AWS ได้เปิดซอร์ส pgactive อย่างเป็นทางการ ซึ่งเป็น PostgreSQL extension ที่เปิดใช้งาน active-active replication ข้ามหลาย database instances แม้ว่าเทคโนโลยีนี้จะมีให้ใช้งานเป็นฟีเจอร์ใน AWS RDS Postgres ตั้งแต่ปี 2023 แต่การเปิดตัวล่าสุดให้กับชุมชนได้จุดประกายการอภิปรายอย่างเข้มข้นเกี่ยวกับความซับซ้อนและความเสี่ยงของการตั้งค่า multi-master database
คุณสมบัติหลักของ pgactive :
- การจำลองแบบ active-active ข้ามหลาย PostgreSQL instances
- การแก้ไขข้อขัดแย้งแบบ last-write-wins ที่อิงตามการประทับเวลา
- การบันทึกข้อขัดแย้งในตาราง
pgactive_conflict_history - สร้างบนพื้นฐานของ logical replication ของ PostgreSQL
- รองรับการใช้งานแบบหลายภูมิภาค
- พร้อมใช้งานใน AWS RDS Postgres ตั้งแต่ปี 2023
คำมั่นสัญญาและอันตรายของ Active-Active Replication
pgactive extension ช่วยให้ PostgreSQL instances หลายตัวสามารถรับ writes พร้อมกันได้ โดยมีการ replicate การเปลี่ยนแปลงทั่วทั้ง cluster โดยใช้ฟีเจอร์ logical replication ของ PostgreSQL วิธีการนี้มีเป้าหมายเพื่อแก้ไขปัญหาทั่วไป เช่น การลด write latency ข้าม regions และการรักษา high availability ในระหว่าง network partitions อย่างไรก็ตาม การตอบสนองของชุมชนเผยให้เห็นความกังวลอย่างลึกซึ้งเกี่ยวกับ trade-offs พื้นฐานที่เกี่ยวข้อง
Extension นี้ใช้กลยุทธ์การแก้ไขความขัดแย้งแบบ last-write-wins ที่อิงตาม timestamps โดยบันทึก conflicting transactions ลงในตารางพิเศษเพื่อตรวจสอบในภายหลัง แม้ว่าสิ่งนี้จะฟังดูตรงไปตรงมา แต่ผู้เชี่ยวชาญด้าน database เตือนว่าวิธีการนี้ทำลายหลักการพื้นฐานของ database systems
การแก้ไขความขัดแย้งไม่ได้เป็นอะไรมากไปกว่าคำพูดอ้อมค้อมสำหรับการทำลาย durability โดยการทิ้งข้อมูลที่ committed และ acknowledged ไปแล้ว
การวิจารณ์นี้เน้นย้ำประเด็นพื้นฐาน เมื่อเกิดความขัดแย้ง ข้อมูลที่ committed ไปแล้วอาจถูกเขียนทับอย่างเงียบๆ ซึ่งละเมิดการรับประกัน durability ที่แอปพลิเคชันมักคาดหวังจาก PostgreSQL
ความซับซ้อนทางเทคนิคและความท้าทายในโลกจริง
การอภิปรายของชุมชนเผยให้เห็นว่า pgactive อยู่ในระบบนิเวศที่ซับซ้อนของโซลูชัน PostgreSQL replication เทคโนโลยีนี้สร้างขึ้นจากงานก่อนหน้าของบริษัทอย่าง 2ndQuadrant (ปัจจุบันเป็นส่วนหนึ่งของ EDB ) ซึ่งพัฒนาเครื่องมือ logical replication หลายรุ่น รวมถึง BDR และ pglogical ในช่วงทศวรรษที่ผ่านมา
การใช้งานทางเทคนิคอาศัย logical replication ที่มีอยู่ใน PostgreSQL แต่เพิ่มความสามารถในการตรวจจับและแก้ไขความขัดแย้ง เมื่อเกิดความขัดแย้ง ระบบจะบันทึกไว้เพื่อการแก้ไขด้วยตนเองที่อาจเกิดขึ้น แต่พฤติกรรมเริ่มต้นจะให้ความสำคัญกับ availability มากกว่า consistency ตัวเลือกการออกแบบนี้ทำให้ pgactive เหมาะสมสำหรับกรณีการใช้งานเฉพาะ แต่อาจเป็นอันตรายสำหรับแอปพลิเคชันที่ต้องการ data integrity อย่างเข้มงวด
ผู้ปฏิบัติงาน database สังเกตว่าการ deployment ที่ประสบความสำเร็จมักต้องการการวางแผนสถาปัตยกรรมอย่างระมัดระวัง แอปพลิเคชันต้องได้รับการออกแบบด้วยกลยุทธ์ data partitioning ที่แต่ละ region หรือ instance เขียนข้อมูลไปยัง subset ของข้อมูลของตัวเองเป็นหลัก เพื่อลดความขัดแย้งให้น้อยที่สุด หากไม่มีการวางแผนดังกล่าว ระบบสามารถสร้างผลลัพธ์ที่คาดเดาไม่ได้ซึ่งต้องการการแทรกแซงด้วยตนเองเพื่อแก้ไข
ไทม์ไลน์วิวัฒนาการของ PostgreSQL Replication:
- BDR1: โอเพนซอร์ส เป็นพื้นฐานสำหรับ pgactive
- PostgreSQL 10 (2017): เพิ่ม native logical replication
- pglogical v1/v2: ส่วนขยาย logical replication แบบโอเพนซอร์ส
- BDR v3/v4: ปิดซอร์สโค้ด ต่อมาเปลี่ยนชื่อเป็น Postgres Distributed (PGD)
- PGD v6: ผลิตภัณฑ์เชิงพาณิชย์ล่าสุดจาก EDB
- pgactive (2023): ฟีเจอร์ของ AWS RDS ที่เปิดเป็นโอเพนซอร์สในปี 2024
กรณีการใช้งานที่จำกัดและทางเลือกอื่น
ความเห็นพ้องของชุมชนชี้ให้เห็นว่า pgactive ตอบสนองความต้องการที่แคบ มันทำงานได้ดีที่สุดสำหรับสถานการณ์ที่การกระจายทางภูมิศาสตร์เป็นสิ่งจำเป็น คาดหวัง network partitions และยอมรับ data inconsistency ได้บ้าง ตัวอย่างรวมถึง content management systems, social media platforms หรือ analytics workloads ที่ eventual consistency เพียงพอ
สำหรับแอปพลิเคชันที่ต้องการ strong consistency ผู้เชี่ยวชาญแนะนำให้ยึดติดกับการตั้งค่า PostgreSQL แบบ single-master แบบดั้งเดิมพร้อม read replicas หรือย้ายไปยัง distributed databases ที่สร้างขึ้นเพื่อจุดประสงค์เฉพาะ เช่น CockroachDB, FoundationDB หรือโซลูชัน cloud-native เช่น Google Spanner
การอภิปรายยังเผยให้เห็นว่าองค์กรหลายแห่งสามารถขยายขนาดได้ไกลอย่างน่าประหลาดใจด้วยการกำหนดค่า PostgreSQL แบบ single-master ซึ่งทำให้เกิดคำถามว่าความซับซ้อนในการดำเนินงานของการตั้งค่า multi-master นั้นสมเหตุสมผลสำหรับกรณีการใช้งานส่วนใหญ่หรือไม่
โซลูชันฐานข้อมูลแบบกระจายทางเลือก:
- MySQL Group Replication: การจำลองแบบซิงโครนัสพร้อมฉันทามติแบบเสียงข้างมาก
- Galera: ปลั๊กอินจำลองข้อมูล MySQL แบบการเขียนซิงโครนัส
- CockroachDB: ฐานข้อมูล SQL แบบกระจาย
- FoundationDB: ที่เก็บข้อมูลแบบ key-value พร้อมคุณสมบัติ ACID
- Google Spanner: ฐานข้อมูลแบบกระจายสำหรับคลาวด์โดยเฉพาะ
- Oracle Database: แบบ multi-master พร้อมฮาร์ดแวร์เฉพาะทาง
บทสรุป
แม้ว่า pgactive จะแสดงถึงความพยายามทางวิศวกรรมที่สำคัญและเติมเต็มช่องว่างเฉพาะในระบบนิเวศ PostgreSQL แต่การตอบสนองของชุมชนเน้นย้ำถึงความท้าทายที่แท้จริงของ distributed database systems การเปิดซอร์ส extension ให้ความโปร่งใสเกี่ยวกับ trade-offs เหล่านี้ แต่ยังเป็นการเตือนใจว่าไม่มีโซลูชันง่ายๆ สำหรับความตึงเครียดพื้นฐานระหว่าง consistency, availability และ partition tolerance ใน distributed systems
สำหรับองค์กรส่วนใหญ่ คำแนะนำยังคงชัดเจน ประเมินอย่างระมัดระวังว่าประโยชน์ของ active-active replication มีค่ามากกว่าความซับซ้อนในการดำเนินงานและปัญหา data consistency ที่อาจเกิดขึ้นหรือไม่ เสน่ห์ที่ล่อใจของการตั้งค่า multi-master มักปกปิดความเชี่ยวชาญอย่างลึกซึ้งที่จำเป็นในการใช้งานอย่างปลอดภัย
หมายเหตุ: Logical replication เป็นฟีเจอร์ของ PostgreSQL ที่จับภาพและ replicate การเปลี่ยนแปลงข้อมูลในรูปแบบที่สามารถตีความและแก้ไขก่อนนำไปใช้กับ target databases
อ้างอิง: Active-active Replication Extension for PostgreSQL (pgactive)