Postgres High Availability with CDC

PlanetScale · 2025 · 3. Quy mô lớn · Độ khó: Nâng cao — bài gốc

Bài khái niệm của nhà cung cấp (PlanetScale bán cả MySQL/Vitess lẫn Postgres); mọi nhận định là theo PlanetScale.

Bối cảnh

CDC từ database là chuyện thường. Theo PlanetScale, thiết kế replication của Postgres làm CDC ràng buộc với HA theo cách khó vận hành.

Cách Postgres làm

Cụm chuẩn: một primary, hai standby semi-sync (ANY 1 (r1, r2)), một client CDC đọc logical replication slot (pgoutput), poll vài giờ một lần.
Slot là đối tượng bền nằm cục bộ trên primary, giữ restart_lsn (WAL cũ nhất cần) và confirmed_flush_lsn (vị trí subscriber đã xác nhận). Slot ghim WAL trên primary tới khi client tiến lên.
Postgres 17 có failover slot (đồng bộ trạng thái slot sang ứng viên promote), nhưng standby chỉ đủ điều kiện mang slot sau khi subscriber đã đẩy slot tiến ít nhất một lần trong lúc standby đó đang theo dõi. Điều kiện sẵn sàng: slot đã sync, vị trí khớp với standby, slot bền và chưa bị vô hiệu.
Các ca hỏng:
1. CDC im lâu, slot trên standby ở trạng thái tạm; buộc failover thì luồng CDC gãy, phải khởi tạo lại connector và snapshot lại;
2. thay replica (basebackup mới): replica mới chưa đủ điều kiện cho tới lần poll tiếp của CDC (ví dụ 6 giờ); mọi switchover trong lúc đó hoặc phải chờ hoặc làm gãy CDC;
3. slot vật lý của một standby ngừng kéo WAL ghim restart_lsn mãi, có thể làm đầy volume WAL của primary và mất khả năng ghi.
Gốc rễ: tiến độ của consumer nằm trong catalog cục bộ của primary, không đi theo WAL (failover slot của bản 17 có ghi vào WAL nhưng vẫn chờ subscriber). Slot chậm nhất quyết định hệ đi được bao xa mà không cần người. Một thao tác giữ availability ghi bị ràng buộc vào hành vi của một hệ downstream bên ngoài.

Cách MySQL làm

Binlog là log hành động, mỗi transaction có GTID; replica bật log_replica_updates ghi lại transaction vào binlog của chính nó với cùng GTID.
Connector CDC chỉ lưu tập GTID đã xử lý; nối lại với bất kỳ server phù hợp và nói "tiếp từ GTID này". Không có slot, không có điều kiện đủ tư cách.
Failover: promote replica, trỏ connector vào replica bất kỳ. Thành công chỉ phụ thuộc retention của binlog; consumer chậm không chặn được switchover, tệ nhất là connector phải snapshot lại.

Bài học cho SWE

Khi chọn database, xét cả CDC tương tác với HA thế nào, không chỉ hiệu năng (Chọn database theo workload).
Trạng thái tiến độ của consumer nên đi theo log (vị trí toàn cục như GTID) thay vì nằm trên một node; nếu không, failover phụ thuộc vào consumer (Độ tin cậy và multi-region).
Một consumer chậm có thể ghim tài nguyên của producer (WAL) tới mức làm hỏng ghi; cần giám sát và giới hạn.
Cùng đề tài GTID làm failover tự động hoá được: Meta 2014.