pgactive - tiện ích mở rộng sao chép active-active cho Postgres

• Tiện ích mở rộng sao chép active-active dành cho PostgreSQL do AWS phát triển và công bố
• Khi cần ghi và sửa dữ liệu trên nhiều phiên bản PostgreSQL, thay vì mô hình active-standby truyền thống chỉ cho một phiên bản duy nhất nhận thay đổi, có thể xây dựng một kiến trúc cho phép thay đổi đồng thời và sao chép giữa nhiều phiên bản
• Phù hợp với các kịch bản như cấu hình cơ sở dữ liệu tính sẵn sàng cao trên nhiều region, giảm thiểu độ trễ ghi, cập nhật blue/green cho ứng dụng, và di chuyển dữ liệu hai chiều
• Tận dụng logical replication để hỗ trợ phát hiện xung đột, xử lý xung đột khi ghi, chuyển đổi định dạng cơ sở dữ liệu đích, v.v.

Khái niệm sao chép active-active

• Sao chép (Replication) là công nghệ đồng bộ hóa các thay đổi giữa các cơ sở dữ liệu
• Cấu trúc active-standby truyền thống của PostgreSQL chỉ cho một phiên bản nhận thay đổi, còn các phiên bản khác ở dạng chỉ đọc, nên một nơi sẽ đóng vai trò là nguồn dữ liệu duy nhất
• pgactive cung cấp topology sao chép active-active, cho phép ghi dữ liệu đồng thời trên nhiều phiên bản
• Cách tiếp cận này phù hợp với các môi trường cần nhiều điểm ghi, ví dụ như triển khai đa region hoặc di chuyển dữ liệu hai chiều
• Trong mô hình active-active, cần quản lý riêng các vấn đề như xung đột, độ trễ và một số giới hạn tính năng

Công nghệ cốt lõi: logical replication

• Logical Replication truyền dữ liệu theo định dạng mà các hệ thống bên ngoài có thể diễn giải được
• Thông qua logical replication, có thể triển khai nhiều tính năng bổ sung trên cơ sở dữ liệu đích như phát hiện xung đột, xử lý xung đột khi ghi, chuyển đổi truy vấn, v.v.
• PostgreSQL đã giới thiệu logical replication cơ bản từ phiên bản 10 vào năm 2017, nhưng sao chép active-active đòi hỏi thêm các tính năng bổ sung
• Do đặc tính thiết kế của PostgreSQL, các chức năng này có thể được phát triển và áp dụng dưới dạng extension
• Cộng đồng phát triển PostgreSQL cũng đang dần bổ sung các tính năng tương ứng vào dự án cốt lõi

[GN⁺]

Ý kiến trên Hacker News

• Tổng hợp lại lịch sử phát triển của BDR, pglogical, pgactive và Postgres Distributed(PGD) từ những gì nghe được từ các đồng nghiệp trong đội 2nd Quadrant và EDB
  Bản ra đời sớm nhất và đến nay vẫn là mã nguồn mở là BDR1 (liên kết), và pgactive được xây dựng dựa trên đó
  BDR2 là bản viết lại BDR1 dưới dạng mã nguồn đóng, và cuối cùng đã bị loại bỏ
  pglogical v1 và v2 (đều là mã nguồn mở, liên kết) đã được phát hành, trong đó v1 được chỉnh sửa lớn và hợp nhất vào Postgres 10
  Dựa trên kinh nghiệm với tính năng logical replication của Postgres 10, 2nd Quadrant bắt đầu phát triển pglogical v2, và từ đây pgEdge cũng xuất hiện
  Sau đó 2nd Quadrant tạo ra pglogical v3 và BDR v3 ở dạng mã nguồn đóng, rồi hợp nhất hai thứ này thành BDR v4
  Sau đó tên sản phẩm BDR được đổi thành Postgres Distributed(PGD, liên kết)
  Sau khi 2ndQuadrant được EDB mua lại, EDB đã phát hành PGD v6
  • PostgresPro cũng có một hệ thống replication multi-master riêng liên kết tài liệu
  • Hỏi liệu PGDv6 hiện vẫn là mã nguồn đóng hay không
• Hệ thống này dùng Logical replication của Postgres để chuyển các thay đổi từ một instance sang instance khác
  Khi xảy ra xung đột, giá trị được ghi sau cùng theo timestamp sẽ là giá trị cuối cùng được áp dụng
  Lịch sử các xung đột được lưu trong một bảng đặc biệt tên là pgactive_conflict_history, nên có thể xem lịch sử và xử lý thủ công nếu cần
  Xem thêm chi tiết và tài liệu tại đây
  • Tò mò liệu cái này có được xem là multi-master replication hay không
    Nếu tính năng đó có thể chính thức được đưa vào Postgres thì sẽ khá thú vị
  • Từ góc nhìn người dùng, muốn biết liệu ghi của mình có được xác nhận ngay lập tức hay chỉ là cuối cùng sẽ hội tụ
• Hỏi có ai gần đây đã trực tiếp dùng cơ sở dữ liệu của Bloomberg là comdb2 hay chưa
• Một câu chuyện có liên quan nhưng hơi lệch chủ đề: liệu có cách nào để làm "replication cho phép ghi cục bộ (dựa trên read replica)" hay không
  Ví dụ muốn đọc dữ liệu từ production hoặc staging, nhưng chỉ sửa được ở local, và kết quả đó không bị đẩy ngược lên upstream trong một cơ sở dữ liệu thứ cấp
  Hiện tại đa phần vẫn là định kỳ chạy script (cron v.v.) để dump dữ liệu hoặc bắn truy vấn tạo snapshot, lưu lên S3 rồi kéo về local để khôi phục dữ liệu
  Cách này phần lớn hiệu quả, nhưng đôi khi thời gian build index quá lâu
  • Nhân tiện, vì các vấn đề dữ liệu nhạy cảm như thông tin cá nhân, nếu dữ liệu đi thẳng vào môi trường staging hay dev theo kiểu này thì rất rủi ro
    Do các vấn đề pháp lý và đạo đức khá lớn nên đa số công ty không khuyến nghị cách làm này
  • Nếu dùng logical replication của Postgres kèm bộ lọc thì có thể làm replication một chiều, và chỉ cần giải phóng replication slot là local có thể tự do thay đổi
    Như vậy có thể sửa bảng local mà không ảnh hưởng tới primary
  • Giữ một cơ sở dữ liệu local ở trạng thái "nguyên bản" làm bản nền, rồi mỗi khi cần thì nhân bản nó ra thành cơ sở dữ liệu cho phát triển sẽ sao chép rất nhanh mà không cần build index lại
    Khuyến nghị lệnh createdb --template
  • Tò mò nếu ghi local và cập nhật từ xa xung đột với nhau thì sẽ xử lý thế nào
    Không nghĩ ra được một chiến lược merge nào dùng được cho mọi tình huống
  • Theo như tôi biết, trong thiết lập logical replication của Postgres thì đây là hành vi tiêu chuẩn
    Replica không bị chặn ghi, chỉ là kết quả đó không lan sang nơi khác
• Cần luôn nhớ rằng thuật ngữ "Conflict resolution" rốt cuộc có nghĩa là "phá vỡ tính bền vững bằng cách bỏ đi dữ liệu đã được commit và xác nhận"
  Tốt nhất là thiết kế kiến trúc sao cho không có vùng dữ liệu ghi nào bị chồng lấn giữa các instance active
  Trong trường hợp như vậy, các công cụ như pgactive sẽ hữu ích
  Hoặc dùng hẳn cơ sở dữ liệu phân tán ngay từ đầu (như Yugabyte)
  • Tài liệu chính thức cũng khuyến nghị cách tránh xung đột bằng cách chia schema theo từng master để "mỗi master là writer duy nhất của từng schema"
    Tất cả master đều đọc được mọi schema, nhưng khi ghi thì mỗi bên chỉ phụ trách phần của mình
    Tò mò liệu ngoài schema ra thì partition v.v. có thể dùng để phân chia trách nhiệm hay không
• Khiến người ta phải nghĩ xem vì sao AWS lại làm ra thứ này
  Không dễ hình dung họ sẽ trực tiếp dùng tính năng này trong sản phẩm của mình ở đâu
  RDS dùng block replication, còn Aurora dùng SAN replication riêng
  Đoán có thể họ định tận dụng nó trong DMS gì đó
  • Có thể là vì Aurora DSQL vừa ra mắt gần đây
  • Thực ra không thấy rõ ích lợi lớn lắm
    Trong một cơ sở dữ liệu quan hệ ACID mạnh, thật khó hiểu vì sao lại cần làm thế này
  • Theo hiểu biết của tôi thì SAN replication của Aurora không được dùng cho cross region replication
  • Ngay trong readme của kho này cũng ghi rõ "trường hợp sử dụng chính là xây dựng cụm cơ sở dữ liệu Multi-Region có tính sẵn sàng cao"
  • Thực tế thì trên RDS Postgres đây đã là tính năng được cung cấp từ 2 năm trước (liên kết liên quan)
    Nhưng 1 tháng trước có tin họ chính thức công bố mã nguồn mở cho cộng đồng (thông báo chính thức)
• Đã từng vận hành nhiều cụm với repmgr, patroni để có môi trường hoàn toàn không downtime, nên plugin này là thứ tôi chỉ muốn cài như lựa chọn cuối cùng
  Muốn ngủ ngon ban đêm thì tốt nhất là tránh nó tối đa
• Tình cờ gần đây đang tìm cách dễ nhất để dựng một cụm Postgres HA có thể tự động failover, khôi phục node và point-in-time recovery
  Thấy nhiều người khuyên dùng tổ hợp patroni+etcd+haproxy, và nhìn cách những người đã dùng thực tế hào hứng đề xuất thì chắc hẳn có lý do
  Tuy vậy, khi xem file ví dụ bằng docker compose thì vẫn thấy hơi nặng nề
  Còn pgpool thì có vẻ đơn giản vì chỉ cần đặt nó phía trước từng postgres
  Muốn nghe khuyến nghị hoặc kinh nghiệm thực tế từ những người thực sự yêu thích Postgres trong môi trường production
  Mục tiêu là dựng cụm dựa trên docker compose càng đơn giản càng tốt, nhưng vẫn có độ sẵn sàng cao, (ít nhất) không mất dữ liệu, và có point-in-time recovery
  • Hỏi có phải đang tìm công cụ như Barman hay không
  • Tôi đang dùng cloudnativepg, và chỉ riêng nó thôi là phần lớn những gì cần đã hoạt động ngay
• Chia sẻ thêm tài liệu khác về pgactive và các trường hợp liên quan nếu có
  <i>Pgactive: Active-Active Replication Extension for PostgreSQL on Amazon RDS</i>
  Bài trên Hacker News (bài tháng 10 năm 2023, có 1 bình luận)
• Có vẻ đây là cơ chế bất đồng bộ, và có lẽ sẽ có vấn đề đáng kể với tính cô lập giao dịch
  • Rốt cuộc đây vẫn là một bài toán đánh đổi
    Tức là tùy tình huống mà mỗi bên phải chấp nhận ưu và nhược điểm riêng