...

1. For the existing unclean.leader.election.enable

   1. If true, unclean.recovery.strategy will be set to Proactive.

   2. If false, unclean.recovery.strategy will be set to Balanced.

2. unclean.recovery.strategy is guarded by the metadata version. Ideally, it should be enabled with the same MV with the ELR change.

3. The unclean leader election behavior is kept before the MV upgrade.

Delivery plan

The KIP is a large plan, it can be across multiple quarters. So we have to consider how to deliver the project in phases.

As the Unclean Recovery can be developed in parallel with the ELR, let's discuss what would be the expected behavior if only one of them have has delivered.

• ELR. The main difference is in the leader election and the unclean leader election.
  • The unclean leader election will remain the same as the current. No change to the unclean.leader.election.enable and the behavior is random select an unfenced replica as the leader.
  • Leader election will be different when ISR and ELR are both empty. In this case, we try to maintain the "last known leader" behavior. Basically, when the last leader gets fenced, the LastKnownELR field will be also updated. The last leader will be put at the front of the LastKnownELR list. Then if the last leader can be unfenced, it will be elected as the leader. In this way, if only ELR is delivered, there is no regression in availability.
• Unclean recovery. 
  • The unclean leader election will be replaced by the unclean recovery.
  • unclean.leader.election.enable will only be replaced by the unclean.recovery.strategy after ELR is delivered.
  • As there is no change to the ISR, the "last known leader" behavior is maintained.

...