Me and my shadow (link!): Disaster recovery replication made easy

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

Bài của nhà cung cấp giới thiệu tính năng của chính họ (Shadowing, bản enterprise). Mọi nhận định ghi "theo Redpanda". Đọc cùng Redpanda 2026 (bản đồng bộ, RPO = 0).

Bối cảnh

• DR cho dữ liệu streaming gần như luôn là sao chép liên tục sang cụm khác. Hai đại lượng: RTO (bao lâu chạy lại được) và RPO (mất bao nhiêu dữ liệu, đo bằng thời gian).
• Cách cũ: công cụ ngoài như MirrorMaker 2 chạy trên một cụm riêng; offset ở cụm đích khác cụm nguồn nên phải dịch offset, có thể sinh bản trùng khi link chập chờn.
• Sao chép cũng dùng cho migration nền tảng (backfill rồi giữ đồng bộ) và phân phối dữ liệu theo region.

Thay đổi chính

• Shadow link chạy ngay trong broker của cụm đích, đọc từ cụm nguồn bằng Kafka API thường; cụm nguồn không biết có link (chỉ thấy thêm tải đọc).
• Sao chép: dữ liệu topic giữ nguyên offset, timestamp, header, batch; cấu hình topic; offset đã commit của consumer group; ACL; schema registry (tuỳ chọn).
• Mô hình active-passive, bất đồng bộ: producer chỉ được ack khi ghi xong ở cụm nguồn; topic bóng chỉ đọc cho tới khi failover, để không lệch nội dung. Failover theo từng topic hoặc cả link; chỉ xoá link khi mọi luồng đã failover.
• Reciprocal active-passive: hai cụm, mỗi cụm vừa là nguồn vừa là bóng của cụm kia, đặt tiền tố tên topic theo site (a_, b_); consumer đọc cả topic local lẫn topic bóng; phải chọn một site chính cho schema registry.
• Số đo của tác giả (2026): nguồn 2,5 GiB/s, 2,5 triệu message/giây, lag tổng dưới 10.000 message, tức RPO hiệu dụng khoảng 4 ms trung bình.

Vì sao

• Theo Redpanda: giữ offset thì failover chỉ là trỏ consumer sang cụm mới và đọc tiếp, không dịch offset, không replay sinh trùng.
• Chạy trong broker nên không cần cụm thứ ba cho tác vụ sao chép, dùng phần dư của cụm sẵn có.
• Đơn giản làm failover thành việc diễn tập thường xuyên được, cho bằng chứng thật về khả năng DR thay vì giả định.

Bài học cho SWE

• Async replication luôn có cửa sổ mất dữ liệu (RPO > 0); hỏi xem cửa sổ đó đo được và nhỏ cỡ nào (Failover, replica và dự phòng dữ liệu).
• Thứ cần sao chép không chỉ là dữ liệu: offset consumer, ACL, schema, cấu hình; thiếu một cái thì failover kẹt.
• Bản sao chỉ đọc cho tới lúc failover tránh hai bên cùng ghi và lệch nhau.
• Hai region cùng active có thể dựng bằng hai link ngược chiều và quy ước đặt tên (Độ tin cậy và multi-region).

Liên quan

• Redpanda 2026 (đồng bộ Raft giữa region) · Redpanda 2025
• WarpStream 2026 (sao chép giữ offset để migrate Kafka)
• Failover, replica và dự phòng dữ liệu · Độ tin cậy và multi-region