MySQL MHA Deployment Guide

This article explains the supported boundaries and basic usage of mha.yml.

1. Support boundaries

  • Currently based on CentOS 7.5 / EL7 environment maintenance
  • Target architecture: one master, multiple replicas + MHA Manager
  • Applicable version: MySQL 5.7

mha.yml belongs to the traditional high availability solution. For new clusters, it is recommended to use MGR or InnoDB Cluster.

2. inventory and roles

mha.yml still uses the [dbbot_mysql] host group, and the actual roles are distinguished by variables:

[dbbot_mysql]
192.168.199.131 ansible_user=root ansible_ssh_pass="'<your_password>'"
192.168.199.132 ansible_user=root ansible_ssh_pass="'<your_password>'"
192.168.199.133 ansible_user=root ansible_ssh_pass="'<your_password>'"

3. Key variables

Edit mysql_ansible/playbooks/vars/var_mha.yml:

master_ip: 192.168.199.131
slave_ips:
  - 192.168.199.132
  - 192.168.199.133
manager_ip: 192.168.199.132
vip: 192.168.199.134
vip_netmask: "32"
net_work_interface: ens33

Description:

  • manager_ip cannot be the same as master_ip
  • manager_ip should be placed on the replica node
  • vip, vip_netmask, net_work_interface need to be consistent with the actual network environment

4. Execution entry

cd /usr/local/dbbot/mysql_ansible/playbooks
ansible-playbook mha.yml

5. Things to note

  • mha.yml The current document only covers CentOS 7.5 / EL7 prerequisites.
  • If you use it on other distributions, you need to verify Perl dependencies and MHA RPM compatibility yourself first.
  • If you need to rerun after a failure, it is recommended to confirm the MHA Manager configuration, VIP status, and MySQL instance status before deciding whether to clean up the residual files.