Kafka Partition Assignment Visualizer

Leadership follows the first replica in each list

Every produce and every consumer fetch for a partition goes to that partition's leader. The first entry in a replica list is the preferred leader, and a preferred leader election puts leadership back exactly there, so the spread of first replicas is what leadership settles to whatever it happens to be right now. A reassignment that distributes replica sets evenly while starting every list with the same broker gives you an even-looking cluster that fails at one machine.

# even replicas, terrible leadership
0: [1,2,3]
1: [1,3,2]
2: [1,2,3]
  -> broker 1 holds 3 replicas, same as the others,
     and leads all three partitions

Preferred and current leadership are different numbers

After a broker restart, leadership has moved to other replicas and does not come back on its own until auto.leader.rebalance.enable acts on its own schedule, or until you run a preferred election. Paste a kafka-topics --describe output and both columns appear side by side, which is the quickest way to see how much a preferred election would actually change.

kafka-leader-election.sh --bootstrap-server broker:9092 \
  --election-type preferred --all-topic-partitions

Rack awareness is applied at creation, not maintained

With broker.rack set, Kafka spreads a new topic's replicas across racks. A manual reassignment can undo that and nothing recomputes it or complains. A partition whose replicas share a rack loses every copy when that rack does, and with min.insync.replicas=2 it stops accepting writes the moment the rack goes rather than degrading. Give this page a broker-to-rack mapping and it checks every partition against the racks available.

Under-replicated is a different problem from unbalanced

A replica outside the ISR does not count toward acks=all and cannot be elected leader without unclean election. If the in-sync count falls below min.insync.replicas the partition refuses writes, which is the setting working as intended and looks like a producer fault. Worth fixing the lag before touching any configuration, because lowering min.insync.replicas to restore writes trades away exactly the durability it was set for.

What this reads

Either a reassignment JSON, the kind kafka-reassign-partitions takes and produces, or the output of kafka-topics --describe. The second carries current leaders and ISR and so gives a fuller answer. Racks go in the box above as id=rack pairs. Nothing here contacts a cluster: it reads what you paste.