mha一al00|MHA轻松实现MySQL高可用配置详解

时间：2020-10-29 来源：手机硬件阅读：

还支持在线切换，从当前运行master切换到一个新的master上面，只需要很短的时间（0.5-2秒内），此时仅仅阻塞写操作，并不影响读操作，便于主机硬件维护。

2MHA架构

MHA由MHA Manager和MHA Node组成。

1.png

3MHA Manager

运行一些工具，比如masterha_manager工具实现自动监控MySQL Master和实现master故障切换，其它工具实现手动实现master故障切换、在线mater转移、连接检查等等。一个Manager可以管理多个master-slave集群。

4MHA Node

部署在所有运行MySQL的服务器上，无论是master还是slave。主要作用有三个。

Ⅰ、保存二进制日志
如果能够访问故障master，会拷贝master的二进制日志

II、应用差异中继日志
从拥有最新数据的slave上生成差异中继日志，然后应用差异日志。

III、清除中继日志
在不停止SQL线程的情况下删除中继日志

5MHA工作原理

2.png

当master出现故障时，通过对比slave之间I/O线程读取masterbinlog的位置，选取最接近的slave做为latestslave。其它slave通过与latest slave对比生成差异中继日志。在latest slave上应用从master保存的binlog，同时将latest slave提升为master。最后在其它slave上应用相应的差异中继日志并开始从新的master开始复制。

在MHA实现Master故障切换过程中，MHA Node会试图访问故障的master（通过SSH），如果可以访问（不是硬件故障，比如InnoDB数据文件损坏等），会保存二进制文件，以最大程度保证数据不丢失。MHA和半同步复制一起使用会大大降低数据丢失的危险。

6当前高可用方案

Heartbeat+DRBD
开销：需要额外添加处于被动状态的master server（并不处理应用流量）
性能：为了实现DRBD复制环境的高可用，innodb-flush-log-at-trx-commit和sync-binlog必须设置为1，这样会导致写性能下降。

一致性：在master上必要的binlog时间可能会丢失，这样slave就无法进行复制，导致产生数据一致性问题。

MySQL Cluster
MySQL Cluster真正实现了高可用，但是使用的是NDB存储引擎，并且SQL节点有单点故障问题。

半同步复制(5.5+)
半同步复制大大减少了“binlog events只存在故障master上”的问题。

在提交时，保证至少一个slave（并不是所有的）接收到binlog，因此一些slave可能没有接收到binlog。

全局事务ID
在二进制文件中添加全局事务ID（global transaction id）需要更改binlog格式，在5.1/5.5版本中不支持。

在应用方面有很多方法可以直线全局事务ID，但是仍避免不了复杂度、性能、数据丢失或者一致性的问题。

PXC
PXC实现了服务高可用，数据同步时是并发复制。但是仅支持InnoDB引擎，所有的表都要有主键。锁冲突、死锁问题相对较多等等问题。

7MHA的优势

1、故障切换快

在主从复制集群中，只要从库在复制上没有延迟，MHA通常可以在数秒内实现故障切换。9-10秒内检查到master故障，可以选择在7-10秒关闭master以避免出现裂脑，几秒钟内，将差异中继日志（relay log）应用到新的master上，因此总的宕机时间通常为10-30秒。恢复新的master后，MHA并行的恢复其余的slave。即使在有数万台slave，也不会影响master的恢复时间。

DeNA在超过150个MySQL（主要5.0/5.1版本）主从环境下使用了MHA。当mater故障后，MHA在4秒内就完成了故障切换。在传统的主动/被动集群解决方案中，4秒内完成故障切换是不可能的。

2、master故障不会导致数据不一致

当目前的master出现故障是，MHA自动识别slave之间中继日志（relay log）的不同，并应用到所有的slave中。这样所有的salve能够保持同步，只要所有的slave处于存活状态。和Semi-Synchronous Replication一起使用，（几乎）可以保证没有数据丢失。

3、无需修改当前的MySQL设置

MHA的设计的重要原则之一就是尽可能地简单易用。MHA工作在传统的MySQL版本5.0和之后版本的主从复制环境中。和其它高可用解决方法比，MHA并不需要改变MySQL的部署环境。MHA适用于异步和半同步的主从复制。

启动/停止/升级/降级/安装/卸载MHA不需要改变（包扩启动/停止）MySQL复制。当需要升级MHA到新的版本，不需要停止MySQL，仅仅替换到新版本的MHA，然后重启MHA　Manager就好了。

MHA运行在MySQL 5.0开始的原生版本上。一些其它的MySQL高可用解决方案需要特定的版本（比如MySQL集群、带全局事务ID的MySQL等等），但并不仅仅为了master的高可用才迁移应用的。在大多数情况下，已经部署了比较旧MySQL应用，并且不想仅仅为了实现Master的高可用，花太多的时间迁移到不同的存储引擎或更新的前沿发行版。MHA工作的包括5.0/5.1/5.5的原生版本的MySQL上，所以并不需要迁移。

4、无需增加大量的服务器

MHA由MHA Manager和MHA Node组成。MHA Node运行在需要故障切换/恢复的MySQL服务器上，因此并不需要额外增加服务器。MHA Manager运行在特定的服务器上，因此需要增加一台（实现高可用需要2台），但是MHA Manager可以监控大量（甚至上百台）单独的master，因此，并不需要增加大量的服务器。即使在一台slave上运行MHA Manager也是可以的。综上，实现MHA并没用额外增加大量的服务。

5、无性能下降

MHA适用与异步或半同步的MySQL复制。监控master时，MHA仅仅是每隔几秒（默认是3秒）发送一个ping包，并不发送重查询。可以得到像原生MySQL复制一样快的性能。

6、适用于任何存储引擎

MHA可以运行在只要MySQL复制运行的存储引擎上，并不仅限制于InnoDB，即使在不易迁移的传统的MyISAM引擎环境，一样可以使用MHA。

#cat /etc/redhat-release

CentOSrelease 6.6 (Final)

#uname -rm

2.6.32-504.el6.x86_64x86_64

创建MHA用户

在主从环境的主上执行

mysql>grant all privileges on *.* to "mha"@"192.168.56.%" identified by "123456";

创建软连接

如果MySQL服务不是yum安装，要在所有MySQLServer上，无论主从都要执行如下两个命令。

# ln-s /application/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog

# ln-s /application/mysql/bin/mysql /usr/bin/mysql

配置SSH公钥认证

几台服务器进行相同操作，仅分发到的服务不同而已，这里仅列出一台。

###

添加统一用户

在生产环境下使用root用户不安全，也不规范。并且环境统一也比较方便管理，因此可以创建统一的普通用户来进行。

#####

创建密钥对

[root@mha-manager ~]#ssh-keygen -t dsa

将公钥分发到各个主机上

验证

配置hosts

部署MHANode

在所有运行MySQL服务的服务器上运行MHA Node，无论是master还是slave。由于MHA　Manager需要MHA　Node，因此在运行MHA　Manager的服务器上也需要安装MHA　Node。当然也可以在任意一个slave上运行MHA　Manager。因为部署步骤相同，所以就列出一个安装步骤（在mha-manager服务器上）

创建目录

[root@mha-manager ~]# mkdir /softs

安装MHA Node