A counting argument
The fix is a counting argument, and the whole idea fits in one line. Require every decision to be approved by a majority of your cluster.
See why that works, because it is arithmetic and not engineering. Any two majorities of the same set must share at least one member, and that member will not vote for two different leaders in the same term.
Split a five-machine cluster into three and two, then, and only the side holding three can elect anybody. The side with two does not become a second leader. It becomes unavailable, and that is the correct outcome: it stops instead of diverging.
Recognise the trade you just made in the abstract. Under partition, consensus chooses consistency and gives up availability on the minority side. That is not a compromise to apologise for. It is the guarantee you were buying.
Sizing the cluster
Size your cluster from the rule that follows, because this catches people in interviews. You tolerate failures up to just under half.
Three machines tolerate one failure. Five tolerate two. Four also tolerate only one, because a majority of four is three, so losing two leaves you short. Four cost more, add a hop across the network to every write, and buy you nothing over three.
Always choose an odd number, and in practice three for most things, five when the cluster matters enough to survive a failure during maintenance.
Size with intent rather than instinct. More members buys availability against several failures at once, and costs write latency, because every commit waits for a majority to acknowledge. Seven members is usually somebody confusing consensus with replication.
Worked example
A team runs etcd with 3 nodes across 3 availability zones. An AZ goes dark. The 2 surviving nodes form a majority, elect a leader in about 400 ms, and the cluster keeps serving with no human involved. Six months later, wanting more safety, someone adds a 4th node in an existing AZ. The next AZ failure takes 2 of the 4 nodes and leaves 2, which is not a majority of 4, so the cluster stops accepting writes entirely and every service depending on it for leader election blocks. The extra node did not add a nine, it removed one. They go to 5 across 3 AZs, which tolerates 2 failures, and write latency rises from 1.8 ms to 2.6 ms as the price.