Je vois un comportement différent avec acks all. De la documentation,

acks = all Cela signifie que le leader attendra le jeu complet de répliques synchronisées pour accuser réception de l'enregistrement. Cela garantit que l'enregistrement ne sera pas perdu tant qu'au moins un réplica synchronisé reste actif. Il s'agit de la garantie disponible la plus solide. Cela équivaut au paramètre acks = -1.

J'avais une configuration de 3 courtiers et un sujet avec un facteur de réplication 3. Ma compréhension de la déclaration ci-dessus est que le leader attendra si l'un des courtiers est en panne (car il * attendra que ISR reconnaisse * le dossier Mais, à ma grande surprise, ce n'est pas le cas, le message est produit et consommé par le consommateur.

Est-ce que cela n'est pas honoré dans ce cas?

2
Nag 27 oct. 2020 à 13:46

2 réponses

Meilleure réponse

Le acks = all est honoré par rapport au paramètre de courtier min.insync.replicas qui par défaut est 1; c'est la raison pour laquelle vous voyez votre producteur envoyer sans problème et le consommateur consommer aussi. Dans votre cas, avec 3 courtiers, si vous voulez que le producteur puisse envoyer uniquement quand TOUS sont en cours d'exécution, vous devez également définir min.insync.replicas = 3.

1
ppatierno 27 oct. 2020 à 10:59

On dirait que cela doit être interprété avec min.insync.replicas .

Lorsqu'un producteur définit acks sur "all" (ou "-1"), min.insync.replicas spécifie le nombre minimum de répliques qui doivent accuser réception d'une écriture pour que l'écriture soit considérée comme réussie. Si ce minimum ne peut pas être atteint, le producteur lèvera une exception (NotEnoughReplicas ou NotEnoughReplicasAfterAppend). Lorsqu'ils sont utilisés ensemble, min.insync.replicas et acks vous permettent de renforcer les garanties de durabilité.

0
Nag 27 oct. 2020 à 10:48