Replication, durability và leader failure
Replication factor, in-sync replicas, producer acknowledgements và min.insync.replicas kết hợp thành policy về write availability và tolerated data loss.
acks=all một mình chưa đủ. Durability còn phụ thuộc replica count/placement, ISR health, minimum ISR, idempotence, unclean election và thời điểm failure.1. Leader, followers và ISR
Mỗi partition có một leader phục vụ produce và phần lớn fetch; followers sao chép log. In-sync replica (ISR) là replica theo kịp leader trong ngưỡng được broker xác định. Controller theo dõi leadership và chọn leader mới khi node/replica fail.
| State | Ý nghĩa | Operational signal |
|---|---|---|
| Leader online | Partition phục vụ request | Leader balance, request latency |
| Follower in ISR | Đủ đồng bộ để eligible leadership | ISR size/shrink/expand |
| Under-replicated | ISR nhỏ hơn replication factor | Giảm redundancy, catch-up lag |
| Offline partition | Không có leader usable | Read/write unavailable |
| Unclean leader | Out-of-sync replica được chọn | Có thể mất records |
Leader election và client metadata refresh tạo latency spike. Client phải refresh metadata/retry bounded; không coi transient NOT_LEADER_OR_FOLLOWER là business failure vĩnh viễn.
2. Producer acks và minimum ISR
acks=0 không chờ broker response; acks=1 chờ leader append; acks=all chờ các in-sync replicas theo replication protocol. min.insync.replicas khiến leader từ chối write với acks=all khi ISR dưới ngưỡng, đổi availability để giữ redundancy.
Ví dụ replication factor 3 và minimum ISR 2 cho phép một replica unavailable mà vẫn write; khi chỉ còn một ISR, write fail thay vì accept với một copy. Nếu producer dùng acks=1, minimum ISR không tạo cùng bảo vệ.
3. Idempotent producer, retries và ordering
Idempotent producer dùng producer ID, epoch và sequence để broker deduplicate retries trong producer session/partition. Nó bảo vệ duplicate do retry protocol, không deduplicate business event được publish lại từ process mới hoặc outbox replay; vẫn cần event/business ID.
Timeout không chứng minh record chưa append. Retry cần idempotence và compatible max.in.flight.requests.per.connection/acks/retries settings để không reorder. Delivery timeout phải bao trùm retry budget nhưng vẫn bounded theo caller SLA.
4. High watermark và read visibility
Replica progress quyết định high watermark; consumers không đọc records vượt committed boundary theo normal semantics. Transactional consumers với read_committed còn dùng last stable offset để ẩn aborted/open transactions, có thể làm visible lag khác log end offset.
Producer ack, broker commit và consumer visibility là các mốc khác nhau. Observability cần phân biệt request success, log end, high watermark và consumer committed/processed offsets.
5. Failure domains và reassignment
Replica placement phải trải broker, rack và availability zone theo topology awareness. Replication factor 3 trong cùng failure domain không chịu được domain loss. Rack-aware placement giảm correlated loss nhưng cross-zone traffic/cost và latency cần budget.
Partition reassignment, leader balancing và replica catch-up tiêu disk/network, cạnh tranh production traffic. Throttle và canary batches, theo dõi under-replication/latency, không di chuyển hàng loạt trong lúc cluster đã saturated.
6. DR và operational evidence
Replication trong một cluster không phải backup hay disaster recovery xuyên region. Operator delete, bad retention/config, credential compromise hoặc logical corruption có thể ảnh hưởng toàn cluster. Cross-cluster replication cần define direction, lag/RPO, topic/config/ACL coverage, failover ownership và failback reconciliation.
Theo dõi offline/under-replicated partitions, ISR changes, unclean elections, leader imbalance, produce/fetch latency, request errors, disk/network saturation và reassignment progress. Chaos test broker/rack loss với producer confirms và consumer reconciliation.