Kiểm thử PostgreSQL replication: replica lag, connection pool và failover

Trước hết phải xác định replication là streaming vật lý hay logical, đồng bộ hay bất đồng bộ, failover tự động hay thủ công, và thành phần nào quyết định primary. RPO bằng không trong synchronous replication không đồng nghĩa ứng dụng không lỗi; RTO ngắn không đồng nghĩa transaction retry an toàn. Những khái niệm này phải được tách riêng thành câu hỏi đo.

Bài đo nên trả lời: giao dịch nào đã được client xác nhận nhưng mất sau failover; thời gian từ sự cố đến commit thành công ổn định là bao lâu; có split-brain hoặc dual-writer hay không; pooler loại bỏ connection tới primary cũ trong bao lâu; read-after-write có trả dữ liệu cũ; và tải phục hồi có tạo reconnect storm làm primary mới quá tải không.

Topology tham chiếu gồm load generator, ứng dụng hoặc client driver, connection pool/proxy, service discovery/VIP, PostgreSQL primary, ít nhất một standby, storage và thành phần orchestration. Điểm đo phải bao gồm transaction từ client, connection/pool metrics, PostgreSQL statistics, WAL positions, system CPU/memory/disk/network và timeline của health check.

Để phân định trách nhiệm, nên giữ một luồng client đi qua đường truy cập sản xuất và một luồng kiểm soát kết nối trực tiếp tới từng database node. Khi endpoint chung lỗi nhưng node trực tiếp vẫn phục vụ, nguyên nhân nằm ở discovery, proxy hoặc pool. Đồng hồ của client, node, orchestrator và monitoring cần đồng bộ; nếu timestamp lệch, RTO và thứ tự promote/fence không đáng tin.

Workload phải gần nghiệp vụ hơn một truy vấn SELECT 1. Tối thiểu nên có read-only, point lookup, insert/update, transaction nhiều statement, commit nhỏ tần suất cao và một tỷ lệ transaction dài. Mỗi giao dịch cần ID duy nhất, client timestamp và trạng thái bắt đầu/commit/response để đối chiếu sau failover. Nếu ứng dụng có idempotency key, phải kiểm tra cả nhánh retry trùng.

Khóa phiên bản PostgreSQL, driver, pooler, orchestration, synchronous_commit, replication slot, max connections, pool size, health-check interval, DNS TTL/VIP behavior, retry/backoff và storage class. Đồng thời ghi dataset size, cache warm/cold, checkpoint/WAL settings và offered transaction rate. Không so sánh hai lần chạy nếu một lần cache nóng còn lần kia vừa restart.

• Nhóm biến: Replication · Cần ghi: physical/logical, sync/async, slots · Tác động chính: RPO, lag, recovery
• Nhóm biến: Client · Cần ghi: driver, timeout, retry, idempotency · Tác động chính: Lỗi quan sát và duplicate
• Nhóm biến: Pool/proxy · Cần ghi: mode, pool size, health check · Tác động chính: Reconnect và route tới primary
• Nhóm biến: Database · Cần ghi: version, WAL/checkpoint, connections · Tác động chính: Throughput và failover
• Nhóm biến: Hạ tầng · Cần ghi: storage latency, network, DNS/VIP · Tác động chính: Lag và RTO đầu cuối
• Nhóm biến: Workload · Cần ghi: mix, TPS, concurrency, data skew · Tác động chính: Áp lực thực tế lên primary/replica

Chạy workload theo các bậc warm-up, ramp-up và steady state. Baseline hợp lệ khi transaction rate, error rate, latency percentile, WAL generation, replica replay và tài nguyên không còn xu hướng tăng bất thường. Ghi p50/p95/p99, throughput, active/idle connections, queue wait, checkpoint time và lag cho từng standby.

Replica lag không nên chỉ đo bằng giây từ một dashboard. Cần lưu LSN gửi/ghi/flush/replay, byte lag và một “canary transaction” có ID để kiểm tra khi nào dữ liệu thực sự đọc được trên standby. Với synchronous mode, ghi rõ mức sync và số standby bắt buộc; trạng thái streaming tự nó không chứng minh commit đã được bảo vệ theo RPO mong muốn.

RTO từ góc ứng dụng nên tính từ thời điểm lỗi được chèn đến khi đạt một cửa sổ liên tiếp các transaction thành công trên primary mới. Cần công bố cả longest error burst, số lỗi theo loại, reconnect time và thời gian hệ thống trở về latency baseline. RPO phải dựa trên transaction ledger: giao dịch client nhận success nhưng không tồn tại sau failover là mất dữ liệu; giao dịch timeout nhưng sau đó tồn tại là trạng thái bất định cần reconciliation.

Raw evidence nên gồm client result, server log, orchestration log, database statistics snapshot và query reconciliation. Không lưu dữ liệu nhạy cảm trong PCAP hoặc log; nếu cần packet timing, dùng môi trường lab và ẩn payload.

• KPI: End-to-end RTO · Phương pháp: Chuỗi transaction có timestamp · Bằng chứng: Client log + timeline fault
• KPI: Effective RPO · Phương pháp: Đối chiếu acknowledged commit · Bằng chứng: Ledger trước/sau promote
• KPI: Replica lag · Phương pháp: LSN/byte/time + canary · Bằng chứng: pg_stat_replication, query xác minh
• KPI: Pool recovery · Phương pháp: Connection destination theo thời gian · Bằng chứng: Pool metrics và server log
• KPI: Duplicate write · Phương pháp: Unique key/idempotency audit · Bằng chứng: Bảng reconciliation
• KPI: Recovery capacity · Phương pháp: TPS/latency sau promote · Bằng chứng: Time series 1 giây hoặc phù hợp
• KPI: Split-brain safety · Phương pháp: Kiểm tra write trên node cũ · Bằng chứng: Fence log + transaction audit

Một kill process không đại diện cho lỗi mạng hay storage. Failover cần được kiểm tra với lỗi process, mất node, mất đường client, mất replication link một chiều, storage stall, CPU saturation và lỗi của proxy/pooler. Mỗi kịch bản phải nêu trigger, expected state transition, fencing và điều kiện phục hồi.

• Kịch bản: Dừng PostgreSQL primary · Câu hỏi chính: Promote và endpoint chuyển bao lâu · Rủi ro cần tìm: Pool giữ phiên cũ
• Kịch bản: Mất mạng client–primary · Câu hỏi chính: Orchestrator có phân biệt partition · Rủi ro cần tìm: Dual primary/split brain
• Kịch bản: Mất replication link · Câu hỏi chính: Lag tăng, policy sync phản ứng · Rủi ro cần tìm: Commit block hoặc RPO tăng
• Kịch bản: Storage latency cao · Câu hỏi chính: Health check có false positive · Rủi ro cần tìm: Failover dây chuyền
• Kịch bản: Restart pooler/proxy · Câu hỏi chính: Client retry có kiểm soát · Rủi ro cần tìm: Reconnect storm
• Kịch bản: Primary cũ trở lại · Câu hỏi chính: Có bị fence và rejoin đúng vai · Rủi ro cần tìm: Write nhầm node cũ

Checklist pass/fail phải định lượng: không có acknowledged transaction bị mất ngoài RPO; không có dual-writer; RTO trong ngưỡng; duplicate được chặn hoặc reconciliation phát hiện; pool và latency trở về baseline trong cửa sổ quy định. Nếu yêu cầu chưa có con số, đánh dấu “cần chủ hệ thống chốt”, không tự đặt chuẩn.

• Chụp inventory phiên bản, cấu hình replication, pool, endpoint và time sync.
• Tạo dataset có checksum/ID; xác nhận backup và phương án khôi phục lab.
• Chạy baseline ở tải thấp, tải mục tiêu và tải biên; lưu KPI.
• Kích hoạt canary write/read để đo vị trí dữ liệu trên primary và replica.
• Chèn một lỗi; không thay đổi đồng thời retry, timeout hoặc offered load.
• Theo dõi fencing, promote, endpoint update, connection đích và client error.
• Khi ổn định, dừng tải có kiểm soát và đối chiếu toàn bộ transaction ledger.
• Xác minh primary cũ không nhận write, sau đó kiểm tra quy trình rejoin.
• Phục hồi baseline và lặp kịch bản để lấy median/p95/worst case.
• Chạy regression với tải cao hơn và transaction dài để tìm giới hạn.

Một lần promote nhanh không chứng minh HA. Nếu workload chỉ read, dataset nhỏ hoặc cache nóng, kết quả không đại diện tải ghi. RTO nhìn từ orchestrator thường ngắn hơn RTO nhìn từ client vì còn DNS, pool, TLS, authentication và retry. Replica lag thấp khi steady state cũng không chứng minh an toàn trước burst WAL hoặc storage stall.

Kết luận chỉ áp dụng cho phiên bản, driver, topology, consistency mode và profile đã chạy. Logical replication có semantics khác physical streaming replication; dịch vụ PostgreSQL managed có control plane, SLA và phương thức failover riêng. Mọi tính năng của sản phẩm quản lý cluster hoặc pooler phải được đối chiếu tài liệu đúng phiên bản.

• WAL: Write-Ahead Log, nền tảng phục hồi và streaming replication của PostgreSQL.
• LSN: Log Sequence Number, vị trí trong WAL dùng đối chiếu tiến độ replication.
• Replica lag: Khoảng cách giữa primary và replica, có thể biểu diễn theo byte, thời gian hoặc mốc dữ liệu.
• RPO: Lượng dữ liệu có thể mất chấp nhận được sau sự cố.
• RTO: Thời gian dịch vụ cần để trở lại mức hoạt động đã định.
• Fencing: Ngăn node cũ tiếp tục ghi sau khi node khác được promote.
• Connection pool: Lớp tái sử dụng connection, có thể giữ đường tới primary cũ nếu health check không phù hợp.
• Idempotency: Thuộc tính cho phép retry mà không tạo tác dụng phụ trùng.