Server | WLAN | Memory | Roles |
---|---|---|---|
dbtest01 | 172.16.1.121 | 2G | Master & mha_node |
dbtest02 | 172.16.1.122 | 2G | Slave & mha_node |
dbtest03 | 172.16.1.123 | 2G | Slave & mha_manager |
MHA (Master High Availability)能够在较短的时间内实现自动故障检测和故障转移,通常在 10 - 30 秒以内;在复制框架中,MHA 能够很好地解决复制过程中的数据一致性问题,由于不需要在现有的 Replication 中添加额外的服务器,仅需要一个 Manager 节点,而一个 Manager 能管理多套复制,所以能大大地节约服务器的数量;另外,安装简单,无性能损耗,以及不需要修改现有的复制部署也是它的优势之处。
MHA 提供在线主库切换的功能,能够安全地切换当前运行的主库到一个新的主库中(通过将从库提升为主库),大概 0.5 - 2 秒内即可完成。
MHA 由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点),MHA Manager 可以独立部署在一台独立的机器上管理多个 Master-Slave 集群,也可以部署在一台 Slave 上。当 Master 出现故障时,它可以自动将最新数据的 Slave 提升为新的 Master,然后将所有其他的 Slave 重新指向新的 Master 。整个故障转移过程对应用程序是完全透明的 。
1.把宕机的 Master 二进制日志保存下来
2.找到 Binlog 位置点最新的 Slave
3.在 Binlog 位置点最新的 Slave 上用 relay-log(差异日志)修复其它 Slave
4.将宕机的 Master 上保存下来的二进制日志恢复到含有最新位置点的 Slave 上
5.将含有最新位置点 Binlog 所在的 Slave 提升为 Master
6.将其它 Slave 重新指向新提升的 Master,并开启主从复制
1.MHA 属于 C/S 结构
2.一个 Manager 节点可以管理多套集群
3.集群中所有的机器都要部署 node 节点
4.node 节点才是管理集群机器的
5.Manager 节点通过 ssh 连接 node 节点,管理 node 节点
6.Manager 可以部署在集群中除了主库以外的任意一台机器上
MHA Manager 节点不止需要安装MHA Manager 软件,还需要安装 MHA Node 软件
# 解压 二进制包,查看 Manager 命令工具
[root@db01 ~]# ll mha4mysql-manager-0.56/bin/
# 检查主从复制状态
masterha_check_repl
# 检查 SSH 免密配置
masterha_check_ssh
# 检查当前 MHA 运行状态
masterha_check_status
# 添加或删除配置 server 信息(app1.conf 中 [serverxx] 配置)
masterha_conf_host
# 启动 MHA 命令
masterha_manager
# 检测 Master 是否宕机
masterha_master_monitor
# 控制故障转移(自动或者手动)
masterha_master_switch
# 建立 TCP连接(从远程服务器)
masterha_secondary_check
# 关闭 MHA 命令
masterha_stop
# 解压 二进制包,查看 Node 命令工具
[root@db01 ~]# ll mha4mysql-node-0.56/bin/
# 对比中继日志(Relay-log)差异,识别差异的中继日志事件并将其差异的事件应用于其他的 Slave
apply_diff_relay_logs
# 去除不必要的 ROLLBACK(回滚)事件
filter_mysqlbinlog
# 清除中继日志(Relay-log)
purge_relay_logs
# 保存二进制日志(Bin-log),保存和复制master的二进制日志
save_binary_logs
1.Masterfailover and slave promotion can be done very quickly
自动故障转移快
2.Mastercrash does not result in data inconsistency
主库崩溃不存在数据一致性问题
3.Noneed to modify current MySQL settings (MHA works with regular MySQL)
不需要对当前 MySQL 环境做重大修改
4.Noneed to increase lots of servers
不需要添加额外的服务器(仅一台 Manager 就可管理上百个 Replication)
5.Noperformance penalty
性能优秀,可工作在半同步复制和异步复制,当监控 MySQL 状态时,仅需要每隔 N 秒向 Master 发送 ping 包(默认3秒),所以对性能无影响。你可以理解为 MHA 的性能和简单的主从复制框架性能一样。
6.Works with any storage engine
只要 Replication 支持的存储引擎,MHA 都支持,不会局限于 Innodb
主要通过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://www.cnblogs.com/zzzwqh/p/13386956.html