MySQL MHA Deployment Guide

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

1. Support boundaries

  • Currently maintained only for CentOS 7 / Red Hat 7
  • 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.

192.168.161.* is the default dbbot three-node regression subnet, not a legacy MHA-specific environment. To validate mha.yml, prepare a separate CentOS 7 or Red Hat 7 environment and use MySQL 5.7.

2. inventory and roles

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

[dbbot_mysql]
192.0.2.131 ansible_user=root ansible_ssh_pass="'<your_password>'"
192.0.2.132 ansible_user=root ansible_ssh_pass="'<your_password>'"
192.0.2.133 ansible_user=root ansible_ssh_pass="'<your_password>'"

3. Key variables

Edit mysql_ansible/playbooks/common_config.yml:

mysql_version: "5.7.44"
mysql_port: 3306
fcs_allow_dbbot_default_passwd: true

Description:

  • mha.yml supports only MySQL 5.7; do not keep the default MySQL 9.7.x configuration.
  • fcs_allow_dbbot_default_passwd: true is suitable only for temporary lab environments. If you keep dbbot’s public default passwords, this switch must be enabled explicitly; production environments should use custom passwords and keep this switch false.

Edit mysql_ansible/playbooks/vars/var_mha.yml:

master_ip: 192.0.2.131
slave_ips:
  - 192.0.2.132
  - 192.0.2.133
manager_ip: 192.0.2.133
vip: 192.0.2.130
vip_netmask: "32"
net_work_interface: ens33
mha_secondary_check_script: ""

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
  • ens33 is only an example interface name. Before running a VIP-related playbook, confirm the real interface with ip route get <gateway> or ip -o -4 addr show. CentOS 7 KVM test environments may also use eth0.
  • mha_secondary_check_script is empty by default, which keeps the classic MHA default behavior. For production, configure a topology-specific multi-path check command to reduce false positives from a single manager path.

4. Execution entry

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

During execution, enter confirm as prompted.

For non-interactive execution, append the confirmation variable explicitly:

python3 /usr/local/dbbot/portable-ansible/ansible-playbook mha.yml -e dbbot_confirmation_input=confirm

If you also override boolean variables on the command line, use JSON extra-vars so key=true is not parsed as a string:

python3 /usr/local/dbbot/portable-ansible/ansible-playbook mha.yml \
  -e dbbot_confirmation_input=confirm \
  -e '{"fcs_allow_dbbot_default_passwd": true}'

5. Uninstall

mha_unsafe_uninstall.yml stops the classic MHA manager, removes the configured VIP and MHA runtime files, and then removes the MySQL instance data, log, and runtime directories for the current mysql_port:

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

During execution, enter confirm as prompted. For non-interactive execution, append -e dbbot_confirmation_input=confirm.

By default, the playbook does not remove the MHA RPM packages. If you need to remove mha4mysql-manager and mha4mysql-node, append -e '{"mha_uninstall_remove_packages": true}'.

6. Things to note

  • The current mha.yml document only covers CentOS 7 and Red Hat 7 prerequisites.
  • Three-node regression environments that do not meet the CentOS 7 / Red Hat 7 and MySQL 5.7 requirements are expected to be blocked by the mha.yml preflight checks.
  • If you use it on other distributions, you need to verify Perl dependencies and MHA RPM compatibility yourself first.
  • secondary_check_script is not configured by default. Production environments should add MHA secondary checks based on their network topology.
  • 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.