สแน็ปช็อตการจัดเก็บข้อมูลสำหรับการสำรองข้อมูลที่สอดคล้องกันของ postgresql - ข้อมูลและปริมาณการบันทึกที่แตกต่างกัน

เรากำลังเรียกใช้ Linux VM จำนวนมากในสภาพแวดล้อมการจัดเก็บข้อมูลแบบ vmware / ที่ใช้ร่วมกันซึ่งแต่ละตัวใช้งานอินสแตนซ์ของตนเองของ postgreSQL (รวม 9.0 และ 9.3) ปัจจุบัน VM ทั้งหมดตั้งอยู่บนพาร์ติชัน / ไดรฟ์หนึ่งรูทและเราประสบความสำเร็จอย่างมาก (~ 8 ปี) โดยใช้สแนปชอตจากสตอเรจของโวลุ่ม VMFS พื้นฐานสำหรับกระบวนการสำรองข้อมูล / คืนค่า (และทำซ้ำไปยังไซต์ DR ของเรา)

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

ด้วยเหตุนี้เราจึงทำการทดลองบางอย่างขณะที่เขียนข้อมูลไปยังฐานข้อมูลให้เร็วที่สุดโดยใช้ pg_bench หลังจากการทดลองเรากู้คืนไดรฟ์ข้อมูล snapshot ของเราและเริ่ม VM + postgres

• สแนปชอตทั้งข้อมูลและปริมาณการบันทึกใกล้เคียงกัน - ผลลัพธ์: ฐานข้อมูลถูกกู้คืน
• Snapshot data volume ก่อน, log volume ~ 1 นาทีต่อมา - ผลลัพธ์: DB recovery
• Snapshot log volume ก่อน, ปริมาณข้อมูล ~ 1 นาทีต่อมา - ผลลัพธ์: DB recovery
• สแนปชอตของโวลุ่มบันทึก, ปริมาณข้อมูล ~ 3 นาทีต่อมา, หลังจากจุดตรวจ WAL เขียนข้อมูลใหม่ไปยังดาต้าไทล์: ผล: DB กู้คืน

ดังนั้นการทดสอบดูเหมือนจะบอกเราตราบใดที่สแนปชอตทั้งสองนั้นสอดคล้องกันที่ระดับเสียงและค่อนข้างใกล้กันคุณจะได้รับสำเนาที่สอดคล้องกันของฐานข้อมูลตามเวลาของสแน็ปช็อตโวลุ่มของ WAL / Log

คำถามของฉัน: ปลอดภัยหรือไม่ เราทำพลาดอะไรบ้างในการทดสอบและสิ่งที่ผิดพลาด?

เอกสารของ Postgres บ่งบอกว่าสิ่งนี้ไม่ปลอดภัย แต่การทดสอบดูเหมือนจะบ่งบอกถึงความแข็งแกร่ง: http://www.postgresql.org/docs/9.1/static/backup-file.html

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

หมายเหตุ: ใช่เรารู้เกี่ยวกับตัวเลือกอื่น ๆ เพื่อให้แน่ใจว่าสอดคล้องกันเช่นการวาง PostgreSQL ไว้ในโหมด hot backup หรือใช้การรวม VMware ของสตอเรจของเราเพื่อระงับ VM ของตัวเอง แต่เรากำลังมองหาโซลูชันเฉพาะที่จัดเก็บเพื่อความสะดวกรวดเร็ว และไม่มีผลกระทบกับลูกค้าของเรา

เอกสารที่คุณอ้างอ้างว่าเป็นข้อมูลทั้งหมด แต่ฉันจะไม่โทษคุณหากคุณต้องการลองตรวจสอบการอ้างสิทธิ์ของผู้ขายเกี่ยวกับสแนปชอตที่ถ่ายในเวลาเดียวกัน บางทีวิธีการเปิดเผยบางสิ่งอาจเป็นการทดสอบระบบความเครียดโดยเฉพาะเจาะจงมากขึ้น

เช่นนอกจากการทดสอบ pgbench ของคุณลองเพิ่มโทรสุ่มเพื่อpg_switch_xlog()การหมุนเข้าสู่ระบบบังคับสั้นและยาวช่วงด่าน (สั้นลงและยาวcheckpoint_timeoutและcheckpoint_timeout) และแม้กระทั่งการใช้ขนาดเล็กหรือใหญ่ขนาดของไฟล์วอล

หากไม่มีสิ่งที่ขาดหายไปสำหรับภาพรวมของคุณที่ไม่ได้ถ่ายพร้อมกันฉันจะรวบรวม DBs ที่คุณกู้คืนมาอาจจะเป็นช่วงเวลาที่โชคดี ในกรณีที่ผ่านมาคิดว่าคุณเอาภาพรวมบันทึกของคุณในขณะที่สถานที่ตั้ง xlog 0/A1C0FFEEปัจจุบันคือการพูด จากนั้นคุณจะมีภาระหนักมากเป็นพิเศษในระบบเป็นเวลา 3 นาทีซึ่งทำให้เกิดวัฏจักรทั้งหมดผ่านไฟล์ WAL และฐานข้อมูลของคุณจะอยู่ที่ตอนที่0/DEADBEEFถ่ายภาพข้อมูล เมื่อคุณพยายามกู้คืนไฟล์ WAL ที่ถูกเขียนไปในเวลาที่สแนปชอตข้อมูลหายไปนานและการกู้คืนจะล้มเหลว