Ensuring MySQL Slave Node Availability with Keepalived and Read/Write Splitting

The author introduces a project that adopts a read‑write splitting strategy, routing write operations to the primary MySQL instance and read‑only queries to a replica, thereby reducing load on the master.

During operation the replica unexpectedly shut down; logs showed no error, so the author recorded the troubleshooting steps, including inspecting Docker container logs ( docker logs 043 --tail 200 ) and the MySQL error log ( cat /var/log/mysql/error.log ).

The article explains two read‑write splitting models: full separation (master for writes only, replica for reads only) and partial separation (master handles both reads and writes, replica handles read‑intensive queries). The project uses the partial approach.

To improve replica availability, Keepalived is deployed to monitor the MySQL service; if the service becomes unhealthy, Keepalived automatically restarts the MySQL container. Two fallback strategies are discussed: redirecting reads to the master (increasing its load) or adding a second replica with Keepalived‑based failover. The author chooses the first strategy.

Implementation steps include installing Keepalived, starting the service ( systemctl start keepalived ), enabling it at boot via sudo vim /etc/rc.local , configuring health checks in /etc/keepalived/keepalived.conf , and adjusting the VIP addresses so the replica does not take over the master role (changing from 192.168.56.88 to 192.168.56.89). The restart script is also modified to avoid forcing a VIP takeover.

In conclusion, the author reflects on the read‑write splitting setup, the lack of built‑in HA for the replica, and how the Keepalived configuration restores availability, while noting future work on a more robust HA solution.