Failover, replica và dự phòng dữ liệu

Bài toán

Mọi hệ có trạng thái đều giữ nhiều bản (replica) để một máy chết không làm mất dịch vụ. Khó không nằm ở việc có bản sao mà ở lúc chuyển sang bản sao:

• Chọn bản nào: replica trễ vài giây vẫn trả lời; promote nó là bỏ đi các ghi đã xác nhận (RPO). Bao lâu thì xong (RTO)?
• Ai quyết định: người theo runbook, hay automation, và automation sai thì sao?
• Bản sao bảo vệ cái gì: replication bảo vệ availability, không bảo vệ khỏi lỗi của chính mình (xoá nhầm, dữ liệu hỏng được nhân bản ngay).
• Hai bên cùng ghi (active-active) thì xung đột ghi giải thế nào?
• Đường dự phòng có còn chạy khi cần không?

Trang này nói về cơ chế bên trong một cụm hay một kho dữ liệu. Kiến trúc nhiều vùng/AZ (dồn tải giữa region, cell, data residency) nằm ở Độ tin cậy và multi-region; máy tự phát hiện và tự sửa nói chung nằm ở Tự động hoá vận hành và auto-remediation.

Diễn tiến theo thời gian

• 2006 · Google: trước Chubby, phần lớn hệ bầu primary bằng cơ chế tự chế hoặc cần người can thiệp. Chubby là dịch vụ khoá thô (cell 5 replica, Paxos bầu master) mà GFS, Bigtable dùng để bầu primary; failover master có grace period để giữ session của client. Theo paper, code failover chạy ít nên nhiều bug nhất. Google 2006
• 2011→2015 · LinkedIn (Espresso): Helix: node chết thì ephemeral node ZooKeeper mất, một slave mỗi partition được nâng master; trong khoảng ngắn partition không nhận ghi nhưng router vẫn đọc từ slave. SCN = generation (tăng mỗi lần đổi master) + sequence để phân biệt ghi của master cũ và mới. LinkedIn 2015
• 2011 · LMAX: (theo LMAX qua lời kể của Fowler) ba bản Business Logic Processor (hai ở DC chính, một ở DR) cùng xử lý mọi event đầu vào, chỉ dùng output của một bản; leader định thứ tự tất định qua replicator; chuyển bản trong micro giây, khởi động lại mỗi đêm không downtime. LMAX 2011
• 2011 · Airbnb: RDS Multi-AZ giữ master sống; slave cho analytics treo cả ngày, khắc phục bằng trỏ job nền và indexer sang master. Airbnb 2011
• 2012 · MemSQL: snapshot + log là một cơ chế dùng cho ba việc: khôi phục sau khởi động lại, độ bền, và dựng slave mới online (gửi snapshot rồi replay log). Replication đồng bộ (k-safety, ghi chậm hơn) hoặc bất đồng bộ (trễ vài ms, failover mất phần delta); không làm master-master vì mất nhất quán (theo MemSQL qua HighScalability). MemSQL 2012
• 2013 · Jepsen: "Chịu f−1 lỗi" nghĩa là có lúc chỉ leader giữ ghi đã ack; bầu node tụt hậu làm leader thì nhánh ghi của leader cũ bị xoá. Jepsen 2013
• 2014 · Facebook: bật GTID cho mọi MySQL bằng cách sửa MySQL để nâng cấp từng replica rồi promote; GTID + semi-sync cho phép promote replica trong 30 giây không mất dữ liệu. Meta 2014
• 2014 · Booking.com: hàng nghìn slave MySQL nên crash là chuyện thường. MySQL 5.5 lưu vị trí replication không nguyên tử với dữ liệu (chạy lại transaction, "Duplicate entry", có khi hỏng âm thầm); 5.6 sửa phía SQL thread nhưng phục hồi IO thread bằng cách tải lại binlog từ master, đè lên card mạng master. Họ đặt Binlog Server cục bộ trên mỗi slave. Booking.com 2014
• 2014 · Dropbox: Master + hai replica không giúp khi automation xoá cả cặp; RTO thật là thời gian khôi phục MySQL lớn từ backup, nên họ viết công cụ replay binlog song song. Dropbox 2014
• 2015 · Booking.com: parallel replication của MariaDB 10.0/MySQL 5.7 lấy độ song song từ binlog group commit của master, nhưng intermediate master tính lại nhóm khi ghi binlog của mình, nên theo đo trên workload production, nó chia độ song song cho tầng sau 2 đến gần 4 lần; lời giải theo Booking là thay intermediate master bằng Binlog Server chuyển nguyên văn binlog. Booking.com 2015 Intermediate master ở DC xa nằm trên đĩa dùng chung (DRBD/SAN) để chịu hỏng máy nên phải sync_binlog = 1; đơn luồng thì trần khoảng 500–1000 transaction/giây. Slave group commit chia chi phí sync cho cả nhóm và giữ được nhịp master kể cả khi tắt write cache. Booking.com 2015
• 2015 · Booking.com: replication đơn luồng của MySQL giới hạn ghi của master ở khoảng một core nếu không muốn lag. Đo parallel replication (MariaDB 10.0) trên 4 môi trường production bằng cách đuổi kịp 24 giờ transaction thật: chỉ 1,3 đến 2,1 lần; với workload CPU-bound, đơn luồng + giảm độ bền còn nhanh hơn. Transaction dài không đều làm tắc pipeline. Theo Booking, parallel replication không phải lời giải để tránh sharding. Booking.com 2015
• 2016 · Quora: Game Day: giả định mất toàn bộ production và backup, dựng lại Quora ở us-west-2 chỉ từ backup nhân bản, mất chưa tới 5 giờ (MySQL khoảng 2 giờ, HBase khoảng 5 giờ). Lộ ra quota instance tổng, phụ thuộc thứ tự restore, tên máy hardcode, AMI cũ. Quora 2016
• 2016 · Booking.com: optimistic parallel replication (MariaDB 10.1): chạy mọi transaction song song, giữ commit đúng thứ tự, phát hiện deadlock ngoài tầm storage engine thì rollback và chạy lại. Tốt hơn kiểu bảo thủ ở mọi môi trường; tăng tốc vẫn tăng khi luồng vượt xa số core vì prefetch IO; tốt nhất 3,78 lần lại ở workload IO-bound. 27 CREATE TABLE mỗi giây (DDL chặn pipeline) là nút thắt nghi vấn. Booking.com 2016
• 2016 · Netflix (billing): master MySQL trên EC2 có bản DRBD đồng bộ ở zone khác (mất một node không mất dữ liệu, đổi lại latency ghi), read replica cùng và khác region gánh ETL; failover sang bản DRBD rồi đổi Route53, ứng dụng batch chịu được khoảng gián đoạn. Netflix 2016
• 2017 · GoCardless: Pacemaker không promote được replica (do một luật colocation -INF + hai crash cùng lúc), biến sự cố 1–2 phút thành 1 giờ 50 phút. Bài học tự nêu: có bug chỉ lộ qua fault injection; tự động hoá làm mai một kỹ năng thao tác tay. GoCardless 2017
• 2017 · Twilio: queue Ratequeue (Redis shard, primary + replica) từ failover tay (20 phút trở lên, dễ sai) sang tự động khoảng 1 phút: replica ping primary, Nagios → Kinesis → dịch vụ Lazarus kiểm tra cả cụm rồi promote. Không dùng Redis Sentinel vì nó xoá dữ liệu primary cũ sau phân vùng mạng. Chaos test (Gremlin tắt primary) mỗi 4 giờ trên staging. Twilio 2017
• 2017 · etcd: kho đồng thuận mạnh thêm node là thêm độ bền nhưng ghi chậm đi; muốn nhanh thì scale dọc. Tối thiểu 3 thành viên trên 2 AZ; ASG dùng để giữ số node (tự chữa lành), không dùng để co giãn. Độ bền ba lớp: replication, snapshot v3 đẩy lên S3, EBS tách vòng đời khỏi máy. etcd 2017
• 2017 · GitLab: hot standby duy nhất trễ tới mức WAL cần thiết đã bị xoá (không có WAL archiving), phải dựng lại bằng tay; trong lúc đó primary bị xoá nhầm, nên cả hai bản đều mất. Replication chỉ là failover, không phải backup; hai năm sau GitLab thêm replica trễ 8 giờ (GitLab 2019). GitLab 2017
• 2017 · LinkedIn (Venice): Helix delayed rebalance: node chập chờn ngắn thì chưa dời partition (rẻ hơn đọc lại partition lớn); replica luôn bootstrap từ Kafka nên phục hồi được kể cả khi mất mọi replica. LinkedIn 2017
• 2018 · Alibaba: RDS MySQL bản HA dùng active–standby qua binlog; PolarDB tách compute khỏi storage dùng chung, replication vật lý bằng redo log, nên standby/read node không phải đuổi kịp dữ liệu: trễ mức mili giây, failover dưới 30 giây (theo Alibaba). Alibaba 2018
• 2018→2019 · Riot Games: Redis Cluster trong container: replica hỏng (nhận lại IP cũ, UUID mới) nằm im ở vai secondary và chỉ lộ khi primary chết và nó được promote, trông như mất hai node cùng lúc; bầu leader bằng cách đua ghi vào service discovery nhất quán cuối cùng làm hai node cùng thắng, nên đổi sang chờ đủ 7 node rồi gán vai theo thứ tự IP; master OOM kéo replica chết theo vì đầy cùng tốc độ. Chỉ fault injection lặp lại hàng trăm lần mới đi qua được đường promote. Riot Games 2019
• 2018 · Heroku: Dùng HA standby làm đường nâng cấp: kiểm standby đồng bộ, cắt replication, đổi config var của app sang primary mới, bỏ primary cũ và tạo standby mới. Heroku 2018
• 2019 · GitLab: replica trễ 8 giờ để quay ngược lỗi của con người (xoá nhầm), khôi phục trong 90 phút thay vì ~5 giờ tải base backup. Theo GitLab, replication bảo vệ availability chứ không thay được backup. GitLab 2019
• 2019 · Walmart: mỗi database của microservice replicate async độc lập nên bên dự phòng có thể không nhất quán giữa các service; khi failover, một service "bully" phát lại n phút thay đổi gần nhất (n phủ độ trễ replication) và mọi consumer idempotent. Walmart 2019
• 2019 · Airbnb: Thông tin idempotency chỉ đọc/ghi ở master: replica lag vài giây đủ để retry không thấy kết quả và trả tiền lần nữa. Scale master bằng shard theo idempotency key. Airbnb 2019
• 2020 · CapitalOne (khái niệm): active-active shared-nothing ở tầng DB khác high availability: nhân bản bất đồng bộ nên có xung đột ghi và hỏng dữ liệu âm thầm, mọi cách giải xung đột đều là vứt bỏ một thay đổi. Hợp với cache hay session hơn là system of record; mẫu thực tế nhất là ứng dụng tự ghi vào từng DB, không nhân bản giữa DB. CapitalOne 2020
• 2020→2025 · Fly.io (Litestream): SQLite sao chép liên tục lên object storage; bản mới dùng định dạng LTX có compaction (khôi phục không phải phát lại mọi thay đổi) và lease bằng conditional write của S3/Tigris để chỉ một instance ghi vào một đích, thay cho Consul của LiteFS. Fly.io 2025
• 2020 · LinkedIn (HDFS): NameNode HA (Quorum Journal Manager 3 node + VIP) bỏ được restart tới một giờ khi nâng cấp, thành rolling upgrade; sau đó Standby được cho phục vụ đọc (Observer) có nhất quán mạnh (bài 2021). LinkedIn 2021
• 2020 · Basecamp: Failover LB tự động nhưng router không theo kịp, phải can thiệp tay hai ngày liền; replication Redis liên DC bất đồng bộ thành full resync đánh sập primary. Basecamp 2020
• 2021→2022 · Fly.io: Postgres HA bằng Stolon với trạng thái cụm trong Consul; Consul sập hay xa là proxy đánh rơi mọi kết nối. Sửa bằng HAProxy hỏi thẳng từng node vai trò của nó, và đặt cụm Consul gần primary. Theo Fly.io, HA tự động thêm một kiểu hỏng; một node đơn lẻ còn đáng tin hơn. Fly.io 2022
• 2021 · Pinterest: hai pipeline streaming hot-hot cô lập (hai cụm Kafka, deploy so le), phía đọc tự chọn pipeline khoẻ. Pinterest 2021
• 2021 · CapitalOne: stack active-active hai region nhưng promote replica Postgres chéo region mất 10–15 phút; so Aurora Global (failover khoảng 1 phút), Aurora Multi-Master (chỉ một region), DynamoDB Global Tables (active-active, không cần failover). Chọn DynamoDB; theo team, thời gian failover giảm 99%. CapitalOne 2021
• 2021→2025 · etcd: dữ liệu membership sai lan qua snapshot: learner mới nhận snapshot từ thành viên cũ mang trạng thái sai, nên sửa code chưa đủ, phải khởi động lại hoặc đăng ký lại mọi thành viên để làm sạch trạng thái đã ghi. etcd (CNCF) 2025
• 2022 · Vitess: VTOrc (fork của Orchestrator thành thành phần gốc của Vitess) đọc topology mong muốn từ topology server thay vì tự dò, dùng shard lock có sẵn để nhiều instance cùng giám sát mà không promote hai primary, chỉ giữ dữ liệu tạm, tự biết tablet đang backup để không "sửa" nó. Vitess (PlanetScale/CNCF) 2022
• 2023 · Twitter: trước khi drain/reboot broker Kafka phải qua dịch vụ ràng buộc, kiểm tra under-replication và số máy được rút cùng lúc; va chạm giữa các operator và automation từng làm cụm thiếu replica. Twitter 2023
• 2023 · ClickHouse: DWH nội bộ chạy mọi insert với insert_quorum=3 (đủ cả ba replica) thay vì mặc định eventual consistency, để bước ELT sau không đọc thiếu; không dùng quorum auto vì khi một node đang nâng cấp, thà insert lỗi rồi Airflow retry còn hơn node vừa khởi động lại thiếu dữ liệu. Ghi idempotent làm retry an toàn. ClickHouse 2023
• 2023 · Jepsen: read replica của AWS RDS MySQL mặc định không giữ thứ tự commit (replica_preserve_commit_order=OFF, trong khi MySQL từ 8.0.27 mặc định ON), nên đọc ở mức Serializable từ replica thấy "fractured read bắc cầu"; vài phút test làm replication của RDS dừng hẳn. Jepsen 2023
• 2023 · Stack Overflow: mở rộng SQL Server AG từ on-prem sang VM trên Azure để đồng bộ dữ liệu; failover AG liên tục timeout vì độ trễ nên phải ép node Azure thành primary, rồi restore một node on-prem và nối lại để vẫn fail-back được. Stack Overflow 2023
• 2024 · Render: HA cho Postgres managed: standby bất đồng bộ (trễ vài giây) trên phần cứng tách biệt; primary không phản hồi 30 giây thì trỏ URL sang standby, gián đoạn dưới một phút; dùng chính failover cho bảo trì định kỳ. Render 2024
• 2025 · Cloudflare: Workers KV từng chạy active-active trên hai object storage bên thứ ba, rút về một để giảm phức tạp; 12/6/2025 bên còn lại sập hơn 2 giờ, kéo theo Access, Gateway, WARP. Đường dự phòng cũ đã mục nên không bật lại được; họ dựng backend thứ hai của chính mình, ghi đua hai bên, đối soát ba lớp (khi ghi, khi đọc, crawler nền). Cloudflare 2025
• 2025 · PlanetScale: theo PlanetScale, logical slot của Postgres nằm cục bộ trên primary nên failover phụ thuộc consumer CDC (standby chỉ đủ điều kiện sau khi subscriber tiến slot); MySQL dùng GTID nên connector nối lại với replica bất kỳ. PlanetScale 2025
• 2025 · Alibaba: PolarDB dùng storage chia sẻ nên RPO = 0; chọn primary bằng lease + I/O fence trên chính storage (VotingDisk) thay vì ZooKeeper hay Paxos; RO dự phòng giữ sẵn buffer pool/undo/redo trong RAM; proxy giữ session và chuyển tiếp giao dịch đang chạy sang primary mới. Theo Alibaba (nhà cung cấp). Alibaba 2025
• 2025→2026 · TigerBeetle: replica hội tụ giống nhau từng byte nên khi mỗi replica thiếu một phần block, nó chỉ lấy đúng block thiếu từ replica khác thay vì chép toàn bộ trạng thái; mô phỏng tất định kiểm bất biến này cho từng replica. TigerBeetle 2026
• 2025 · Jepsen: Replication đồng bộ về độ bền vẫn lệch thứ tự hiển thị: primary theo thứ tự lock trong bộ nhớ, secondary theo thứ tự WAL; tạm tránh bằng chỉ dùng endpoint ghi. Jepsen 2025
• 2025 · Jepsen: Bitflip hay cắt cụt file trên thiểu số node vẫn có thể làm cụm Raft mất dữ liệu hoặc node tự xoá stream. Jepsen 2025
• 2026 · Stripe: khoảng 2.000 shard MongoDB tự sửa bằng tìm đường trên đồ thị trạng thái (BFS rồi Dijkstra) với bất biến an toàn (quorum, số vote lẻ), xử lý được nhiều lỗi cùng lúc và trạng thái dở dang mà automation dạng plugin bó tay. Số lần gọi người trực giảm 30%. Stripe 2026
• 2026 · Upstash: sau vụ mất một AZ tháng 5/2026, mô tả failover Redis multi-AZ: replica có số thứ tự ghi cao nhất thắng bầu; không có bản đủ mới thì tạm dừng ghi thay vì promote bản thiếu; split-brain thì trộn theo timestamp tới mức field; primary làm chậm ghi khi replica trễ; DNS cũng phải nhiều AZ. Theo Upstash. Upstash 2026
• 2026 · GitHub: cụm Elasticsearch trải qua primary và replica của GitHub Enterprise Server tạo phụ thuộc vòng khi bảo trì (replica chờ Elasticsearch khoẻ, Elasticsearch chờ replica); chuyển sang cụm một node + Cross Cluster Replication để khớp mẫu leader/follower. GitHub 2026
• 2026 · Vitess: EmergencyReparentShard v25: đóng băng vị trí GTID đã nhận, bỏ qua tablet không thể thắng thay vì chờ chúng áp relay log (trước đây một replica trễ là timeout cả failover), chạy đua trong nhóm dẫn đầu; sắp ứng viên theo quan hệ trội vì tập GTID chỉ có thứ tự bộ phận; split-brain thì thất bại rõ ràng, chọn bên giữ dữ liệu là việc của người (VTOrc không bao giờ tự làm). Vitess (PlanetScale/CNCF) 2026
• 2026 · Alibaba (nhà cung cấp): khung bốn mức rủi ro (process, máy, DC, thành phố) và RPO/RTO; theo Alibaba, semi-sync tụt về bất đồng bộ khi trễ nên không phải RPO = 0; PolarDB-X dùng Paxos (2 replica + 1 logger, trọng số bầu); hai DC cùng thành phố thì mất DC giữ leader vẫn cần người, ba DC mới tự động hoàn toàn. Alibaba 2026
• 2026 · TigerBeetle: coi MTTR là giới hạn thiết kế: dựng lại một replica 128 TiB mất khoảng 6 giờ, nếu MTTR > MTBF thì hệ vào vòng xoắn chết. Giới hạn kích thước replicated state machine (ví dụ 16 TiB) và đẩy dữ liệu lạnh xuống object storage để thời gian hồi phục có trần (theo TigerBeetle). TigerBeetle 2026
• 2026 · ClickHouse: viết lại WAL-G bằng Rust (WAL-RUS) để WAL archival có bộ nhớ dự đoán được trên máy Postgres chật; tương thích hai chiều archive và cấu hình với WAL-G. Theo ClickHouse (nhà cung cấp). ClickHouse 2026
• 2026 · Upstash: failover tự động che việc mất một replica, nên mỗi replica có check riêng và mất một replica là sự cố dù khách không thấy. Upstash 2026
• 2026 · Redpanda: hai kiểu sao chép cho Kafka API (theo nhà cung cấp). Shadow link bất đồng bộ, chạy trong broker cụm đích, giữ nguyên offset, sao cả offset consumer, ACL, schema; topic bóng chỉ đọc tới khi failover; đo được RPO khoảng 4 ms ở 2,5 GiB/s. Stretch cluster một cụm Raft trải nhiều region: ack khi đa số đã lưu nên RPO = 0, không có bước promote. Redpanda 2026 Redpanda 2026
• 2026 · Alibaba: RocketMQ một replica trên cloud disk, failover không thêm bản sao dữ liệu: node dự bị thấy đĩa qua Multi-Attach, quyền ghi rào bằng NVMe Persistent Reservation; phát hiện lỗi bằng tiến độ lease trên đĩa chung (bắt được I/O treo) thay vì heartbeat. Theo Alibaba, từ vài phút xuống vài giây, hàng chục nghìn lần diễn tập (bài giới thiệu paper). Alibaba 2026
• 2026 · PlanetScale: so ba cách backup Postgres: pg_dump (hợp migration; ở 30 TB tranh tài nguyên, không có PITR, giữ snapshot lâu có thể dẫn tới transaction wraparound), file system (phải tắt database), continuous archiving (base backup lúc chạy + WAL có full page write; wal-g stream WAL lên S3). PlanetScale backup mỗi 12 giờ để giới hạn WAL phải phát lại, và chụp backup trên node dùng một lần dựng từ backup cũ để không đụng primary. PlanetScale 2026
• 2026 · GitHub: Spokes giữ mỗi repo đầy đủ trên đĩa của năm fileserver, cập nhật ref bằng three-phase commit theo quorum; cùng một cơ chế lo cả độ bền lẫn scale đọc, nên thêm replica để đỡ đọc làm ghi chậm đi, mất quorum là dừng ghi. Kiến trúc mới đặt bản có thẩm quyền trên Azure Blob và đọc qua worker có cache; benchmark nội bộ ghi cao tới 35 lần (theo GitHub). GitHub 2026
• 2026 · Neon: replica không cứu được khi lệnh ghi sai đã sang cả standby, nên thời gian PITR mới là con số quyết định. Theo Neon, PITR trên Postgres managed truyền thống (dựng instance, nạp snapshot từ S3 lười, replay WAL) mất hàng giờ với DB lớn; khi storage giữ lịch sử bất biến, restore là tạo branch tại một LSN, tính bằng giây. Neon 2026
• 2026 · NVIDIA (nhà cung cấp): hot standby cho engine LLM trên cùng GPU: weight dùng chung qua GPU Memory Service, standby khởi tạo sẵn nhưng không giữ KV cache, bầu active bằng flock mà kernel tự nhả khi process chết; giết một trong hai worker: 283 giây (cold restart) so với 7,3 giây. Chỉ phủ lỗi process, lỗi node/phần cứng vẫn reschedule. NVIDIA 2026
• 2026 · WhatsApp/Meta: Backup Key Vault là đội HSM phân tán nhiều data center, chịu lỗi bằng replication theo đa số; đội mới chỉ dựng vài năm một lần và sẽ công bố bằng chứng mỗi lần. WhatsApp 2026

Các lựa chọn và đánh đổi

Quy tắc rút ra

1. Failover tự động cũng là một hệ thống phải kiểm thử bằng lỗi thật, và tự động hoá làm mai một kỹ năng thao tác tay (GoCardless 2017: Pacemaker chạy tốt 2 năm rồi không promote được).
2. Replication bảo vệ availability, backup bảo vệ dữ liệu; replica trễ là cửa sổ để quay ngược lỗi của con người (GitLab 2019). Backup chỉ có giá trị nếu đã restore thử, kể cả phụ thuộc thứ tự restore và quota (Quora 2016).
3. Failover không mất dữ liệu cần từ chối promote bản thiếu: chọn replica có số thứ tự ghi cao nhất, không có thì tạm dừng ghi (Upstash 2026).
4. Tiến độ replication nên nằm trong log, không nằm trên một node: GTID làm promote và nối lại consumer dễ (Facebook 2014, PlanetScale 2025); trạng thái cục bộ (relay log, logical slot) làm failover và phục hồi phụ thuộc node đó (Booking.com 2014, Postgres theo PlanetScale).
5. Đường dự phòng không chạy thì mục: rút dự phòng để giảm phức tạp rồi không bật lại được (Cloudflare 2025). Active-active chọn ở phía đọc giữ đường dự phòng luôn "nóng" (Pinterest 2021).
6. Active-active ghi nhân bản không phải HA miễn phí: chỉ hợp cho dữ liệu chịu được mất một thay đổi (CapitalOne 2020); với dữ liệu chính, chọn một nơi ghi hoặc đối soát có version (Cloudflare 2025, Upstash 2026).
7. HA tự động thêm phụ thuộc mới (kho đồng thuận, cụm trải nhiều node); đặt nó ra khỏi đường đi nóng và khớp mô hình HA của nó với hệ chứa nó (Fly.io 2022, GitHub 2026).
8. Phục hồi của một replica không được đổ tải lên primary dùng chung (Booking.com 2014).
9. Thời gian hồi phục là giới hạn thiết kế: replica càng lớn thì dựng lại càng lâu, cửa sổ mất thêm một máy càng dài; giới hạn kích thước phần nóng để MTTR có trần (TigerBeetle 2026).
10. Muốn bỏ hẳn failover chéo region thì phải đổi mô hình dữ liệu sang active-active nhất quán cuối, và trả giá bằng mất query linh hoạt (CapitalOne 2021); Render 2024 cho thấy hướng ngược lại: giữ single-primary, làm failover nhanh và chạy nó thường xuyên khi bảo trì.
11. Dự phòng không được kiểm chứng thì không phải dự phòng: failover tự động che việc mất bản sao, nên phải giám sát và cảnh báo trên từng replica (Upstash 2026) và kiểm tra under-replication trước khi rút máy bảo trì (Twitter 2023).
12. Ở hệ nhiều service, RPO của từng database không cộng lại thành một điểm phục hồi chung; cần log thay đổi + phát lại + idempotent ở tầng ứng dụng (Walmart 2019).
13. Bản sao để failover phải mang theo mọi thứ client cần, không chỉ dữ liệu: offset consumer, ACL, schema, cấu hình; giữ nguyên offset thì failover chỉ là trỏ client sang cụm mới (Redpanda 2026, theo nhà cung cấp).
14. Sync quorum trải ≥3 miền lỗi đổi độ trễ ghi lấy RPO = 0 và không có bước promote; async giữ ghi nhanh nhưng luôn còn cửa sổ mất dữ liệu — chọn theo loại dữ liệu (Redpanda 2026 stretch cluster vs shadow link).
15. Nếu storage đã tự dự phòng, HA có thể là bài toán chuyển quyền ghi, không phải thêm bản sao: rào ghi ở tầng storage (fencing) và đo "còn ghi bền không" thay vì "còn sống không" (Alibaba 2026, RocketMQ; cùng hướng PolarDB 2025).
16. Backup để migration (logical) khác backup để khôi phục thảm hoạ (physical + WAL): chu kỳ base backup giới hạn lượng WAL phải phát lại, tức là núm vặn thời gian restore; chụp backup trên node phụ để không tranh tài nguyên với primary (PlanetScale 2026). PlanetScale 2026
17. Khi replica vừa để bền vừa để phục vụ đọc, thêm replica làm ghi chậm đi: tách lớp bền (object storage) khỏi lớp phục vụ (worker có cache) để scale từng bên, và để mất một máy chỉ như cache miss (GitHub 2026). GitHub 2026
18. Bầu leader nên là một dịch vụ dùng chung, không phải mỗi hệ tự chế (Chubby 2006); client của nó phải chịu được leader đổi mà không tự khuếch đại sự cố. Google 2006
19. Replication lag là trần ghi của cả cụm, không chỉ là độ tươi của replica: replication đơn luồng giới hạn master ở khoảng một core; parallel replication chỉ giúp 1,3 đến 3,8 lần tuỳ workload và kiểu (bảo thủ hay lạc quan), transaction lớn không đều và DDL làm tắc pipeline (Booking 2015, 2016); mỗi tầng relay tính lại nhóm commit còn chia nhỏ độ song song thêm, nên tầng chuyển tiếp nên chuyển nguyên văn (Binlog Server). Booking.com 2015 Booking.com 2015 Booking.com 2016
20. Hệ đồng thuận mạnh thêm node là thêm độ bền, không thêm tốc độ (etcd 2017); và replica không thay được PITR khi lỗi logic đã nhân bản, nên thời gian restore phải được biết trước (Neon 2026). etcd 2017 Neon 2026
21. Hot standby rẻ khi phần đắt nhất được tách khỏi vòng đời process và dùng chung; trong cùng máy, cơ chế kernel tự dọn khi process chết (file lock) đủ để bầu active, không cần lease. NVIDIA 2026

Câu hỏi mở

• RPO=0 xuyên region có giá bao nhiêu latency? WarpStream nói khoảng 80–100 ms p50 (WarpStream 2025); chưa có nguồn đối chiếu từ phía DB quan hệ.
• Postmortem mất dữ liệu thật: đã có GitLab 2017 (GitLab 2017), nhưng gốc là thao tác tay khi dựng lại replica và backup hỏng, không phải failover sai. Vẫn thiếu nguồn về mất dữ liệu do promote replica trễ hay split-brain trong production.
• Upstash trộn sau split-brain bằng timestamp; chưa nguồn nào đo tần suất mất ghi do cách này.
• Liên hệ: Độ tin cậy và multi-region (kiến trúc nhiều vùng/AZ), Tự động hoá vận hành và auto-remediation (automation failover), Sự cố và postmortem, Migration không downtime (replica logic dùng để migrate), Chọn database theo workload (CDC và HA khi chọn DB), Tách compute khỏi storage (lớp bền tách khỏi lớp phục vụ).
• Liên hệ: Batching và khấu hao round-trip (group commit khấu hao fsync, cũng là nguồn độ song song cho replica).
• Liên hệ: Hạ tầng phục vụ LLM inference (cold start GPU, autoscale theo in-flight, canary model, shadow engine).