Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#4,269 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

  • #4273 de @platinumhamburg — cerrado sin fusionar

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
java
Área
databases, distributed-systems

Línea de trabajo

Empieza con ReassignmentLeaderElection y el protocolo de replicación, y después reproduce la secuencia de tres réplicas descrita en el issue. Rastrea el cambio de líder, el HW del follower y el LEO local durante la reasignación; se considera terminado cuando una migración limpia establece un prefijo de log común antes de que se confirme una escritura acks=-1.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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!
Lenguaje dominante
Java
Estrellas
2.2k
Forks
646
Merge medio
2 d 28 min
PR fusionados (30 d)
128

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/fluss

Todos los issues de apache/fluss

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.