Disaster Recovery for Databases: High-availability Architecture of PolarDB-X

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

Bài của nhà cung cấp (Alibaba Cloud) giới thiệu sản phẩm; mọi nhận định và con số là theo Alibaba Cloud. Giá trị chính là khung phân loại rủi ro và bảng đánh đổi giữa các kiểu replication.

Khung khái niệm

• Bốn mức rủi ro: process (OOM, segfault; xác suất cao, ảnh hưởng một service) → máy (kernel panic, hỏng đĩa) → data center (mất điện, đứt cáp) → thành phố (động đất, lũ; xác suất rất thấp). Mỗi mức cần một cách bảo vệ riêng.
• RPO (mất tối đa bao nhiêu dữ liệu) phản ánh cách và tần suất backup; RTO (gián đoạn tối đa bao lâu) phản ánh tốc độ khôi phục. Tiêu chuẩn Trung Quốc GB/T 20988-2025 chia 6 mức, mức cao nhất RPO = 0 và RTO vài phút.
• Ba lớp bảo vệ: backup toàn phần định kỳ (chống lỗi logic như xoá nhầm bảng, nhưng RPO bằng chu kỳ backup), backup log tăng dần (khôi phục tới thời điểm bất kỳ, RPO bằng độ trễ của log backup gần nhất), đồng bộ replica thời gian thực.
• So sánh replication (theo bài): đồng bộ (RPO = 0, chậm, mất phân vùng là ngừng); bất đồng bộ (nhanh, mất dữ liệu, failover cần người kiểm); semi-sync (gần 0, khi trễ thì tụt về bất đồng bộ nên vẫn có thể mất); đồng thuận đa số Paxos/Raft (RPO = 0, failover tự động trong vài giây, sống nếu còn đa số).

Kiến trúc PolarDB-X

• Compute node không trạng thái (2PC cho giao dịch phân tán), data node (DN) chạy Paxos, metadata và bộ cấp timestamp toàn cục (GMS) là một cụm DN, node CDC và node columnar có trạng thái lưu ở GMS/OSS nên dựng lại được. HA của cả cụm rốt cuộc dựa vào HA của DN: theo bài RPO = 0, RTO dưới 8 giây.
• XPaxos (bản Paxos mở rộng): leader mạnh, tự failover khi số node hỏng chưa quá nửa; trọng số bầu để định trước thứ tự leader; replica logger (chỉ giữ log, không dữ liệu, rẻ) và learner (không bầu, phục vụ đọc); leader mới không bắt kịp trong cửa sổ cho phép thì tự chuyển cho node không trễ; dùng binlog làm log Paxos (bỏ bước relay log).
• Topology triển khai theo mức rủi ro, thường 2 replica đầy đủ + 1 logger với trọng số 9/9/1:
  • một máy (chỉ cho test); nhiều máy trong một DC;
  • hai DC cùng thành phố: mất DC giữ leader thì cần người ép promote (theo bài khoảng 50% trường hợp mất DC không tự động được); bốn replica chia đều hai DC thì mất DC nào hay phân vùng giữa hai DC cũng cần người;
  • ba DC cùng thành phố, mỗi DC một node: mất bất kỳ DC nào vẫn tự động (khuyên cho nghiệp vụ lõi);
  • ba DC ở hai thành phố: mất thành phố giữ leader vẫn cần người.

Bài học cho SWE

• Chọn kiến trúc dự phòng bắt đầu từ mức rủi ro muốn chịu và RPO/RTO, không từ công nghệ (Failover, replica và dự phòng dữ liệu).
• Semi-sync không phải RPO = 0: khi trễ nó tụt về bất đồng bộ.
• Hai địa điểm không đủ cho failover tự động dưới đồng thuận đa số; cần địa điểm thứ ba (có thể chỉ là logger rẻ) để phân xử (Độ tin cậy và multi-region).
• Backup và replication chống hai loại rủi ro khác nhau (lỗi logic và hỏng hạ tầng), cùng ý với GitLab 2019 (GitLab 2019).

Liên quan

• Failover, replica và dự phòng dữ liệu
• Độ tin cậy và multi-region