Common reasons for switching the primary node

There are various situations where it may be necessary to switch the primary node in a MySQL group replication setup. Here are some of the typical reasons for this behavior:

• Performing OS or MySQL maintenance tasks that require the primary node to be offline temporarily.

• Applying patches or updates to the host system that may impact the performance or availability of the primary node.

• Upgrading the MySQL server to a new version or making significant changes to the configuration that require a new primary node.

• The current primary server experiences an issue or goes down unexpectedly, making it necessary to promote a new primary node to maintain data replication and minimize downtime.

Primary Promotion and its importance

In the event of a primary node failure, it’s important to select a new primary node to ensure the continuity of data replication and minimize downtime. This process is known as primary promotion.

With primary promotion, the group replication cluster can continue to function and handle requests even when a primary node fails.

Methods for switching the primary node

There are several methods available for switching the primary node in MySQL group replication, including:

1. Auto-switch
2. Auto-switch by weight of the node
3. Manual Primary Promotion

Setting up a three-node MySQL group replication cluster for demonstration

To illustrate the primary promotion process and its different scenarios, I have set up a practical example using a three-node MySQL group replication cluster. This setup allows us to demonstrate how the primary node can be switched in different situations, such as node failures or maintenance tasks.

‍