mysql高可用之mha_MySQL
Jun 01, 2016 pm 12:58 PMmysql高可用有很多方案，如mmm，mysql cluster等，但都无法真正应用到生产环境。偶然间发现mha(master high availability)，目前在mysql高可用方面是一个相对成熟的解决方案，它能够在较短时间内实现自动故障检测和故障转移，通常在10~30秒内；并且在replication环境中，mha能够很好的解决复制过程中数据行一致性问题。我们可以在不改动现有环境下部署mha，安装非常简单。
mha由mha manager(管理节点)和mha node(数据节点)组成。管理节点可以单独部署在一台独立的机器上管理一个或多个master-slave集群，也可以部署在一台slave节点上。数据节点运行在每台mysql服务器上，管理节点会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将其他的slave重新指向新的master。
如何保持数据的一致性呢？主要通过mha node的以下几个工具实现，但是这些工具由mha manager触发：
save_binary_logs如果master的二进制日志可以存取的话，保存复制master的二进制日志，最大程度保证数据不丢失
apply_diff_relay_logs相对于最新的slave，生成差异的中继日志并将所有差异事件应用到其他所有的slave
注：对比的是relay log，relay log越新就越接近于master，才能保证数据是最新的。
purge_relay_logs删除中继日志而不阻塞sql线程
好了，基本就介绍那么多，如果想详细了解请访问官网：https://code.google.com/p/mysql-master-ha，下面我们来部署下。
mha架构如下：
master：10.10.10.56 hostname:rd-mysql-test1server-id:1写入，数据节点
slave1：10.10.10.57 hostname:rd-mysql-test2 server-id:2读，数据节点，备选master(candicate master)
slave2：10.10.10.57 hostname:rd-mysql-test3 server-id:3读，数据节点
mha manager：10.10.10.59 hostname:rd-mysql-test4-管理节点
1.在所有节点安装mha node
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
注意：mha是由perl编写，因此依赖perl模块，我们使用epel源来安装相关perl模块。
2.安装mha manager1 2 3 4 |
|
2.mha manager的版本可以后manager node的版本不一样，建议使用新版本。
安装完成后会在/usr/local/bin目录下生成以下脚本：
1 2 3 4 5 6 7 8 9 10 11 |
|
另外在/usr/local/src/mha4mysql-manager-0.53/samples/scripts下还有以下脚本，我们将其复制到/usr/local/bin
1 2 3 4 5 6 7 8 |
|
3.在所有节点上做ssh免密码登录
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
(1)在master和slave上创建复制用户并授权
1 2 3 4 |
|
(2)两台slave设置
1 2 3 |
|
(3)两台slave设置read_only(从库对外只提供读，因为slave可能选为master，因此不把它写入配置文件)
mysql -e 'set global read_only=1'
(4)master和slave都添加管理账号
1 2 3 4 |
|
(1)log-bin必须在candicate mater(备选主机)上必须设置，如果备选主机没有设置log-bin，那么在故障转移过程mha manager会检测不到log-bin，则备选主机不会成为新的master，即使你设置过candicate master=1；如果所有slave没有设置log-bin，则mha manager不会启动故障转移。
(2)replication用户必须在所有的slave上存在，否则masterha_check_repl会不成功
(3)replication过滤规则（binlog-do-db和replicate-ignore-db等）必须在所有msyql上一致，否则masterha_check_repl会不成功
5.mha配置
(1)创建mha配置文件目录并编辑配置文件
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
|
注意：以上相关执行脚本命令的已经全都注释点，后面我们会通过手动执行的方式来充分了解，当我们全都弄明白了在恢复自动执行。
(2)设置relay log的清除方式默认情况下，slave上的relay log在sql thread执行完成后会自动清除,但是这些relay log可能在恢复其他slave时仍然需要。因此我们禁用relay log自动清除功能，使用定期清除relay log的方法。然而在手动清除的时候我们需要考虑到复制延迟的问题，在ext3文件系统中，删除大文件会花费很长的时间，这会导致严重的复制延迟。为了避免这种情况，我们可以通过建立硬链接的方式来避免。
mha node用purge_relay_logs工具来实现，它会创建硬链接，执行set global relay_log_purge=1，等待几秒钟以便sql thread能够切换到新的relay log，最后执行set global log_purge=0.
具体参数如下：
1 2 3 4 5 6 |
|
1 2 3 4 5 6 |
|
注意：确定使用的用户是否能够登录mysql
我们手动执行以下：1 2 3 4 5 6 7 8 9 10 11 |
|
检查所有的节点ssh是否能够互通
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 |
|
根据官方文件说明：
1 2 3 |
|
为了便于我们充分了解相关脚本命令，我们将/etc/mha/app1.conf中的相关执行脚本的命令行全都注释掉，通过手动执行的方式来体验下，在弄明白所有脚本后我们在自动执行。
8.开启mha manager监控
1 |
|
其中：
1 2 3 4 5 |
|
注意：现在mha manager进行没有作为daemon来运行，如果故障转移成功完成或master进程意外被杀，那么监控将会停止。我们可以使用daemontools来是监控作为daemon来运行。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
1 2 3 |
|
同时在/usr/local/bin下对上面这些命令建立了软连接方便我们执行。另外创建监控/services目录，并在/etc/inittab下也有变化：
SV:123456:respawn:/command/svscanboot
它使用init的方式来守护自己。
1 2 3 4 5 6 7 8 9 |
|
9.查看是否启动
1 2 |
|
启动后会在/var/log/masterha/app1下生成app1.master_status.health manager.log两个文件。
关闭监控我们可以使用masterha_stop --conf=/etc/mha/app1.cnf
10.测试一.自动failover
1.我们关闭master的mysql
[root@rd-mysql-test1 mysql]# mysqladmin shutdown
我们查看/var/log/masterha/app1会发现以下情况：
1 2 |
|
saved_master_binlog_from_10.10.10.56_3306_20150807180251.binlog是从master上复制过来的二进制日志。
manager.log是复制环境状态的检查并记录了整个failover的过程，我们可以failover报告：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
从报告中可以看出故障迁移是成功，我们还可以看看mysql的状态确认迁移是否成功。
整个迁移过程如下：
(1)检查配置文件阶段，检查配置文件中master存活
(2)宕机master保证应用不会连接，会使用shutdown_script配置的脚本；如果master_ip_failover_script设置的话，将会进行VIP漂移切换
(3)master恢复阶段，其中包括：
获取最新的slave的二进制日志
从master上保存二进制日志并和最新的slave上的rilay log对比差异，将差异保存到slave的remote_workdir=/tmp下，然后再将其保存到mha manager上的/var/log/masterha/app1下
选出新的master，如果设置了candidate_master，则优先选为新masterha_conf_host来添加。
对比新master的relay log，生成差异并将mha manager上的日志复制到remote_workdir=/tmp下
将差异应用在新master上
(4)slaves恢复阶段，其中包括：
并行操作，对比relay log
并行操作，将mha managermha manager上的日志复制到remote_workdir=/tmp下，将差异日志应用到slave
(5)将slave提升为新的master，并将老master从配置文件中删除。
大体过程如下，总结的比较吃力，请详见manager.log。
注：1.成功完成一次故障转移后mha manager的监控会停止，若新master出现宕机时failover则不会发生，因此我们需要使用daemontools将将他作为daemon运行
2.当failover完成后，会将老的master从配置文件删除，若我们在修复好老的master后，希望将其作为slave继续使用，我们需要使用masterha_conf_host来添加，如：
1 2 3 4 5 6 7 8 9 |
|
好了，mha就先写到这里，内容有点多，有可能有错误的地方请指正，另外细节性的东西有很多，稍微不注意就会掉坑里，可能说的不完全，大家可以到官网仔细看看吧。
熱門文章
熱門文章
熱門文章標籤
記事本++7.3.1
好用且免費的程式碼編輯器
SublimeText3漢化版
中文版，非常好用
禪工作室 13.0.1
強大的PHP整合開發環境
Dreamweaver CS6
視覺化網頁開發工具
SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)
在 Linux 中運行 MySQl（有/沒有帶有 phpmyadmin 的 podman 容器）
Mar 04, 2025 pm 03:54 PM
在 Linux 中運行 MySQl（有/沒有帶有 phpmyadmin 的 podman 容器）
