Hi Jose, Thanks for the KIP. Just a minor question about this:
> This means that the leader will not allow followers to join the ISR until it has recovered from the unclean leader election. If I understand correctly, the main reason for this is to avoid the need to propagate the "IsUnclean" flag between elections. It ensures that we cannot have a "clean" election until the recovery has completed. On the other hand, if we need to do another unclean election because the recovering leader failed, then we would get the "IsUnclean" flag naturally. Are there any additional limitations we should consider while the unclean leader is recovering? For example, should we not allow consumers to read from the partition until the recovery has completed as well? By the way, I do find the naming of the "IsUnclean" field a tad awkward. The naming suggests that it reflects upon the election, but then it is strange that the election becomes clean through recovery (which obviously cannot restore the lost data). An alternative name might be "UncleanRecoveryRequired." Another option might be to consider it more of a partition state. After an unclean election, then the state might be UNCLEAN_ELECTED. After recovery, it might transition to UNCLEAN_RECOVERED. Then at least we keep track of the fact that the current leader was uncleanly elected. Not sure how important that is, just a thought.. Best, Jason On Mon, Jan 10, 2022 at 11:47 AM José Armando García Sancio <jsan...@confluent.io.invalid> wrote: > Hi all, > > I would like to open the discussion on implementing "KIP-704: Send a > hint to broker if it is an unclean leader." See this wiki page for > details: https://cwiki.apache.org/confluence/x/kAZRCg > > Thanks! > -- > -Jose >
