目录
3 在host4(manager_host)上安装MHA Manager
6 对于MySQL 5.1+使用mysqlbinlog 5.1+
不要在使用基于语句的二进制日志记录（SBR）时使用 LOAD DATA INFILE
MHA本身不会构建复制环境，因此您需要自己搭建MySQL复制环境。换句话说，您可以在现有环境中使用MHA。例如，假设有四个主机：host1、host2、host3、host4。主服务器当前正在host1上运行，并且两个从服务器正在host2和host3上运行。因此，MySQL服务器正在host1、host2和host3上运行。让我们在host4(manager_host)上运行MHA Manager。
请参阅安装MHA Node。
请参阅安装MHA Manager。MHA Manager依赖于MHA Node软件包，因此您需要在管理服务器上同时安装这两个软件包。
下一步是在MHA Manager上创建一个配置文件。参数包括每个MySQL服务器的主机名、MySQL用户名和密码、MySQL复制用户名和密码、工作目录名称等。所有参数都在参数页面中描述。
- manager_host$ cat /etc/app1.cnf
-
- [server default]
- # mysql user and password
- user=root
- password=mysqlpass
- ssh_user=root
- # working directory on the manager
- manager_workdir=/var/log/masterha/app1
- # working directory on MySQL servers
- remote_workdir=/var/log/masterha/app1
-
- [server1]
- hostname=host1
-
- [server2]
- hostname=host2
-
- [server3]
- hostname=host3
请注意，您没有指定host1是当前的主服务器。MHA会在内部自动检测当前的主服务器。
MHA Manager会通过SSH内部调用MHA Node软件包中包含的程序。MHA Node程序还通过SSH（scp）将差异中继日志文件发送给其他非最新的从服务器。为了使这些过程非交互式，需要设置SSH公钥身份验证。MHA Manager提供了一个简单的检查程序“masterha_check_ssh”，用于验证彼此之间是否可以建立非交互式的SSH连接。
- # masterha_check_ssh --conf=/etc/app1.cnf
-
- Sat May 14 14:42:19 2011 - [warn] Global configuration file /etc/masterha_default.cnf not found. Skipping.
- Sat May 14 14:42:19 2011 - [info] Reading application default configurations from /etc/app1.cnf..
- Sat May 14 14:42:19 2011 - [info] Reading server configurations from /etc/app1.cnf..
- Sat May 14 14:42:19 2011 - [info] Starting SSH connection tests..
- Sat May 14 14:42:19 2011 - [debug] Connecting via SSH from root@host1(192.168.0.1) to root@host2(192.168.0.2)..
- Sat May 14 14:42:20 2011 - [debug] ok.
- Sat May 14 14:42:20 2011 - [debug] Connecting via SSH from root@host1(192.168.0.1) to root@host3(192.168.0.3)..
- Sat May 14 14:42:20 2011 - [debug] ok.
- Sat May 14 14:42:21 2011 - [debug] Connecting via SSH from root@host2(192.168.0.2) to root@host1(192.168.0.1)..
- Sat May 14 14:42:21 2011 - [debug] ok.
- Sat May 14 14:42:21 2011 - [debug] Connecting via SSH from root@host2(192.168.0.2) to root@host3(192.168.0.3)..
- Sat May 14 14:42:21 2011 - [debug] ok.
- Sat May 14 14:42:22 2011 - [debug] Connecting via SSH from root@host3(192.168.0.3) to root@host1(192.168.0.1)..
- Sat May 14 14:42:22 2011 - [debug] ok.
- Sat May 14 14:42:22 2011 - [debug] Connecting via SSH from root@host3(192.168.0.3) to root@host2(192.168.0.2)..
- Sat May 14 14:42:22 2011 - [debug] ok.
- Sat May 14 14:42:22 2011 - [info] All SSH connection tests passed successfully.
如果masterha_check_ssh停止并出现错误或要求进行身份验证，则SSH配置对于MHA的正常工作无效。您需要修复它然后再次尝试。最可能的原因是SSH公钥身份验证未正确设置。
为了使MHA正常工作，配置文件中定义的所有MySQL主服务器和从服务器都必须正常工作。MHA Manager提供了一个名为masterha_check_repl的命令，用于快速检查复制的健康状况。
- manager_host$ masterha_check_repl --conf=/etc/app1.cnf
- ...
- MySQL Replication Health is OK.
如果在这里遇到任何错误，请检查日志并修复问题。当前的主服务器不能是从服务器，并且所有其他从服务器必须从主服务器复制。TypicalErrors页面可能有助于修复设置错误。
您已配置了MySQL复制，安装了MHA Node和MHA Manager，并配置了SSH公钥身份验证。下一步是启动MHA Manager。可以使用masterha_manager命令启动MHA Manager。
- manager_host$ masterha_manager --conf=/etc/app1.cnf
- ....
- Sat May 14 15:58:29 2011 - [info] Connecting to the master host1(192.168.0.1:3306) and sleeping until it doesn't respond..
如果所有配置都有效，masterha_manager会检查MySQL主服务器的可用性，直到主服务器死机。如果masterha_manager在监视主服务器之前出现错误而停止，请检查错误日志并修复配置。所有日志默认打印到标准错误（STDERR），但可以在"manager_log"配置参数中更改。常见的错误是MySQL复制配置无效，ssh_user没有足够的权限（最低要求是中继日志的读权限和远程工作目录的写权限）。默认情况下，masterha_manager在前台运行。如果向masterha_manager发送SIGINT（发送Ctrl+C），masterha_manager将停止监控并退出。
在MHA Manager监视MySQL主服务器之后，除非主服务器变得不可达或管理器自身终止，否则不会打印任何内容。您可能想要检查MHA Manager是否真的正常工作。masterha_check_status命令可用于检查当前MHA Manager的状态。以下是一个示例。
- manager_host$ masterha_check_status --conf=/etc/app1.cnf
- app1 (pid:5057) is running(0:PING_OK), master:host1
"app1"是MHA内部处理的应用程序名称，是配置文件的前缀名称。
如果管理器停止或配置文件无效，则将返回以下错误：
- manager_host$ masterha_check_status --conf=/etc/app1.cnf
- app1 is stopped(1:NOT_RUNNING).
您可以使用masterha_stop命令停止MHA Manager。
- manager_host$ masterha_stop --conf=/etc/app1.cnf
- Stopped app1 successfully.
如果无法停止（即挂起），请添加“--abort”参数。
一旦您了解了如何停止它，请再次启动masterha_manager。
现在MHA Manager正在监控MySQL主服务器的可用性。接下来，让我们测试主故障转移是否正常工作。为了模拟这种情况，您可以简单地在主服务器上杀死mysqld。
host1$ killall -9 mysqld mysqld_safe在某些发行版（如Ubuntu）上，mysqld将通过angel进程自动重新启动。如果mysqld重新启动非常快（几秒钟），则在MHA开始故障转移之前，来自MHA的ping将再次成功。在这种情况下，故障转移不会开始。如果重新启动mysqld花费很长时间（即InnoDB崩溃恢复需要2分钟），则故障转移将开始。
如果您在测试杀死mysqld时遇到困难，或者想要测试Linux内核方面的问题，那么触发内核panic很容易。
host1# echo c > /proc/sysrq-trigger检查MHA管理器上的日志，并验证host2是否成为新主服务器，host3是否从host2复制。
当故障转移完成（或以错误结束）时，MHA Manager进程将停止。这是一种预期行为。如果您想永久运行MHA Manager，请阅读“在后台运行MHA Manager”部分。
现在我们已经完成了主故障转移的基本测试。在实践中，您可能希望执行以下操作。
您可能希望测试故障情况。请参阅下面的示例。
- terminal1# masterha_manager --conf=/etc/app1.cnf
- terminal2# mysql -hhost2 db1 -e "insert into t1 values (100, 100, 100)"
- terminal2# mysql -hhost1 db1 -e "insert into t1 values (100, 100, 100)"
- Check replication stops with error
- kill master
- Check master failover does not work.
- mysql_host2> set global slave_sql_skip_counter=1;
- mysql_host2> start slave;
- Check replication starts again.
-
- Test manual failover
- # remove error file
- # rm -f /var/log/masterha/mha_test50/mha_test50.failover.error
- # masterha_master_switch --master_state=dead --conf=/path/to/conf --dead_master_host=host1
MHA由MHA Manager和MHA Node两个包组成。MHA Manager运行在管理服务器上，而MHA Node运行在每个MySQL服务器上。MHA Node程序并不总是运行，而是在需要时（在配置检查、故障转移等时）从MHA管理程序中调用。MHA Manager和MHA Node都是用Perl编写的。
可以从 下载 部分下载MHA Node和MHA Manager。这些是稳定的软件包。
如果您想尝试源码开发，请检出GitHub源树。MHA Manager托管在这里，MHA Node托管在这里。
官方文档中的下载地址不能下载最新版本的Node 和 Manager 了，可以从以下地址下载最新的0.58版本
MHA Node具有以下脚本和依赖的Perl模块。
您需要将MHA Node安装到所有MySQL服务器（主服务器和从服务器）。您还需要在管理服务器上安装MHA Node，因为MHA Manager模块在内部依赖于MHA Node模块。MHA Manager在内部通过SSH连接到受管MySQL服务器并执行MHA Node脚本。MHA Node除了DBD::mysql之外不依赖于任何外部Perl模块，因此您应该能够轻松安装。
您可以按照以下步骤安装MHA Node的rpm软件包。
- ## If you have not installed DBD::mysql, install it like below, or install from source.
- yum install perl-DBD-MySQL
-
- ## Get MHA Node rpm package from "Downloads" section.
- rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm
- ## If you have not installed DBD::mysql, install it like below, or install from source.
- # apt-get install libdbd-mysql-perl
-
- ## Get MHA Node deb package from "Downloads" section.
- # dpkg -i mha4mysql-node_X.Y_all.deb
- ## Install DBD::mysql if not installed
- $ tar -zxf mha4mysql-node-X.Y.tar.gz
- $ perl Makefile.PL
- $ make
- $ sudo make install
MHA Manager具有诸如masterha_manager、masterha_master_switch等管理命令行程序，以及相关的Perl模块。MHA Manager依赖于以下Perl模块。在安装MHA Manager之前，您需要先安装它们。不要忘记安装MHA Node。
您可以按照以下步骤安装MHA Manager的rpm软件包。
- ## Install dependent Perl modules
- # yum install perl-DBD-MySQL
- # yum install perl-Config-Tiny
- # yum install perl-Log-Dispatch
- # yum install perl-Parallel-ForkManager
-
- ## Install MHA Node, since MHA Manager uses some modules provided by MHA Node.
- # rpm -ivh mha4mysql-node-X.Y-0.noarch.rpm
-
- ## Finally you can install MHA Manager
- # rpm -ivh mha4mysql-manager-X.Y-0.noarch.rpm
- ## Install dependent Perl modules
- # apt-get install libdbd-mysql-perl
- # apt-get install libconfig-tiny-perl
- # apt-get install liblog-dispatch-perl
- # apt-get install libparallel-forkmanager-perl
-
- ## Install MHA Node, since MHA Manager uses some modules provided by MHA Node.
- # dpkg -i mha4mysql-node_X.Y_all.deb
-
- ## Finally you can install MHA Manager
- # dpkg -i mha4mysql-manager_X.Y_all.deb
- ## Install dependent Perl modules
- # apt-get install libdbd-mysql-perl
- # apt-get install libconfig-tiny-perl
- # apt-get install liblog-dispatch-perl
- # apt-get install libparallel-forkmanager-perl
-
- ## Install MHA Node, since MHA Manager uses some modules provided by MHA Node.
- # dpkg -i mha4mysql-node_X.Y_all.deb
-
- ## Finally you can install MHA Manager
- # dpkg -i mha4mysql-manager_X.Y_all.deb
要使MHA正常工作，您必须创建一个配置文件并设置参数。参数包括每个MySQL服务器的主机名、MySQL用户名和密码、工作目录名称等。所有参数都在参数页面进行了描述。
所有参数解释
https://raw.githubusercontent.com/wiki/yoshinorim/mha4mysql-manager/Parameters.md
以下是一个示例配置文件。
manager_host$ cat /etc/app1.cnf
- [server default]
- # mysql user and password
- user=root
- password=mysqlpass
- # working directory on the manager
- manager_workdir=/var/log/masterha/app1
- # manager log file
- manager_log=/var/log/masterha/app1/app1.log
- # working directory on MySQL servers
- remote_workdir=/var/log/masterha/app1
-
- [server1]
- hostname=host1
-
- [server2]
- hostname=host2
-
- [server3]
- hostname=host3
所有参数必须遵循“param=value”的语法。例如，以下参数设置是不正确的。
- [server1]
- hostname=host1
- # incorrect: must be "no_master=1"
- no_master
应用程序范围的参数应该写在 [server default] 块中。在 [serverN] 块中，您应该设置局部范围的参数。主机名是必需的局部范围参数，因此必须在此处写入。块名称应以“server”开头。在内部，服务器配置按块名称排序，排序顺序在MHA确定新主服务器时很重要（有关详细信息，请参阅FAQ）。
如果您计划从单个管理服务器管理两个或更多MySQL应用程序（（主服务器，从服务器）对），则创建全局配置文件会使配置变得更加容易。一旦您在全局配置文件中编写了参数，您就不需要为每个应用程序设置参数。如果在/etc/masterha_default.cnf创建一个文件，MHA Manager脚本会自动将该文件读取为全局配置文件。
您可以在全局配置文件中设置应用程序范围的参数。例如，如果所有MySQL服务器上的MySQL管理用户和密码相同，您可以在这里设置“user”和“password”。
全局配置示例：
- [server default]
- user=root
- password=rootpass
- ssh_user=root
- master_binlog_dir= /var/lib/mysql
- remote_workdir=/data/log/masterha
- secondary_check_script= masterha_secondary_check -s remote_host1 -s remote_host2
- ping_interval=3
- master_ip_failover_script=/script/masterha/master_ip_failover
- shutdown_script= /script/masterha/power_manager
- report_script= /script/masterha/send_master_failover_mail
这些参数适用于所有由在主机上运行的MHA Manager监控的应用程序。
应用程序配置文件应分别编写。以下示例是配置app1（host1-4）和app2（host11-14）。
app1：
manager_host$ cat /etc/app1.cnf
- [server default]
- manager_workdir=/var/log/masterha/app1
- manager_log=/var/log/masterha/app1/app1.log
-
- [server1]
- hostname=host1
- candidate_master=1
-
- [server2]
- hostname=host2
- candidate_master=1
-
- [server3]
- hostname=host3
-
- [server4]
- hostname=host4
- no_master=1
在上述情况下，MHA Manager在/var/log/masterha/app1下生成工作文件（包括状态文件），并在/var/log/masterha/app1/app1.log生成日志文件。在监视其他应用程序时，您需要设置唯一的目录/文件名称。
app2：
manager_host$ cat /etc/app2.cnf
- [server default]
- manager_workdir=/var/log/masterha/app2
- manager_log=/var/log/masterha/app2/app2.log
-
- [server1]
- hostname=host11
- candidate_master=1
-
- [server2]
- hostname=host12
- candidate_master=1
-
- [server3]
- hostname=host13
-
- [server4]
- hostname=host14
- no_master=1
如果在全局配置文件和应用程序配置文件中设置了相同的参数，则使用后者（应用程序配置）。
从MHA版本0.56开始，MHA支持新的[section]。在binlog部分中，您可以定义mysqlbinlog流式传输服务器。当MHA执行基于GTID的故障转移时，MHA会检查binlog服务器，如果binlog服务器领先于其他从服务器，MHA会在恢复之前将差异binlog事件应用于新主服务器。当MHA执行非基于GTID的（传统的）故障转移时，MHA会忽略binlog服务器。
以下是一个示例配置。
manager_host$ cat /etc/app1.cnf
- [server default]
- # mysql user and password
- user=root
- password=mysqlpass
- # working directory on the manager
- manager_workdir=/var/log/masterha/app1
- # manager log file
- manager_log=/var/log/masterha/app1/app1.log
- # working directory on MySQL servers
- remote_workdir=/var/log/masterha/app1
-
- [server1]
- hostname=host1
-
- [server2]
- hostname=host2
-
- [server3]
- hostname=host3
-
- [binlog1]
- hostname=binlog_host1
-
- [binlog2]
- hostname=binlog_host2
要使MHA真正发挥作用，您需要验证以下设置。大多数设置都会在启动masterha_manager或masterha_check_repl时自动检查。
MHA Manager内部通过SSH连接到MySQL服务器。最新的从服务器上的MHA Node也通过SSH（scp）内部发送中继日志文件到其他从服务器。为了使这些过程自动化，通常建议启用SSH公钥认证而不使用密码。您可以使用MHA Manager中包含的masterha_check_ssh命令来检查SSH连接是否正常工作。
当您使用masterha_secondary_check脚本检查附加网络连接时，您还需要验证MHA Manager到远程主机的SSH公钥访问是否可用。
MHA Manager内部并行执行恢复。在生成差异中继日志文件时，MHA以并行方式连接到最新的从服务器，并生成并发送差异中继日志文件到非最新的从服务器。如果您有数十个从服务器或将数十个MySQL实例合并到单个操作系统中，sshd可能会拒绝SSH连接请求，这将导致从服务器恢复错误。为了避免此问题，请提高/etc/ssh/sshd_config中的MaxStartups参数（默认值为10）并重新启动sshd。
MHA仅在Linux上进行了测试。
在主服务器崩溃的情况下，MHA解决了从服务器之间的一致性问题。此外，MHA尝试保存从主服务器中未发送的二进制日志事件，并将事件应用于所有从服务器。如果您只有一个从服务器，则无需关心从服务器之间的一致性问题。即使您仅使用一个从服务器，只要通过SSH连接到崩溃的主服务器，MHA仍然有助于保存事件，但是使用半同步复制也可以解决此问题。
从MHA Manager版本0.52开始，支持多主复制配置。以下是使MHA与多主工作的一些注意事项。
只允许一个主要主服务器（可写）。其他MySQL主服务器必须设置“read-only=1”。 默认情况下，所有受管理的服务器（在MHA配置文件中定义）应该在两层复制通道中。有关详细信息，请参见下文。
在MHA Manager版本0.52之前，MHA检查所有受管理的主机，并仅在所有从服务器从同一主服务器复制时才开始监视/故障转移。也就是说，MHA不支持多主配置。通常，只要MHA管理自动故障转移，使用多主配置的原因是有限的，例如在线模式更改。如果您想临时使用多主配置（即仅用于模式更改），只需停止MHA并在操作期间配置多主。操作完成后，再次进行单主和多个从服务器配置，然后重新启动MHA。
MHA不支持默认的三层或更多层次的复制结构（例如，Master1->Master2->Slave3）。 MHA只处理直接复制自当前主要主服务器的从服务器的故障转移和恢复。MHA可以管理master1和master2，并在master1崩溃时将master2提升为新主服务器，但是MHA无法监视和恢复slave3，因为slave3从不同的主服务器（master2）复制。为了使MHA与此类结构一起工作，可以进行以下配置。
在这两种情况下，MHA只管理主要主服务器和第二层从服务器。这仍然非常有帮助，因为在主服务器（master1）崩溃的情况下可以进行从master1到master2的自动故障转移，并且第三层从服务器仍然可以正常工作。有关详细信息，请参阅UseCases页面。
MHA支持MySQL版本5.0或更高版本。MHA不支持MySQL 4.1或更早版本。这是因为从MySQL 5.0开始，二进制日志格式发生了变化（称为binlog v4格式）。当MHA解析二进制日志以识别目标中继日志位置时，binlog格式必须是v4，因此MySQL 4.1在此处无法工作。MySQL 5.0或更高版本中的mysqlbinlog还要求binlog格式为v4。此外，较早版本的MySQL存在一些围绕MySQL复制处理的严重问题，因此强烈建议使用更高版本。特别是如果您使用的是MySQL 5.0.60之前的版本，请考虑升级。
MHA使用mysqlbinlog将binlog事件应用于目标从服务器。如果主服务器使用基于行的格式，则行事件将写入二进制日志中。这样的二进制日志只能由MySQL 5.1或更高版本中的mysqlbinlog解析，因为MySQL 5.0中的mysqlbinlog不支持基于行的格式。可以如下检查mysqlbinlog（和mysql）版本。
- [app@slave_host1]$ mysqlbinlog --version
- mysqlbinlog Ver 3.3 for unknown-linux-gnu at x86_64
如果它包含在MySQL 5.1中，则mysqlbinlog版本应为3.3或更高。 MHA在所有从服务器上内部检查MySQL和mysqlbinlog版本。如果mysqlbinlog版本为3.2或更早版本，并且MySQL版本为5.1或更高版本，则MHA在开始监视之前会停止并显示错误。
如果当前从服务器未设置log-bin，则显然它们无法成为新主服务器。MHA Manager内部检查log-bin设置，并且不会将其提升为新主服务器。如果当前没有从服务器设置log-bin，则MHA Manager不会继续执行故障转移。
复制过滤规则（binlog-do-db，replicate-ignore-db等）在所有MySQL服务器上必须相同。MHA在启动时检查过滤规则，并且如果过滤规则不相同，则不会开始监视或故障转移。
故障转移完成后，所有其他从服务器都会执行CHANGE MASTER TO语句。要开始复制，必须在新主服务器上存在一个复制用户（具有REPLICATION SLAVE权限）。
默认情况下，从服务器上的中继日志会在SQL线程执行完毕后自动删除。但是，可能仍然需要这些中继日志来恢复其他从服务器。因此，您需要禁用自动中继日志清除，并定期清除旧的中继日志。但是，当手动清除中继日志时，您需要注意复制延迟问题。在ext3文件系统上，删除大文件需要很长时间，这将导致严重的复制延迟。为了避免复制延迟，临时创建中继日志的硬链接是有帮助的。有关详细信息，请参阅两张幻灯片。
MHA Node有一个命令行工具“purge_relay_logs”，用于执行上述幻灯片中描述的所有操作。也就是说，它创建硬链接，执行“SET GLOBAL relay_log_purge=1”，等待几秒钟以使SQL线程可以切换到新的中继日志（只要它明显落后），并执行“SET GLOBAL relay_log_purge=0”。
purge_relay_logs需要以下参数。purge_relay_logs内部连接到MySQL从服务器，因此需要MySQL身份验证参数。
--user MySQL username. By default, it's root.
--password MySQL password for --user. By default, it's empty.
--host MySQL hostname. By default, it's 127.0.0.1. --host must be the same server where you run purge_relay_logs. For example, if you pass --host=host2 on host1, purge_relay_logs aborts. If you have virtual hostname vhost1 on host1, passing --host=vhost1 on host1 is valid and purge_relay_logs does not abort.
--port MySQL port number. By default, it's 3306.
--workdir Tentative directory where hard linked relay logs are created and removed. After executing the script successfully, hard-linked relay log files are deleted. By default, it's /var/tmp. If you put relay log files on a different OS partition from /var/tmp, you need to explicitly set this parameter. This is because creating hard links between different OS partitions are not supported (You'll get "Invalid cross-device link" error). In this case, set --workdir to a directory which resides on a same OS partition as relay log files.
--disable_relay_log_purge By default, if relay_log_purge is ON(1) in MySQL, purge_relay_logs script exits without doing anything. So relay_log_purge is still ON(1). By setting --disable_relay_log_purge, purge_relay_logs script does not exit and automatically sets relay_log_purge to 0. So after executing the script, relay_log_purge becomes OFF(0).
purge_relay_logs脚本的计划purge_relay_logs会在不阻塞SQL线程的情况下移除中继日志。中继日志需要定期清理（例如，每天一次，每6小时一次等），因此应该在每个从服务器上定期通过作业调度程序调用purge_relay_logs脚本。例如，您可以按照以下方式从cron中调用purge_relay_logs：
- [app@slave_host1]$ cat /etc/cron.d/purge_relay_logs
- # purge relay logs at 5am
- 0 5 * * * app /usr/bin/purge_relay_logs --user=root --password=PASSWORD --disable_relay_log_purge >> /var/log/masterha/purge_relay_logs.log 2>&1
建议在从服务器之间使用不同的时间调用 cron。如果所有从服务器同时调用 purge_relay_logs，那么在发生故障时，可能会导致没有一个从服务器拥有必要的中继日志事件。
当主服务器在使用基于语句的二进制日志记录（SBR）完成 LOAD DATA INFILE 后立即崩溃时，如果使用非事务性存储引擎或过旧的 MySQL 版本（例如 5.0.45 等），MHA 可能无法生成差异中继日志事件。使用 LOAD DATA INFILE 与 SBR 存在一些已知问题，并且在 MySQL 5.1 中已被弃用。LOAD DATA INFILE 也会导致显著的复制延迟，因此没有积极的原因使用它。
如果您想使用 LOAD DATA，请使用 SET sql_log_bin=0; LOAD DATA … ; SET sql_log_bin=1; 更为推荐的方法。
从 MHA 0.56 开始，MHA 支持基于 GTID 和传统的中继日志的故障切换。MHA 会自动区分选择哪种故障切换方式。要进行基于 GTID 的故障切换，需要满足以下所有条件：
使用 MySQL 5.6（或更新版本） 所有 MySQL 实例都使用 gtid_mode=1 至少有一个实例已启用 Auto_Position 参数