EC2 - วิธีการสำรองข้อมูล PostgreSQL อย่างถูกต้องเป็นอย่างไร

นี่คือการติดตั้ง: อินสแตนซ์ Amazon 2 ขนาดเล็ก (สำรอง EBS) EC2 ของ Amazon พร้อม 3 วอลุ่มเพิ่มเติม นี่คือทั้งเว็บเซิร์ฟเวอร์และเซิร์ฟเวอร์ฐานข้อมูล รหัสหนึ่งเล่มสำหรับหนึ่งเล่มสำหรับไดเรกทอรีข้อมูล PostgreSQL (8.4) และอีกหนึ่งเล่มเพื่อจัดเก็บไฟล์ WAL จาก PostgreSQL

(1) วอลุ่มที่มีไฟล์ WAL จะมีการสำรองฐานของไดเรกทอรีข้อมูลซึ่งจะถูกคัดลอกไปหลังจากทำการ pg_start_backup () จากนั้นจะจัดเก็บผลลัพธ์การเก็บถาวรอย่างต่อเนื่องจาก PostgreSQL (ไฟล์ WAL) หากต้องการสแน็ปช็อตวอลุ่มนี้มีจุดใดในการสร้างการซิงค์และการแช่แข็งระบบไฟล์ (ใช้ xfs_freeze หากเป็น XFS หรือ dmsetup หากเป็น EXT4) หรือฉันจะเพียงแค่ถ่ายภาพสด? ไฟล์ WAL จะจัดส่งในอัตราหนึ่งต่อนาที เป็นไปได้ไหมที่สแนปชอตสามารถเริ่มต้นได้ในขณะที่ไฟล์ WAL เดี่ยวถูกคัดลอกมาและทำให้ข้อมูลเสียหาย?

(2) ไดรฟ์ข้อมูลที่ประกอบด้วยไดเรกทอรีข้อมูล PostgreSQL แบบสดจะได้รับการสำรองข้อมูลสำหรับการวัดที่ดี (ทุกวัน) ก่อนที่จะทำสแน็ปช็อตของไดรฟ์ข้อมูลนี้ฉันจะออก pg_dump และไฟล์ SQL ที่เป็นผลลัพธ์จะถูกเก็บไว้ในไดเรกทอรีข้อมูล มีจุดใดในการระมัดระวังเพื่อให้แน่ใจว่าข้อมูลฐานข้อมูลจริงมีความสอดคล้องกันหรือไม่? มันจะถูกต้องหรือไม่ที่จะสมมติว่าการถ่ายภาพสแนปชอตสดจะถูกต้อง (a) ไฟล์กำหนดค่าการสำรองข้อมูล (postgresql.conf, pg_hba.conf, pg_ident.conf) และ (b) สำรองข้อมูลไฟล์ SQL dump การสำรองสองสิ่งนี้ไฟล์การถ่ายโอนข้อมูล sql และไฟล์กำหนดค่าจะเป็นจุดหลักของการจับภาพไดรฟ์ข้อมูลนี้ ฐานข้อมูลไม่ใหญ่มากดังนั้นฉันไม่สนใจความจริงที่ว่าแฟ้มข้อมูลจะขยายภาพรวมนี้ และในกรณีนั้นฉันสามารถทำสแน็ปช็อตสดได้ถูกต้องหรือไม่

(2a) ควรเก็บไดเรคทอรีข้อมูลไว้ในไดรฟ์ข้อมูลรูทหรือไม่และมีสคริปต์การสำรองข้อมูลที่คัดลอกไฟล์ sql dump รวมถึงไฟล์ปรับแต่งไปยังไดรฟ์ข้อมูลอื่น

(3) สำหรับวอลลุ่มที่มีโค้ดอยู่อีกครั้งมีจุดใดในการซิงค์และการแช่แข็งระบบไฟล์? หรือแค่ถ่ายภาพสดจะถูกนำมาใช้? ข้อมูลนี้ควร "คงที่" พอสมควร

(4) นี่เป็นโครงร่างการสำรองข้อมูลที่มั่นคงหรือไม่? ปริมาณการรูทไม่ได้รับการสำรองข้อมูลเป็นประจำเนื่องจากฉันจะเก็บภาพเครื่องหลังจากที่ตั้งค่าและกำหนดค่าแล้ว

ขอบคุณ

ดูคู่มือการปรับ หากคำแนะนำของฉันขัดแย้งกับ 'ในทางใดทางหนึ่งมันถูกต้อง

1. การซิงค์ไม่ใช่ความคิดที่ดีเว้นแต่เครื่องมือคัดลอกของคุณจะ fsync () แต่ละไฟล์ WAL ที่เขียนและไดเรกทอรีอยู่ก่อนคัดลอกไฟล์ถัดไป ไฟล์ WAL สุดท้ายที่ไม่สมบูรณ์นั้นไม่สำคัญอะไรมาก ที่แย่ที่สุดคุณแค่ลบมัน โดยทั่วไปแล้ว Pg จะสำลักกับ WAL ที่ไม่สมบูรณ์ - แม้ว่าจะไม่มีการตรวจสอบอย่างสมบูรณ์ดังนั้นคุณสามารถทำได้เป็นคนโชคร้ายจริง ๆ และให้ลองใช้ข้อมูลขยะที่โอกาสที่บ้าคลั่งเกิดขึ้นเพื่อดูเหมือนเร็กคอร์ด WAL จริง ในตำแหน่งของคุณฉันจะซิงค์ปริมาณก่อนสแนปชอตเพื่อให้แน่ใจว่าบัฟเฟอร์สกปรกใด ๆ ที่ไม่ได้เขียนไว้ใน RAM ตีอิมเมจระบบไฟล์บนดิสก์ การแช่แข็งจะช่วยหลีกเลี่ยง WAL ที่ยุ่งเหยิง แต่ไม่เป็นอันตรายถึงตายได้บางส่วนดังนั้นจึงไม่ใช่ความคิดที่แย่ แต่ไม่สำคัญ สิ่งสำคัญคือการมีไทม์ไลน์ที่ไม่เสียหายจนถึงจุดพักฟื้น ส่วนตัวฉันเขียน WAL ของฉันเป็นชื่อไฟล์ชั่วคราวและเปลี่ยนชื่อพวกเขาเป็นชื่อสุดท้ายของพวกเขาเพียงครั้งเดียวคัดลอกอย่างเต็มที่; ถ้าคุณทำเช่นนี้คุณไม่จำเป็นต้องหยุด

2. เสียงถูกต้อง สแน็ปช็อตสดก็เหมือนกับการทดสอบปลั๊กดึงในระบบที่มีการแคชการเขียนผ่าน ฐานข้อมูลของคุณควรกู้คืนได้ดีเมื่อกู้คืนจากสแนปชอตจริงเช่นเดียวกับหลังจากปลั๊กอินดึง ฉันขอแนะนำให้คุณทำการทดสอบการกู้คืนจากภาพรวมโดยอัตโนมัติ (หมายเหตุ: การทดสอบการกู้คืนข้อมูลสแน๊ปช็อตไม่ใช่การแทนที่แบบสมบูรณ์สำหรับการทดสอบการดึงปลั๊กเนื่องจากไม่ได้คำนึงถึงดิสก์ตัวควบคุม RAID และการเขียนแคชเป็นต้น) ไม่เพียง แต่ไฟล์กำหนดค่าและดัมพ์ แต่ฐานข้อมูลของไฟล์เองควรจะดีหลังจากสแนปชอตของคุณ พิจารณาการซิงค์โวลุ่มก่อนหน้าสแนปชอตเพื่อให้แน่ใจว่าข้อมูลดัมพ์ทั้งหมดมีดิสก์ที่เข้าชมจริง
   
   2a อาจประหยัดพื้นที่ดิสก์บางส่วน แตกต่างกันเล็กน้อย คุณจะได้รับสแนปชอตให้นานขึ้นโดยไม่ต้องวุ่นวายกับฐานข้อมูลสดทั้งหมด

3. ทำไมถึงจับภาพปริมาณรหัสของคุณ การคัดลอกระดับไฟล์ธรรมดาอาจทำได้ดี แน่นอนว่าภาพรวมสดควรจะเป็น

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

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

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