pgactive - ส่วนขยายการจำลองแบบ Active-Active สำหรับ Postgres

• ส่วนขยาย active-active replication สำหรับ PostgreSQL ที่ AWS สร้างและเปิดเผยเป็นโอเพนซอร์ส
• เมื่อต้องมีการเขียนและแก้ไขข้อมูลจากหลาย PostgreSQL อินสแตนซ์ แทนที่จะใช้โมเดล active-standby แบบเดิมที่ให้อินสแตนซ์หนึ่งรับการเปลี่ยนแปลงเพียงลำพัง ก็สามารถสร้างสถาปัตยกรรมที่รองรับ การเปลี่ยนแปลงพร้อมกันจากหลายอินสแตนซ์ และการจำลองแบบได้
• เหมาะกับสถานการณ์อย่าง การออกแบบฐานข้อมูลที่มีความพร้อมใช้งานสูง ข้ามหลายรีเจียน, การลด latency ของการเขียน, blue/green update ของแอปพลิเคชัน, และ การย้ายข้อมูลแบบสองทิศทาง
• ใช้ logical replication เพื่อรองรับการตรวจจับความขัดแย้ง, การแก้ไข write conflict และการแปลงฟอร์แมตของฐานข้อมูลเป้าหมาย เป็นต้น

แนวคิดของการจำลองแบบ Active-Active

• การจำลองแบบ (Replication) คือเทคโนโลยีสำหรับซิงก์การเปลี่ยนแปลงระหว่างฐานข้อมูล
• โครงสร้าง active-standby แบบเดิมของ PostgreSQL อนุญาตให้มีเพียงอินสแตนซ์เดียวที่รับการเปลี่ยนแปลงได้ ส่วนที่เหลือจะเป็นแบบอ่านอย่างเดียว จึงมีแหล่งข้อมูลหลักเพียงจุดเดียว
• pgactive มอบ topology การจำลองแบบแบบ active-active ทำให้หลายอินสแตนซ์สามารถเขียนข้อมูลได้พร้อมกัน
• วิธีนี้เหมาะกับสภาพแวดล้อมที่ต้องการหลายจุดสำหรับการเขียน เช่น การปรับใช้แบบ multi-region หรือการย้ายข้อมูลแบบสองทิศทาง
• ในโมเดล active-active จำเป็นต้องมีการจัดการเพิ่มเติมสำหรับความขัดแย้ง, ความล่าช้า และข้อจำกัดของบางฟีเจอร์

เทคโนโลยีหลัก: Logical Replication

• Logical Replication คือการส่งข้อมูลในรูปแบบที่ระบบภายนอกสามารถตีความได้
• ด้วย logical replication สามารถเพิ่มความสามารถเสริมต่าง ๆ บนฐานข้อมูลปลายทางได้ เช่น การตรวจจับความขัดแย้ง, การแก้ไข write conflict และการแปลงคิวรี
• PostgreSQL ได้เพิ่ม logical replication พื้นฐาน มาตั้งแต่เวอร์ชัน 10 ในปี 2017 แต่สำหรับ active-active replication ยังต้องมีความสามารถเพิ่มเติม
• ด้วยลักษณะการออกแบบของ PostgreSQL ฟังก์ชันเหล่านี้จึงสามารถพัฒนาและนำไปใช้ได้ในรูปแบบ ส่วนขยาย (extension)
• ชุมชนนักพัฒนาของ PostgreSQL เองก็กำลังทยอยเพิ่มความสามารถเหล่านี้เข้าสู่โปรเจกต์หลักเช่นกัน

[GN⁺]

ความคิดเห็นใน Hacker News

• ลองสรุปประวัติพัฒนาการของ BDR, pglogical, pgactive และ Postgres Distributed(PGD) จากที่ได้ยินมาจากเพื่อนร่วมทีมของ 2nd Quadrant และ EDB
  ตัวที่ออกมาตัวแรกและยังเป็นโอเพนซอร์สอยู่จนถึงตอนนี้คือ BDR1 (ลิงก์) และ pgactive ก็สร้างขึ้นบนพื้นฐานนี้
  BDR2 เป็นการเขียน BDR1 ใหม่แบบปิดซอร์ส และสุดท้ายก็ถูกยกเลิกไป
  จากนั้นมี pglogical v1 และ v2 (ทั้งคู่เป็นโอเพนซอร์ส, ลิงก์) ออกมา โดย v1 ถูกปรับแก้อย่างมากแล้วถูกรวมเข้าไปใน Postgres 10
  อาศัยประสบการณ์จากฟีเจอร์ logical replication ของ Postgres 10 ทำให้ 2nd Quadrant เริ่มพัฒนา pglogical v2 และจากจุดนี้ pgEdge ก็ถือกำเนิดขึ้นมา
  หลังจากนั้น 2nd Quadrant ก็สร้าง pglogical v3 และ BDR v3 แบบปิดซอร์ส แล้วรวมทั้งสองอย่างเป็น BDR v4
  ต่อมาชื่อผลิตภัณฑ์ BDR ก็เปลี่ยนเป็น Postgres Distributed(PGD, ลิงก์)
  และหลังจาก 2ndQuadrant ถูก EDB เข้าซื้อกิจการ EDB ก็ออก PGD v6
  • ที่ PostgresPro ก็มีระบบ replication แบบ multi-master แยกต่างหากด้วย ลิงก์เอกสาร
  • ถามว่า PGDv6 ยังเป็นแบบปิดซอร์สอยู่หรือไม่
• ระบบนี้ใช้ logical replication ของ Postgres เพื่อส่งต่อการเปลี่ยนแปลงจากอินสแตนซ์หนึ่งไปยังอีกอินสแตนซ์หนึ่ง
  ถ้าเกิด conflict จะใช้วิธีให้ค่าที่ถูกเขียนล่าสุดตาม timestamp เป็นค่าที่มีผลสุดท้าย
  ประวัติของ conflict ที่เกิดขึ้นจะถูกเก็บไว้ในตารางพิเศษชื่อ pgactive_conflict_history จึงสามารถตรวจสอบประวัติหรือแก้ไขด้วยตนเองได้
  รายละเอียดเพิ่มเติมและเอกสารดูได้ที่นี่
  • สงสัยว่านี่นับเป็น multi-master replication หรือไม่
    ถ้าสามารถนำความสามารถนี้เข้าไปเป็นส่วนหนึ่งของ Postgres อย่างเป็นทางการได้ก็น่าสนใจดี
  • ในมุมผู้ใช้ อยากรู้ว่าการเขียนข้อมูลของตัวเองจะได้รับการยืนยันในทันที หรือเป็นแค่ eventual consistency
• สงสัยว่ามีใครเพิ่งได้ลองใช้ฐานข้อมูลของ Bloomberg(comdb2) โดยตรงบ้างหรือไม่
• มีคำถามที่เกี่ยวข้องแต่หลุดประเด็นไปนิดหน่อยว่า มีวิธีทำ "replication ที่เขียนในเครื่องได้ (โดยอิงจาก read replica)" หรือไม่
  เช่น อยากใช้ฐานข้อมูลรองที่อ่านข้อมูลจาก production หรือ staging ได้ แต่แก้ไขได้เฉพาะในเครื่อง local และผลลัพธ์จะไม่ถูกส่งกลับขึ้นไปยัง upstream
  ตอนนี้วิธีที่ใช้กันมากคือคอยรันสคริปต์เป็นระยะ ๆ (เช่น cron) เพื่อ dump หรือ query ข้อมูลมาสร้าง snapshot แล้วเก็บไว้ใน S3 จากนั้นก็ดึงมาลงเครื่องเพื่อ restore ข้อมูล
  วิธีนี้ส่วนใหญ่ใช้ได้ผล แต่บางครั้งการสร้างดัชนีกินเวลานานเกินไป
  • อนึ่ง ถ้าเป็นข้อมูลอ่อนไหวอย่างข้อมูลส่วนบุคคล การปล่อยให้ข้อมูลไหลเข้า staging หรือ dev โดยตรงแบบนี้มีความเสี่ยงมาก
    เพราะมีประเด็นทางกฎหมายและจริยธรรมใหญ่พอสมควร บริษัทส่วนใหญ่จึงไม่แนะนำวิธีนี้
  • ถ้าใช้ logical replication ของ Postgres ร่วมกับ filter ก็ทำ replication ทางเดียวได้ และเมื่อปล่อย replication slot แล้วก็สามารถแก้ไขข้อมูลในเครื่องได้อย่างอิสระ
    แบบนี้จะทำให้แก้ไขเฉพาะตารางในเครื่องได้โดยไม่กระทบ primary
  • ถ้ามีฐานข้อมูล local แบบ "สะอาด" เก็บไว้เป็นต้นแบบ ก็สามารถ clone มันเมื่อต้องการแล้วใช้เป็นฐานข้อมูลสำหรับพัฒนาได้ ทำให้คัดลอกได้เร็วมากโดยไม่ต้องสร้างดัชนีใหม่
    แนะนำคำสั่ง createdb --template
  • สงสัยว่าถ้าการเขียนใน local ไปชนกับการอัปเดตจากฝั่ง remote จะจัดการอย่างไร
    นึก merge strategy ที่ใช้ได้กับทุกสถานการณ์ไม่ออก
  • เท่าที่ทราบ สำหรับการตั้งค่า logical replication ของ Postgres นี่คือพฤติกรรมมาตรฐาน
    ไม่ได้ห้ามเขียนบน replica เพียงแต่ผลลัพธ์นั้นจะไม่กระจายไปที่อื่น
• ควรจำไว้เสมอว่าคำว่า "Conflict resolution" สุดท้ายแล้วหมายถึง "ยอมทิ้งข้อมูลที่ถูก commit และยืนยันไปแล้ว ทำให้ความทนทานของข้อมูลพังลง"
  ทางที่ดีที่สุดคือออกแบบสถาปัตยกรรมไม่ให้ช่วงข้อมูลที่เขียนจากทุก active instance ซ้อนทับกัน
  ในกรณีแบบนี้เครื่องมืออย่าง pgactive ก็พอใช้งานได้
  ไม่เช่นนั้นก็ควรใช้ distributed database อย่าง Yugabyte ไปตั้งแต่แรก
  • ในเอกสารทางการก็แนะนำวิธีหลีกเลี่ยง conflict ด้วยการแยก schema ตาม master เพื่อให้ "แต่ละ master เป็นผู้เขียนเพียงรายเดียวของแต่ละ schema"
    ทุก master ยังอ่านทุก schema ได้ แต่ตอนเขียนจะเขียนเฉพาะส่วนที่ตัวเองรับผิดชอบ
    สงสัยว่านอกจาก schema แล้ว จะใช้ partition หรือวิธีอื่นในการกระจายความรับผิดชอบได้หรือไม่
• ทำให้อดคิดไม่ได้ว่า AWS สร้างสิ่งนี้ขึ้นมาทำไม
  นึกไม่ออกว่าพวกเขาจะใช้ฟีเจอร์นี้ในผลิตภัณฑ์ของตัวเองตรงไหน
  RDS ใช้ block replication ส่วน Aurora ใช้ SAN replication แบบเฉพาะของตัวเอง
  เดาว่าอาจตั้งใจเอาไปใช้กับ DMS
  • อาจเป็นเพราะ Aurora DSQL ที่เพิ่งเปิดตัวไม่นานนี้ก็ได้
  • จริง ๆ แล้วยังมองไม่ค่อยเห็นประโยชน์มากนัก
    เลยสงสัยว่าทำไมถึงต้องทำแบบนี้กับ relational database ที่เน้น ACID แบบเข้มแข็ง
  • เท่าที่รู้ SAN replication ของ Aurora ไม่ได้ใช้กับ cross region replication
  • ใน readme ของ repository นั้นก็ระบุชัดว่า "การใช้งานหลักคือสร้างคลัสเตอร์ฐานข้อมูลที่มีความพร้อมใช้งานสูงแบบ Multi-Region"
  • มีคนบอกว่าจริง ๆ แล้วนี่เป็นฟีเจอร์ที่มีให้ใน RDS Postgres มาตั้งแต่ 2 ปีก่อน (ลิงก์ที่เกี่ยวข้อง)
    แต่เพิ่งมีข่าวเมื่อ 1 เดือนก่อนว่าเปิดซอร์สและเผยแพร่สู่ชุมชนอย่างเป็นทางการ (ข่าวทางการ)
• เคยใช้ repmgr และ patroni เพื่อดูแลหลายคลัสเตอร์ให้แทบไม่มี downtime เลย ดังนั้นปลั๊กอินนี้เป็นอะไรที่อยากติดตั้งเป็นทางเลือกสุดท้ายจริง ๆ
  ถ้าอยากนอนหลับสบายตอนกลางคืนก็ควรหลีกเลี่ยงให้มากที่สุด
• บังเอิญช่วงนี้กำลังหาวิธีสร้างคลัสเตอร์ Postgres แบบ high availability ที่รองรับ "automatic failover, การกู้คืนโหนด, point-in-time recovery" ได้อย่างง่าย ๆ
  เห็นมีคนแนะนำชุด patroni+etcd+haproxy กันเยอะ และจากที่เห็นคนเคยใช้พูดถึงกันอย่างตื่นเต้นก็คงมีเหตุผลของมัน
  แต่พอดูไฟล์ตัวอย่าง docker compose แล้วก็รู้สึกว่ามันหนักพอตัว
  ส่วน pgpool ดูเหมือนแค่วางไว้หน้า postgres แต่ละตัวก็พอ เลยดูง่ายกว่า
  เลยอยากรู้คำแนะนำหรือประสบการณ์จากคนที่ชอบใช้ Postgres ในงานจริง
  เป้าหมายคือสร้างคลัสเตอร์บนพื้นฐาน docker compose ให้เรียบง่ายที่สุด แต่ยังได้ high availability, (อย่างน้อย) การไม่สูญเสียข้อมูล และ point-in-time recovery
  • ถามว่ากำลังมองหาเครื่องมืออย่าง Barman อยู่หรือไม่
  • ตอนนี้ใช้ cloudnativepg อยู่ และฟีเจอร์ที่ต้องการส่วนใหญ่ก็ทำงานได้เลยจากตัวมันเอง
• แชร์ว่ามีข้อมูลอื่นเกี่ยวกับ pgactive หรือกรณีใช้งานที่เกี่ยวข้องอีกหรือไม่
  <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
  โพสต์ใน Hacker News (โพสต์เมื่อเดือนตุลาคม 2023, 1 ความคิดเห็น)
• ดูเหมือนจะเป็นแบบ asynchronous และน่าจะมีประเด็นใหญ่เรื่อง transaction isolation
  • สุดท้ายก็มองว่าเป็น trade-off
    กล่าวคือแต่ละคนต้องยอมรับข้อดีข้อเสียตามสถานการณ์ของตัวเอง