How we used delayed replication for disaster recovery with PostgreSQL

GitLab · 2019 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

GitLab.com (2/2019): khoảng 3 triệu user, gần 7 triệu project; theo GitLab là một trong những site SaaS single-tenant mã nguồn mở lớn nhất. Postgres là thành phần sống còn.
Sự cố cụ thể: một user xoá nhầm một label của project gitlab-ce, kéo theo mất liên kết của label với issue và merge request.
Replication không phải backup: một lệnh DELETE/DROP TABLE được replicate gần như ngay tới mọi replica.

Thay đổi chính

PITR (point-in-time recovery): base backup định kỳ + lưu trữ WAL (trên Google Cloud Storage) để khôi phục về bất kỳ thời điểm nào.
Delayed replica: một replica áp WAL trễ 8 giờ (recovery_min_apply_delay = '8h'), đọc WAL từ archive (archive recovery) thay vì streaming, vì đơn giản hơn và tránh các bẫy của streaming kèm độ trễ (replication slot, hot standby feedback). Postgres chỉ trì hoãn bản ghi COMMIT: dữ liệu được áp ngay nhưng chỉ hiện ra sau khi hết thời gian trễ.
Quy trình khôi phục:
1. tạm dừng replay ngay khi biết sự cố (pg_xlog_replay_pause()) để replica không áp lệnh DELETE;
2. bỏ độ trễ, đặt recovery_target_time ngay trước thời điểm xoá (chừa một khoảng sai số; nếu vượt qua thì phải làm lại từ đầu);
3. replica bắt kịp đúng tới thời điểm đó;
4. xuất dữ liệu bị mất rồi nhập lại vào production (không promote replica, để khỏi mất dữ liệu mới).
Cách chính xác hơn là khôi phục theo transaction ID (recovery_target_xid) nếu đã log ID của DDL.

Kết quả

Khôi phục mất 50 phút (~110 GB WAL/giờ, archive lúc đó trên S3); dữ liệu được khôi phục 90 phút sau khi bắt đầu xử lý. So với cold backup: không phải tải base backup ~2 TB (~5 giờ) rồi áp tới 24 giờ WAL.

Vì sao

Theo GitLab: delayed replica là lựa chọn đầu tiên khi lỗi được phát hiện trong khoảng trễ. Nó còn liên tục kiểm thử khả năng PITR từ archive (lag của replica bất thường thì biết ngay archive WAL có vấn đề). Vẫn cần cold backup cho các trường hợp như hỏng cả data center, hỏng dữ liệu âm thầm.

Bài học cho SWE

Replication bảo vệ availability, backup bảo vệ dữ liệu. Delayed replica nằm ở giữa: một cửa sổ để quay ngược lỗi của con người.
Một cơ chế khôi phục có ích khi nó được dùng thường xuyên, và vì vậy được kiểm thử liên tục. Cùng tinh thần "diễn tập thật" trong Độ tin cậy và multi-region.
Log transaction ID của các lệnh nguy hiểm để khôi phục chính xác hơn.