PostgreSQL: ฉันสามารถทำ pg_start_backup () บน live ที่รันอยู่ภายใต้โหลดหรือไม่?

การจำลองแบบที่สร้างขึ้นของเราใช้งานไม่ได้ ("ส่วน WAL ที่ร้องขอถูกลบแล้ว" ในช่วงเวลาที่ระบบหยุดทำงาน) เราไม่สามารถหยุดต้นแบบได้อย่างง่ายดายอีกครั้ง

เราทำได้ไหม

1. pg_start_backup(),
2. rsync ${PGDATA}/ นายทาส
3. pg_stop_backup()

... ในขณะที่มาสเตอร์ postgresql ยังโหลดเต็มหรือไม่ (หรือจะpg_start_backup()นำไปสู่

• ล็อคตาราง
• บล็อก I / O
• ไม่สอดคล้องกัน
• สัญญาณเตือนไฟไหม้
• การตอบสนอง db ช้า

กล่าวอีกนัยหนึ่งจะpg_start_backup()ส่งผลต่อแอปพลิเคชันของเราหรือไม่

pg_start_backupจะดำเนินการจุดตรวจตามบันทึก dezso สิ่งนี้มีผลกระทบ แต่ฐานข้อมูลของคุณดำเนินการจุดตรวจอย่างสม่ำเสมออยู่แล้วและต้องทำเช่นนั้นเพื่อให้สามารถทำงานได้ดังนั้นจึงไม่เป็นปัญหาสำหรับคุณอย่างชัดเจน จุดตรวจก่อนหมายถึงมีการสะสมข้อมูลน้อยลงหมายความว่าหากมีสิ่งใดก็ตามที่จุดตรวจสอบpg_start_backupจะได้รับผลกระทบต่ำกว่าปกติ

ที่คุณต้องกังวลคือ rsync หรือpg_basebackupขั้นตอนที่เทียบเท่า การอ่าน I / O จากนี้จะไม่เลวร้ายเกินไปเนื่องจากมันเป็นลำดับ แต่มันอาจจะส่งผลเสียต่อประสิทธิภาพการทำงานของ I / O ของฐานข้อมูลของคุณและมันก็มีแนวโน้มที่จะผลักดันข้อมูลออกมาจากแคช RAM ร้อนน้อย - ข้อมูลที่ใช้แล้วทำให้แคชสั่นเนื่องจากข้อมูลที่ต้องการมากขึ้นจะถูกอ่านอีกครั้ง

คุณสามารถใช้niceและioniceเพื่อช่วย จำกัด ผลกระทบ I / O (แต่ไม่ใช่ผลกระทบของแคช); อย่างไรก็ตามมีค่าใช้จ่าย การสำรองข้อมูลจะใช้เวลานานและจนกว่าคุณจะเสร็จสิ้นการสำรองข้อมูลและเรียกใช้pg_stop_backupระบบของคุณ - ตามที่ฉันเข้าใจ - การสะสม WAL จะไม่สามารถลบสะสมหนี้จุดตรวจสอบสำหรับจุดตรวจใหญ่เมื่อสิ้นสุดการสำรองข้อมูลและกำลังรวบรวมตารางและดัชนี ขยายเพราะมันไม่สามารถล้างแถวที่ตายแล้ว ดังนั้นคุณจึงไม่สามารถที่จะสำรองข้อมูลได้ตลอดไปโดยเฉพาะถ้าคุณมีโต๊ะปั่นสูงมาก

ในที่สุดก็ยากที่จะพูดว่าคุณสามารถใช้งานได้อย่างปลอดภัยpg_start_backupและpg_stop_backupสำรองข้อมูลร้อนในสภาพแวดล้อมของคุณ คนส่วนใหญ่สามารถ แต่ถ้าคุณอยู่ใกล้กับสิ่งที่ฮาร์ดแวร์ของคุณสามารถทำได้มีความต้องการเวลาที่ จำกัด ไม่สามารถเสี่ยงต่อการแผงลอยและมีโต๊ะปั่นสูงมากเช่นเดียวกับตารางขนาดใหญ่มากมันอาจจะลำบาก .

น่าเสียดายที่คุณต้องทดสอบและดู

หากคุณสามารถทำได้อาจเป็นการดีถ้าคุณเปิดCHECKPOINTใช้สแนปชอตอะตอมของไดรฟ์ข้อมูลที่ฐานข้อมูลของคุณเปิดอยู่แทนที่จะใช้ LVM เครื่องมือของ SAN EBS หรืออะไรก็ตามที่คุณใช้ หากคุณสามารถทำได้คุณสามารถคัดลอกสแนปชอตได้ตามต้องการ วิธีนี้ไม่เหมาะสำหรับการสำรองข้อมูลพื้นฐานสำหรับ PITR / โหมดเตรียมพร้อม / โหมดเตรียมพร้อม แต่เป็นวิธีการสำรองข้อมูลแบบสแตติกที่ดีเลิศและมีผลกระทบต่อระบบน้อยกว่ามาก คุณสามารถทำได้หากสแนปชอตของคุณเป็นแบบอะตอมและฐานข้อมูลทั้งหมดของคุณรวมถึง WAL จะอยู่ในวอลุ่มเดียว

ความเป็นไปได้หนึ่งที่ฉันยังไม่ได้ตรวจสอบคือการรวมสองวิธี มันเกิดขึ้นกับฉันว่าอาจเป็นไปได้ ( ยังไม่ทดลองและอาจผิดและไม่ปลอดภัยฉันยังไม่รู้):

• pg_start_backup
• ทริกเกอร์สแน็ปช็อตของพื้นที่ตารางทั้งหมด datadir หลักและปริมาณ xlog
• pg_stop_backup
• คัดลอก WAL จนถึงไฟล์เก็บถาวรสุดท้ายจาก pg_stop_backup
• คัดลอกข้อมูลจากสแน็ปช็อตวอลุ่ม

โดยพื้นฐานแล้วความคิดคือการลดระยะเวลาที่ฐานข้อมูลต้องชะลอการตรวจสอบจุดโดยใช้เวลาของแต่ละเล่มที่คุณสามารถคัดลอกในเวลาว่าง

นี่เป็นการขุดหลุมฝังศพ แต่ฉันต้องแก้ไขบางสิ่งที่นี่

คำตอบก่อนหน้านี้ระบุว่า:

คุณสามารถใช้ niceice และ ionice เพื่อช่วย จำกัด ผลกระทบ I / O (แต่ไม่กระทบกับแคช); อย่างไรก็ตามมีค่าใช้จ่าย การสำรองข้อมูลจะใช้เวลานานและจนกว่าคุณจะเสร็จสิ้นการสำรองข้อมูลและเรียกใช้ pg_stop_backup ระบบของคุณ - ตามที่ฉันเข้าใจ - การสะสม WAL จะไม่สามารถลบสะสมหนี้จุดตรวจสอบสำหรับจุดตรวจใหญ่เมื่อสิ้นสุดการสำรองข้อมูลและกำลังรวบรวมตารางและ ดัชนีขยายเนื่องจากไม่สามารถล้างแถวที่ตายแล้ว ดังนั้นคุณจึงไม่สามารถที่จะสำรองข้อมูลได้ตลอดไปโดยเฉพาะถ้าคุณมีโต๊ะปั่นสูงมาก

ที่ไม่เป็นความจริง. ระบบจะเก็บหมายเลข WAL ไว้ในการกำหนดค่าของคุณ (cf เอกสารออนไลน์ ) ดังนั้นโดยทั่วไปแล้วค่าที่สูงขึ้นระหว่าง:

• (2 + checkpoint_completion_ratio) * checkpoint_segments + 1
• wal_keep_segments

ลองจินตนาการถึงกรณีนี้:

• การสำรองข้อมูลของคุณใช้เวลานานเนื่องจากมีหลายร้อยกิ๊กที่จะคัดลอก
• คุณมีการเก็บรักษา WAL ขนาดเล็ก (เช่นจุดตรวจสอบ 3 ส่วน)
• คุณไม่มีการตั้งค่าการเก็บถาวร WAL

จากนั้นหลังจากเริ่มต้น "pg_start_backup ()" ไฟล์ WAL ของคุณจะหมุนระหว่างการสำรองข้อมูล เมื่อการสำรองข้อมูลของคุณจะเสร็จสิ้นจากนั้นคุณจะพยายามคืนค่าในโปรแกรมฐานข้อมูลอื่น เอ็นจิ้นที่เปิดตัวจะขอไฟล์ WAL อย่างน้อยสร้างขึ้นเมื่อคุณออก "pg_start_backup ()"

pg_start_backup 
-----------------
B/D0020F18
(1 row)

ฐานข้อมูลจะไม่ยอมรับการบูตจนกว่าคุณจะให้ไฟล์ WAL "0000000x0000000B000000D0" (โดยที่ x เป็นของคุณ TimelineID ) ไฟล์ WAL นี้เป็นขั้นต่ำเปล่าสำหรับระบบในการบูต แน่นอนว่ามีเพียงไฟล์นี้เท่านั้นคุณจะสูญเสียข้อมูลเนื่องจากข้อมูลที่เหลืออยู่ในไฟล์ WAL ที่คุณไม่มี แต่อย่างน้อยคุณจะมีเอ็นจิ้นฐานข้อมูลที่ใช้งานได้

ดังนั้นคุณต้องทำการเก็บถาวร WAL หรือคุณต้องบันทึกไฟล์ WAL ที่จำเป็นด้วยตัวเอง แต่ Postgresql จะไม่ทำเพื่อคุณ

สำหรับประสบการณ์ของฉันกับ PostgreSQL มันเป็นการดำเนินการที่ค่อนข้างปลอดภัยเว้นแต่ว่าคุณจะมีผลกระทบอย่างมากต่อช่วงเวลานั้น หากคุณมีมันก็จะดีกว่าที่จะหยุดเขียนชั่วคราวจากลูกค้าของคุณทั้งหมด

ฉันมีกรณีที่สำคัญเพียงกรณีเดียวในขณะที่ซิงค์เจ้านายของฉันกับทาสภายใต้การโหลดและมันเกิดจาก OOM killer (ใช่คุณควรปิดการใช้งาน OOM Killer บนโหนดฐานข้อมูลโดยสิ้นเชิงฉันไม่ทราบว่าในวันนั้น)

ดังนั้นฉันจึงกู้คืนฐานข้อมูลจากการสำรองข้อมูลทุกคืนและให้ Postgres กลุ่ม WAL ทั้งหมดจากไดเรกทอรี pg_archive สำหรับเล่นซ้ำ (เพิ่งคัดลอกไปไว้ในโฟลเดอร์ pg_xlog) ทุกอย่างเป็นไปด้วยดี แต่การหยุดทำงานก็หลีกเลี่ยงไม่ได้แน่นอน