Hardening EmergencyReparentShard in v25

Vitess (PlanetScale/CNCF) · 2026 · 4. Điều chỉnh · Độ khó: Nâng cao — bài gốc

Bài của dự án mã nguồn mở; mọi nhận định là theo các maintainer.

Bối cảnh

• EmergencyReparentShard (ERS) là failover của Vitess khi primary của shard chết hoặc không liên lạc được. VTOrc dùng ERS để tự xử lý nhiều sự cố. Primary chết thì shard không ghi được, nên càng nhanh càng tốt, nhưng phải chắc giữ đúng lịch sử transaction.
• Các pha: khoá shard → dừng nhận replication và thu vị trí đã nhận/đã áp của mọi tablet còn sống (đóng băng lịch sử) → chờ áp relay log và kiểm lịch sử lạc (errant) → chọn ứng viên (luật promote, ràng buộc cell, chính sách độ bền; tablet tiến xa nhất chưa chắc là primary cuối, có thể làm nguồn trung gian cho ứng viên khác bắt kịp) → trỏ lại replica, chờ semi-sync ack sẵn sàng, ghi primary mới vào topology. Theo bài: mỗi lần chờ thêm là thêm một chỗ ERS có thể hỏng.

Ba thay đổi trong v25

1. Không chờ tablet không thể thắng. Trước v25, ERS chờ mọi tablet áp xong relay log; chỉ một tablet vượt timeout (15s ở vtctldclient, 30s ở VTOrc) là cả ERS thất bại, dù đã có replica cập nhật sẵn. Shard càng nhiều tablet càng dễ hỏng; với VTOrc nghĩa là retry hoặc phải có người trong khi shard vẫn không ghi được (báo cáo năm 2025: shard 4 tablet, một replica trễ nhiều). Sửa: dùng vị trí GTID đã nhận (đã đóng băng) để lọc ra nhóm dẫn đầu; tablet đã nhận ít hơn thì áp xong cũng không vượt lên được nên bỏ qua; trong nhóm dẫn đầu thì cho chạy đua, tablet áp xong trước đi tiếp. Chỉ áp dụng cho GTID của MySQL/Percona; file-position và MariaDB giữ cách cũ.
2. Sắp xếp ứng viên nhất quán. Tập GTID không luôn có quan hệ trước/sau (sau split-brain hay ghi lạc trên replica). Bộ sắp cũ so từng cặp, coi không so được là hoà, nên tuỳ thứ tự map hay RPC mà B có thể đứng trước A dù A có lịch sử đầy đủ hơn. Sửa: đếm số ứng viên trội hẳn mỗi ứng viên; không ai được xếp trước tablet trội hơn mình.
3. Phục hồi split-brain chặt hơn. Hai tablet mỗi bên có transaction bên kia không có thì promote bên nào cũng mất dữ liệu; lùi về một replica cũ hơn còn tệ hơn (mất cả hai phía). ERS giờ ghi nhận các leader phân kỳ; nếu lọc xong không còn đúng một leader thì thất bại kèm alias và vị trí của các leader. Người vận hành có thể chọn rõ ràng bằng --new-primary + --allow-split-brain-promotion (chỉ với leader không bị trội); đây là phục hồi có mất mát, bên thua phải dựng lại. VTOrc không bao giờ tự bật cờ này; có metric đếm mỗi lần dùng.

• Các kiểm tra cũ giữ nguyên: tablet không liên lạc được không tự động bị bỏ qua; với semi-sync, primary chết cùng một acknowledger tiềm năng không liên lạc được vẫn chặn ERS vì cặp đó có thể vẫn nhận ghi.

Bài học cho SWE

• Failover phải chọn bản có lịch sử đầy đủ nhất, nhưng không được chờ những bản không thể thắng: mỗi lần chờ thừa là một cách để failover thất bại (Failover, replica và dự phòng dữ liệu).
• Lịch sử dạng tập (GTID) chỉ có thứ tự bộ phận; thuật toán chọn phải xử lý được "không so được".
• Quyết định bỏ dữ liệu của bên nào khi split-brain là việc của người, không của automation; automation chỉ nên thất bại rõ ràng kèm bằng chứng (Tự động hoá vận hành và auto-remediation).
• Cùng hướng với Upstash 2026 (chọn theo số thứ tự ghi, từ chối promote bản thiếu): Upstash 2026.

Liên quan

• Failover, replica và dự phòng dữ liệu
• Tự động hoá vận hành và auto-remediation
• Cùng dự án: Vitess (PlanetScale/CNCF) 2022, Vitess (PlanetScale/CNCF) 2022