Jepsen: Amazon RDS for PostgreSQL 17.4

Bài tóm tắt Jepsen 2025 3. Quy mô lớn Độ khó: Khó

Jepsen · 2025 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Báo cáo ngắn, "khảo sát sơ bộ" theo lời Jepsen; không fault injection.

Bối cảnh

  • RDS for PostgreSQL Multi-AZ cluster: replication đồng bộ (ghi bền trên primary và ít nhất một secondary trước khi ack); endpoint ghi và endpoint đọc. Secondary không hỗ trợ Serializable, nên mức mạnh nhất trên mọi node là "Repeatable Read" của Postgres, thực chất là Snapshot Isolation.

Thay đổi chính (kết quả)

  • Trên cụm khoẻ, khoảng 150 transaction ghi/giây + 1.600 transaction đọc/giây, Elle thấy chu trình G-nonadjacent vài phút một lần, gồm Long Fork: hai nhánh cập nhật hai dòng khác nhau, mỗi nhánh không thấy nhánh kia. Vi phạm Snapshot Isolation; không thấy trên Postgres thường. Không thấy Short Fork (write skew), nên có thể RDS cho Parallel Snapshot Isolation, yếu hơn một chút.
  • Xuất hiện ở mọi bản thử, từ 13.15 tới 17.4.
  • Nguyên nhân (cập nhật 3/5, do kỹ sư AWS và người bình luận HN chỉ ra, đã được nêu trong mailing list Postgres từ 2013): primary công bố transaction theo thứ tự một lock trong bộ nhớ, secondary theo thứ tự trong WAL; hai thứ tự có thể khác nhau.
  • Khuyến nghị tạm: chỉ dùng endpoint ghi, hoặc cho mọi transaction quan trọng có ít nhất một lần ghi.

Vì sao

  • Đọc từ replica tạo một nguồn thứ tự thứ hai; "đồng bộ" ở mức độ bền không có nghĩa đồng bộ ở thứ tự hiển thị.

Bài học cho SWE

  • Replica đọc có thể yếu hơn mức isolation ghi trên tên; kiểm bất biến khi đọc lẫn từ primary và replica.
  • Lỗi chỉ hiện ở cụm (không ở một node) cần test trên cấu hình triển khai thật.

Liên quan