Kafka eligible leader replicas: when a shrunken ISR still needs a safe leader
Eligible leader replicas (ELR) let a Kafka partition elect a safe new leader when its in-sync replica set (ISR) has shrunk, so teams need them when partitions lose followers and the choice of next leader decides whether committed records survive. Without ELR, the election can only draw from the current ISR. If the ISR has shrunk to the failed leader alone, the partition either waits for a member to return or, if unclean leader election is enabled, accepts a replica that may be missing data. ELR was introduced under KIP-966 Part 1 and keeps replicas that were recently in sync as candidates, so a partition can recover without giving up data.
The strict min ISR rule is the constraint that makes ELR safe. It ties the candidate set to min.insync.replicas, so a shrunken ISR does not quietly become a basis for electing a replica that is behind. Kafka 4.0 makes the feature available and enables it with eligible.leader.replicas.version set to 1. New clusters on 4.1 have it enabled by default. Clusters upgraded to 4.0 must check whether the setting is on, and setting it to 0 downgrades the feature. Confirm the exact rule and its edge cases in the Kafka eligible leader replicas documentation before you write it into runbooks.
Before you rely on ELR, check three things on your own clusters: the Kafka version, the value of eligible.leader.replicas.version, and how your topics set min.insync.replicas and unclean.leader.election.enable. Then test a controlled broker failure on a non-production cluster that shrinks an ISR, and record which replica becomes leader and whether any acknowledged records are missing. Build that test into the upgrade plan, because changing the setting is a cluster-level decision that affects every partition, and the results decide whether you keep ELR on, disable it, or pair it with stricter producer acknowledgment settings.
Enabling eligible leader replicas on 4.0, 4.1 and upgraded clusters
A cluster built from scratch on Kafka 4.1 starts with eligible leader replicas enabled, so there is no separate enablement step. Your work moves to confirming the feature state after bootstrap and designing topics and runbooks around the strict minimum ISR rule, which changes how partitions behave when replicas fall out of sync.
- Default state: Clusters created on 4.1 have the feature on from the start. Check the state on your own cluster after bootstrap instead of assuming it from the release number.
- Topic design: Set the replication factor and min.insync.replicas together, since the eligible replica set only helps when those values leave room for it.
- Runbooks: Expect some partitions to stay unavailable during certain broker failures. Write on-call procedures that treat this as the designed safety behavior, not as a fault to clear by forcing an election.
- Version record: Record the initial version and feature settings in your configuration repository so later upgrades keep them consistent.
- Test failures: Simulate broker loss in a non-production environment so operators see the expected availability outcome before production traffic arrives.
Before go-live, confirm the default for your exact release in the Kafka eligible leader replicas documentation and record the result.
Kafka 4.0 includes eligible leader replicas, but it is not enabled by default. You turn it on by setting eligible.leader.replicas.version to 1, and you can turn it off again by setting the same key to 0. Treat this as a deliberate change with a test and a rollback plan, because it alters leader election behavior for every partition that depends on it.
- Explicit enablement: Set
eligible.leader.replicas.version=1only after every broker in the cluster runs 4.0. Confirm the exact method for applying the setting to a running cluster in the feature documentation. - Verification: After the change, check that the feature is active on the cluster before you consider the work complete. Keep the check in your change record.
- Rollback path: Setting the key to
0is the documented way to downgrade the feature. Rehearse that step in a test cluster so the team knows the sequence before it is needed. - Change window: Schedule the change when brokers are healthy and the ISR is stable, so you do not combine it with a broker restart or a partition move.
- Parity across environments: Apply the same setting in staging and production so incident behavior in staging reflects production.
For the exact enablement procedure on your release, follow the steps in the Kafka eligible leader replicas documentation and the upgrade notes that apply to your current version.
A cluster upgraded from an earlier KRaft release reaches 4.x through an upgrade path, and the feature state depends on where it ends up. The default for new clusters from 4.1 does not automatically describe an upgraded cluster, so check the state after the upgrade completes and enable the feature with the 4.0 key if it is still off.
- Upgrade path: Clusters older than 3.3.x should move to 3.9.x before they move to 4.x, according to the Kafka upgrade notes. Rolling upgrades are supported from each of the last three releases to the latest version.
- ZooKeeper clusters: Kafka 4.0 supports only KRaft, so ZooKeeper-based clusters must migrate to KRaft before any 4.x upgrade.
- Post-upgrade check: Confirm the feature state on the upgraded cluster rather than relying on the release number.
- Enablement timing: Set
eligible.leader.replicas.version=1after the cluster is fully on 4.x and stable, so the change is not mixed with mid-upgrade broker restarts. - Rollback: Keep the
0setting in the runbook in case the feature causes an unexpected availability outcome in your environment.
Before you start, read the Kafka 4.3 upgrade notes and confirm the exact steps for your starting version, since the path depends on whether your cluster is on ZooKeeper or KRaft.
Configuration options and when each fits
This table compares the values of eligible.leader.replicas.version and the situations where each applies, from a 4.0 upgrade to a fresh 4.1 or later cluster. Read it against your current release and cluster history, then confirm each setting in the 4.3 documentation before changing anything. The main takeaway is that the 4.1 default changes what you must do only on clusters that started before 4.1 or were upgraded to 4.0.
| Setting or check | What it does | When it fits or what to confirm |
|---|---|---|
| eligible.leader.replicas.version=1 | Enables eligible leader replicas so the controller keeps replicas that left the ISR as candidates for leader election | Use on a cluster upgraded to 4.0 where you want the safer election behavior when the ISR shrinks |
| eligible.leader.replicas.version=0 | Disables eligible leader replicas and returns election to the earlier ISR-only behavior | Use only when you must roll back the feature, and confirm the downgrade steps in the 4.3 documentation first |
| Enable path on 4.0 clusters | Set the version to 1 on a 4.0 cluster that has not enabled ELR | Plan a change window, confirm the exact setting method for your cluster in the 4.3 documentation, and test on a non-production cluster |
| Default on new 4.1 clusters | ELR is enabled by default on clusters created from 4.1 | Check the value on each cluster rather than assuming it, since clusters upgraded from older releases may not match new installs |
| Keep or downgrade decision | Keeping ELR preserves safer leader choices during ISR shrinkage; downgrading removes that protection | Keep it unless a documented incompatibility or a tested rollback requirement applies to your cluster |
| ELR state visible through admin tooling | Shows the eligible leader replicas for each partition so you can see candidates before an election | Confirm the tool and command in the 4.3 documentation for your release before using it in runbooks |
| Min ISR and replication settings | Strict min ISR rules govern whether writes proceed when replicas fall out of sync | Review min.insync.replicas and replication factor together with ELR, since they set how many candidates exist |
Enabling and verifying eligible leader replicas step by step
This sequence confirms the cluster is on a supported release in KRaft mode, turns eligible leader replicas on or confirms the default, and proves the cluster behaves correctly before anyone relies on it in production.
Confirm a supported release and KRaft mode
Check which Kafka version every broker and controller runs, and confirm the cluster uses KRaft rather than ZooKeeper. The supported releases listed on the downloads page are 4.3.1, 4.2.2 and 4.1.2, so a cluster on an archived version needs its own upgrade plan first. ZooKeeper-based clusters must migrate to KRaft before moving to 4.x. Done when every node reports a supported version and no node depends on ZooKeeper. Confirm the exact version commands and output against the 4.3 page.
Check the cluster's current ELR state
Before changing anything, record whether eligible leader replicas are already active and at what level, using the ELR check described on the 4.3 eligible leader replicas page. Run the check on the controller quorum that owns cluster metadata. Save the output with the change record so you can compare it after the change. Confirm the exact command and expected fields against the 4.3 page before running it.
Set the ELR version flag on Kafka 4.0
On a cluster running Kafka 4.0, eligible leader replicas are off until you enable them with the feature version setting eligible.leader.replicas.version set to 1. Apply the change with the Kafka feature tooling from the 4.3 page, following its rules for upgrading the metadata feature level. Do not expect a broker restart to do this for you. Done when the check from the previous step reports the feature at version 1. Confirm the exact flag syntax and any required ordering against the 4.3 page.
Confirm the default on Kafka 4.1 and later
On new clusters from 4.1, eligible leader replicas are enabled by default, so the step is verification rather than configuration. Compare the state recorded earlier with the expected default for your version. If a cluster that started on 4.1 or later shows the feature disabled, investigate how it was provisioned or upgraded before changing anything. Done when the feature state matches the documented default for your release. Confirm the expected output against the 4.3 page.
Apply the change in line with the upgrade notes
If your change requires any broker or controller restart or a rolling change, follow the sequence in the Kafka upgrade notes for your version and the 4.3 page on eligible leader replicas. Change one node at a time where the docs call for it, and keep enough brokers in service to hold the replication factor. Done when every node reports the same version and feature state and the cluster is healthy with no under-replicated partitions. Confirm the restart requirements against the 4.3 page.
Verify ELR state across partitions
Run the ELR check again and compare it with the baseline. Look at partitions that have a shrunken in-sync replica set and confirm they show eligible leader replicas where expected. Check that topic-level minimum in-sync replica settings match your intent, because the strict minimum ISR rule governs how ELR behaves. Done when the post-change output shows the feature active and the partitions you care about are tracked. Confirm field names against the 4.3 page.
Test failover in a non-production cluster
In a non-production cluster that matches your production topology, shut down brokers so that the in-sync replica set shrinks, then confirm that leader election behaves as you expect and that no committed data is lost. Repeat the test with the feature disabled if you need a comparison. Record the partitions that stayed available and the ones that did not. Done when the results match your written expectations and you have a signed-off test record. Use the failover steps on the 4.3 page as the reference for what to expect.
Document the state and the rollback path
Record the final version, feature level, verification output and test results in your change log. Write down the downgrade procedure from the 4.3 page, which sets the version flag back to 0 on a cluster that supports it, and who approves using it. Schedule a repeat of the ELR check after each future upgrade, because feature state is part of the cluster you run. Done when the runbook lists the commands, the expected outputs and the owner of each check.
Downgrading and what changes when ELR is turned off
On a Kafka 4.0 cluster, eligible leader replicas are switched on with eligible.leader.replicas.version=1 and can be switched off by setting it to 0. The cards below cover the change itself, the checks before and after it, and the risk of altering leader election on partitions that are already serving traffic.
The 4.0 downgrade setting
On a cluster running Kafka 4.0, the downgrade is a single config change: set eligible.leader.replicas.version to 0. This is the documented route back from the feature that is enabled by default on new clusters from 4.1. Confirm that your cluster is on 4.0 and that the change is applied through the tooling your team uses for dynamic configuration, then record the exact command and the time it ran so the change can be traced later.
Recording the current state
Before changing anything, capture the value of eligible.leader.replicas.version as it stands, along with the broker version, the topics with the lowest replication settings and any open incidents. The current value should be 1 on a 4.0 cluster where the feature was enabled. If the value is missing or different, stop and find out why, because the rollback plan depends on knowing the starting point.
Leader election on live partitions
Turning the feature off changes which replicas the controller can consider when a partition loses its leader and the in-sync replica set shrinks. The effect applies to partitions already in service, not only to new topics. Ask your Kafka operator or the project documentation which partitions are affected, and schedule the change for a window in which a leader failover would be tolerable, because leadership moves can briefly interrupt producers and consumers.
Checking ELR state after the change
After the change, verify that the new value is visible on every broker and that partitions which previously tracked eligible replicas now report the expected state. Compare the post-change output with the record taken beforehand, looking for partitions that stayed below their replication target, leaders that moved unexpectedly and consumer lag that did not recover. Keep the comparison in the change record so that any later disagreement can be traced to a point in time.
Planning for a later re-enable
Turning the feature off is not the end of the decision. Setting the value back to 1 on the same 4.0 cluster is a second configuration change with its own effect on leader election, so the reversal needs the same checks as the original. Agree on who can approve it, which partitions will be watched and what result would trigger a rollback, before the downgrade begins, so the team does not improvise under an incident.
Confirming behavior on newer releases
The 4.0 downgrade path does not settle how a 4.1 or later cluster should behave, because the feature is enabled by default on new clusters from 4.1. Before disabling it on any cluster that is not running 4.0, confirm with the official upgrade notes and the ELR documentation whether the same setting applies and what it changes. Treat any unverified assumption about a newer release as a question for the vendor and your own test cluster, not as a reason to skip the check.
Questions teams ask before enabling eligible leader replicas
Does enabling eligible leader replicas cost anything extra?
The feature itself carries no license fee because Apache Kafka is licensed under the Apache License 2.0 and the project offers no paid edition. The cost comes from the people and time needed to plan the change, test it on a non-production cluster and watch it after go-live. Ask any partner to split the quote into planning, configuration, testing and handover, and to state which parts are one-time and which recur, such as periodic reviews during upgrades. Infrastructure costs stay roughly the same because ELR changes how leaders are chosen, not how much data is stored.
How long does it take to turn on eligible leader replicas?
The configuration change on a supported cluster is small, but the surrounding work sets the duration: confirming your Kafka version, checking topic and replication settings, rehearsing the change and agreeing a rollback plan. Timing depends on how many clusters you run and how carefully each one is tested. No fixed duration applies to every environment, so ask for a schedule that lists each stage and the owner of each stage before work begins.
Which Kafka version do we need before we can use it?
Eligible leader replicas is available from Kafka 4.0. On a 4.0 cluster it is enabled by setting eligible.leader.replicas.version to 1, and it is enabled by default on new clusters from 4.1. The supported releases listed on the Kafka downloads page are 4.3.1, 4.2.2 and 4.1.2, so confirm the exact release you run against the Kafka 4.3 eligible leader replicas documentation before planning. Clusters on older releases need an upgrade first, and the upgrade path itself is a separate planning item.
What does the team need to provide before the work starts?
You need a current inventory of clusters, their Kafka versions, broker counts, topic replication factors and min.insync.replicas values. You also need the change window rules, access to a staging cluster that mirrors production topology, and a named owner who can approve a leader election behavior change. Producer acknowledgment settings and client retry behavior should be documented, because they determine how writes behave during a shrunken ISR. Confirm these items in writing with any partner so scope is agreed before the first change.
Can our own platform team do this without outside help?
Yes, if your team already operates Kafka in KRaft mode, understands replication and can run controlled tests. The configuration change is simple, but the decision needs judgment about which topics tolerate a longer wait for a leader and which must never elect an out-of-date replica. A small team often handles the change internally and brings in help for the review of topic settings, failure testing or a multi-cluster rollout. Decide early who signs off on the risk.
When should we bring in an implementation partner?
Bring in help when you run many clusters, when topics are shared across teams with different durability needs, or when no one on staff has tested leader failover recently. A partner is also useful when your change process requires documented test evidence for a compliance review. DeployOpen plans, implements, tests and documents self-hosted Kafka inside your own infrastructure under a written, fixed scope, so you know the deliverables before the work starts. Ask for the test plan and the handover document as named deliverables.
What changes for operations after go-live?
After go-live, leader elections can wait for an eligible replica instead of picking any replica that has fallen out of sync, which lowers the chance of data loss but can extend unavailability for affected partitions. Your monitoring should track ELR state, ISR shrinkage and partitions without a leader, and your runbooks should say who decides when to accept a longer outage. Review the setting again at each Kafka upgrade. If you ever need to revert, the documented downgrade sets eligible.leader.replicas.version back to 0 on 4.0 clusters, so include that step in the rollback plan.
Official Kafka documentation for eligible leader replicas
The next read for this topic is the Apache Kafka 4.3 eligible leader replicas page, which describes how the feature changes leader election when the in-sync replica set shrinks and which settings control it. Read it before you change any configuration, because the behavior you get depends on the Kafka version your cluster runs and on how the cluster was created. The page is the reference for eligible.leader.replicas.version, the config key that turns the feature on or off on clusters upgraded to 4.0, and for the downgrade path back to version 0. Treat the documentation as the source of truth for your exact release, and confirm with your platform team which version each cluster is actually running before you copy any example.
The Kafka 4.3 eligible leader replicas documentation is the page to bring into a design review. Use it to confirm three things for your environment: whether the cluster was created on 4.1 or later, where ELR is enabled by default, and whether a cluster upgraded from 4.0 has the feature switched on. If the cluster was upgraded from an earlier line, check the version-specific steps in the Kafka 4.3 upgrade notes first, since those notes also cover the requirement that KRaft clusters older than 3.3.x move to 3.9.x before 4.x. Record the results in your change ticket so that the next upgrade does not depend on memory.
The Kafka 4.3 upgrade notes hold the version-specific steps that the feature page does not repeat, including Java runtime requirements for brokers and tools and the rule that ZooKeeper-based clusters must migrate to KRaft before moving to 4.x. Read them alongside the feature page and build your rollout plan from both. Ask your team to confirm the current supported release list on the Kafka downloads page before scheduling any upgrade, because patch releases for supported lines are published as needed.
How DeployOpen scopes and delivers Kafka replication safety work
DeployOpen plans and implements Kafka eligible leader replicas (KIP-966) on self-hosted clusters in infrastructure you control. We start from your current version, your ISR behavior and your availability and durability requirements, then agree the change in writing before any cluster is touched.
How we scope
- Confirm the running Kafka version and whether the cluster was upgraded to 4.0 or built new on 4.1 or later.
- Record the min.insync.replicas settings and replication factor for every topic that needs ELR protection.
- Agree in writing which clusters, environments and downgrade steps are in the fixed-scope deliverables.
How we build
- Set eligible.leader.replicas.version on the 4.0 cluster in a staging environment before any production change.
- Test leader election under controlled broker stops and confirm ELR membership behaves as the documentation describes.
- Check ELR state with the Kafka admin tooling and capture the results as evidence for the change record.
How we hand over
- Document the enablement, the downgrade path by setting the version back to 0, and the rollback steps.
- Provide a runbook covering ELR state checks, expected election behavior and escalation when the ISR shrinks.
- Walk your operations team through the runbook and the open items that still need your confirmation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope covers re-checking ELR state after each Kafka upgrade within the supported release line.
- Ask for the support scope, response expectations and upgrade coverage in writing before you sign.
