This blog was written in response to a question about the differences between a three node MySQL cluster and a two-node-plus-a-witness MySQL cluster. In summary, the two-plus-witness configuration reduces MySQL high availability (HA) capabilities; but let me explain in a little more detail…
Firstly, quorum is important in a cluster, in fact in any HA scenario - this isn’t unique to MySQL database clustering. The principle being that in the event of a failure, the nodes “vote” on what action to take. With an even number of nodes you could end up in a situation where you do not get a majority result, so you need an odd number of nodes to ensure the voting ALWAYS produces a majority result. If you’re interested to learn more, check out this blog: Why Does a MySQL / MariaDB Cluster Require an Odd Number of Nodes?
Having an odd number of nodes is important, but we recognise that for some customers the costs/overheads of having three full database nodes doesn’t work for them, or perhaps their applications can cope with the slightly raised risk, or the application isn’t read heavy and therefore doesn’t require horizontal scaling capacity (at least not right now). So let’s dive into the pros and cons of each scenario:
|Three (3) full database nodes||
|Two (2) database nodes + witness||
We have a few customers who started out with 2+1 because it suited their hardware/server capacity budgets better at the time, but as their applications grew, they needed to expand. Converting a witness node into a full database node at a later date is VERY easy and can be achieved without downtime. With my DBA/Site Availability hat on, I would always opt for 3 full nodes from the outset to give me peace of mind that we have full HA, but equally, that isn’t always possible for everyone.