ชุมชน PostgreSQL กำลังหารือกันอย่างกระตือรือร้นเกี่ยวกับความท้าทายและแนวทางปฏิบัติที่ดีที่สุดสำหรับการสำรองและกู้คืนฐานข้อมูล โดยเฉพาะอย่างยิ่งสำหรับสถานการณ์การกู้คืนแบบเย็น การสนทนานี้เกิดขึ้นหลังจากการปรับปรุงประสิทธิภาพล่าสุดใน pgstream ซึ่งเป็นเครื่องมือ Change Data Capture แต่ได้ขยายไปสู่ความกังวลที่กว้างขึ้นเกี่ยวกับกลยุทธ์การกู้คืนจากภัยพิบัติของ PostgreSQL
 |
|---|
| แผนผังแสดงกระบวนการสร้าง snapshot ของ PostgreSQL และเริ่มต้น replication เพื่อปรับปรุงการสำรองข้อมูลและการกู้คืน |
ความท้าทายของการกู้คืนแบบเย็น
ผู้ดูแลระบบฐานข้อมูลกำลังเน้นย้ำถึงช่องว่างที่สำคัญในเอกสารอย่างเป็นทางการของ PostgreSQL เกี่ยวกับสถานการณ์การกู้คืนแบบเย็นและแบบมืด สถานการณ์เหล่านี้เกี่ยวข้องกับการกู้คืนจากการสำรองข้อมูลนอกสถานที่หลังจากระบบล้มเหลวอย่างสมบูรณ์ โดยเฉพาะอย่างยิ่งท้าทายสำหรับฐานข้อมูลในช่วง 100GB ถึง 2TB ซึ่งเป็นช่วงที่ธุรกิจส่วนใหญ่ดำเนินการอยู่ กระบวนการกู้คืนอาจใช้เวลาตั้งแต่ 6 ถึง 72 ชั่วโมง มักจะอยู่ภายใต้สภาวะที่เครียด
ชุมชนเน้นย้ำว่าการหาลำดับการดำเนินงานที่ถูกต้องสำหรับการกู้คืนบทบาท สิทธิ์ และสคีมาอาจเป็นเรื่องยุ่งยาก การทำผิดพลาดกลางคันในกระบวนการกู้คืนที่ใช้เวลานานอาจหมายถึงการต้องทำงานซ้ำหลายชั่วโมง โดยเฉพาะอย่างยิ่งเมื่อทำงานกับฐานข้อมูลการผลิตขนาดใหญ่ที่มีพฤติกรรมแตกต่างจากสภาพแวดล้อมการพัฒนาขนาดเล็ก
หมวดหมู่ขนาดฐานข้อมูลที่กล่าวถึง:
- ฐานข้อมูลขนาดเล็ก: ต่ำกว่า 1GB (สำหรับการพัฒนา/ทดสอบ)
- ฐานข้อมูลขนาดกลาง: 100GB-2TB (ธุรกิจส่วนใหญ่)
- ฐานข้อมูลขนาดใหญ่: 1TB+ (ระดับองค์กร)
- เวลาในการกู้คืนแตกต่างกันอย่างมาก: 6-72 ชั่วโมง ขึ้นอยู่กับขนาดและวิธีการ
โซลูชันอัตโนมัติและเครื่องมือ
สมาชิกชุมชนหลายคนได้แบ่งปันแนวทางของพวกเขาในการแก้ไขปัญหาความน่าเชื่อถือของการสำรองข้อมูล องค์กรบางแห่งใช้กระบวนการกู้คืนอัตโนมัติรายชั่วโมงและรายวันโดยใช้สคริปต์เชลล์ ทำให้พนักงานสามารถทดสอบและตรวจสอบความถูกต้องของการสำรองข้อมูลได้อย่างสม่ำเสมอ แนวทางเชิงรุกนี้ช่วยระบุความล้มเหลวของการสำรองข้อมูลก่อนที่จะกลายเป็นปัญหาสำคัญในระหว่างการกู้คืนจากภัยพิบัติจริง
ชุมชนยังได้เน้นย้ำถึงเครื่องมือเฉพาะทางเช่น pg_bulkload สำหรับการกู้คืนแบบเย็นที่เร็วขึ้น ซึ่งสามารถลดเวลาการกู้คืนจาก 24-72 ชั่วโมงเหลือเพียง 1-2 ชั่วโมงสำหรับฐานข้อมูลขนาดเทราไบต์ นอกจากนี้ เครื่องมือเช่น pg_repack ช่วยรักษาระบบที่ทำงานอยู่โดยการเรียกคืนพื้นที่ดิสก์โดยไม่มีการหยุดทำงาน
การเปรียบเทียบประสิทธิภาพเครื่องมือสำรองข้อมูล:
- pg_bulkload: ลดเวลาการกู้คืนฐานข้อมูลขนาด 1TB+ จาก 24-72 ชั่วโมง เหลือเพียง 1-2 ชั่วโมง
- Standard pg_dump/pg_restore: ประสิทธิภาพพื้นฐานสำหรับการเปรียบเทียบ
- ZFS snapshots: การสำรองข้อมูลระดับระบบไฟล์พร้อมฟังก์ชัน send/receive
- WAL-G: โซลูชันการสำรองข้อมูลทางเลือกที่ชุมชนแนะนำ
กลยุทธ์การสำรองข้อมูลระดับไฟล์ระบบ
การถกเถียงที่น่าสนใจได้เกิดขึ้นเกี่ยวกับการใช้สแนปช็อตระดับไฟล์ระบบสำหรับการสำรองข้อมูล PostgreSQL ผู้ดูแลระบบบางคนสนับสนุนการใช้สแนปช็อต ZFS พร้อมฟังก์ชัน send/receive โดยถือว่าเป็นแนวทางที่สะอาดซึ่งทำงานได้กับโครงสร้างพื้นฐานข้อมูลทั้งหมดของพวกเขา ไม่ใช่เพียงแค่ PostgreSQL วิธีการนี้สามารถให้เวลาการกู้คืนที่เร็วกว่าเมื่อเปรียบเทียบกับกระบวนการดัมพ์และกู้คืน SQL แบบดั้งเดิม
อย่างไรก็ตาม มีการถกเถียงเกี่ยวกับการใช้ไฟล์ระบบ copy-on-write กับฐานข้อมูล บางคนโต้แย้งว่าฐานข้อมูลจัดการคุณสมบัติหลายอย่างที่ไฟล์ระบบขั้นสูงให้มาแล้ว อาจเสียสละประสิทธิภาพเพื่อมาตรการความปลอดภัยที่ซ้ำซ้อน
ความแตกต่างระหว่างการจำลองแบบและการสำรองข้อมูล
ชุมชนเน้นย้ำอย่างแรงถึงความแตกต่างระหว่างโซลูชันความพร้อมใช้งานสูงและการกู้คืนจากภัยพิบัติที่แท้จริง แม้ว่าการจำลองแบบสตรีมมิ่งและการจำลองแบบอ่านจะให้เวลาทำงานที่ยอดเยี่ยม แต่ก็ไม่ได้ป้องกันสถานการณ์ความล้มเหลวทั้งหมด
มีรูปแบบความล้มเหลวมากมายที่ความล้มเหลวไปพร้อมกับการจำลองแบบสตรีมมิ่งและอินสแตนซ์ทั้งหมดถูกทำลาย
ความสามารถในการกู้คืนจุดเวลาและขั้นตอนการสำรองข้อมูลที่ผ่านการทดสอบยังคงเป็นสิ่งสำคัญ แม้ว่าจะมีการจำลองแบบที่แข็งแกร่งอยู่ก็ตาม การถกเถียงเสริมว่าการวางแผนการกู้คืนจากภัยพิบัติต้องคำนึงถึงสถานการณ์ที่การจำลองแบบเองล้มเหลวหรือแพร่กระจายปัญหาไปยังอินสแตนซ์ทั้งหมด
เครื่องมือที่ชุมชนแนะนำ:
- pg_bulkload: การโหลดข้อมูลจำนวนมากอย่างรวดเร็วสำหรับการกู้คืนแบบ cold restore
- pg_repack: การจัดระเบียบตารางแบบสดและการเรียกคืนพื้นที่
- barman: ตัวจัดการสำรองข้อมูลและการกู้คืนสำหรับ PostgreSQL
- WAL-G: เครื่องมือจัดเก็บและกู้คืนสำหรับ PostgreSQL
ช่องว่างในการทดสอบและเอกสาร
ธีมที่เกิดขึ้นซ้ำในการถกเถียงของชุมชนคือความสำคัญของการทดสอบขั้นตอนการกู้คืนจากภัยพิบัติในระดับใหญ่ องค์กรหลายแห่งค้นพบช่องว่างในแผนการกู้คืนของพวกเขาเฉพาะในระหว่างเหตุฉุกเฉินจริง ชุมชนเรียกร้องให้มีเอกสารอย่างเป็นทางการที่ดีกว่าซึ่งให้คำแนะนำทีละขั้นตอนสำหรับสถานการณ์การกู้คืนทั่วไป คล้ายกับสิ่งที่ระบบฐานข้อมูลอื่นๆ เสนอ
การสนทนาเผยให้เห็นว่าแม้ว่า PostgreSQL จะให้เครื่องมือสำรองและกู้คืนที่ทรงพลัง แต่ความรู้เชิงปฏิบัติในการประสานงานอย่างมีประสิทธิภาพในระหว่างสถานการณ์วิกฤตมักจะพึ่งพาภูมิปัญญาของชุมชนมากกว่าคำแนะนำอย่างเป็นทางการที่ครอบคลุม สิ่งนี้เน้นย้ำถึงโอกาสสำหรับการปรับปรุงเอกสารและแนวทางปฏิบัติที่ดีที่สุดที่เป็นมาตรฐานในระบบนิเวศ PostgreSQL
อ้างอิง: Behind the scenes: Speeding up pgstream snapshots for PostgreSQL