Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Server] Clean leader reassignment can leave divergent WAL in an ISR replica

Đang mở
  • Có gì không ổn?
#4,269 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

  • #4273 của @platinumhamburg — đã đóng, không merge

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
30/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
databases, distributed-systems

Hướng nghiên cứu

Bắt đầu với ReassignmentLeaderElection và replication protocol, sau đó tái hiện chuỗi ba replica được mô tả trong issue. Theo dõi thay đổi leader, HW của follower và LEO cục bộ trong quá trình phân công lại; được xem là hoàn tất khi một quá trình migration sạch thiết lập một tiền tố log chung trước khi một lần ghi acks=-1 được xác nhận.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Search before asking
  • I searched in the issues and found nothing similar.
Fluss version

0.9.0 (latest release)

Please describe the bug 🐞

A clean leader reassignment can leave replicas with different records at the same offsets, while the new leader acknowledges writes with acks=-1 and all replicas remain in the ISR.

This was reproduced using a regular Log Table without secondary indexes.

Steps to reproduce

Use three replicas, A, B, and C, with A as leader and ISR [A, B, C]. All offset ranges below are half-open.

  1. Append and commit a common prefix [0,10) on all three replicas.
  2. Append another batch [10,15) to A with acks=1. Deliver its replication response only to C. B remains at offset 10 and stays in the ISR; A's HW remains 10.
  3. Perform a clean leader reassignment to B using ReassignmentLeaderElection.
  4. Append different records to B. Since B's LEO is 10, these records occupy [10,15).
  5. Resume replication from B to A and C.

Actual behavior

The write in step 4 completes successfully with acks=-1, but the replicas contain:

Replica HW Records at offsets 10–14
A 15 New records from B
B, current leader 15 New records
C, still in ISR 15 Old records from A

The previously committed prefix [0,10) remains intact. The inconsistency affects the replacement records acknowledged by the new leader.

Solution

The replication protocol needs to establish a common log prefix when leadership changes, rather than treating matching offsets as proof of matching history. Leader-epoch-based reconciliation and the relationship between follower HW and local LEO need to be considered together.

Append offset-continuity checks alone would not detect this case because the divergent records occupy the same offsets.

Related work

Tracked under #673.

This issue documents a reproducible WAL divergence during a normal,
clean ISR leader migration: a write can be acknowledged while ISR
replicas retain different records at the same offsets.

Related implementation work: #778, #788, and #789.

Are you willing to submit a PR?
  • I'm willing to submit a PR!
Ngôn ngữ chính
Java
Star
2.2k
Fork
656
Merge trung bình
1 ngày 21 giờ
Pull request đã merge (30 ngày)
127

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/fluss

Tất cả issue của apache/fluss

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.