高可用mysql之MHA源码剖析

* MHA的整个故障(离线)切换过程

----------------------------------------------------------------------------------------------------
- 检测主库的状态,确认是否崩溃。
- 确认服务崩溃,保存binlog,推送到主控机,并可以强制关闭主库避免脑裂。
- 找出数据最新的从库(也就是read_master_log_pos最大的),确定下新主库。
- 从最新从库上生成差异的relaylog,再加上未读取的binlog,应用到新主库,记下偏移。
- (并发)的为其他从库生成差异的relaylog和binlog,应用到各个从库。
- 从库指向新主库的偏移处,开始复制。

源码部分关键逻辑

--------------------------------------------------------------------------------------------------------
** 读取配置
** 检查配置
- 检查apply_diff_relay_log的版本号
- 连接所有服务器并读取状态(得知老主库)
- 检查参数传进来的崩溃主库是否与老主库地址一致,否则终止切换
- 检查老主库是否在离线主机列表中,不在的话就终止切换
- 检查是否真的连接不上mysql服务
- 检查所有在线从库,是否都指向老主库
- 检查是否有些不该忽略失败的从库已经离线
- 检查上次切换是否失败
- 检查上次切换发生时间与本次切换的时间间隔,太短则终止
- 从所有从库获取“切换锁”
- 保证所有从库的slave sql线程已经启动
** 如果支持gtid自动定位但未启用,那么应该强制apply_diff_relay_log禁用log_bin??
** 强制关闭
- (并发)强制停止所有从库的slave io线程
- 探测从主控机到崩溃主库所在主机的ssh可达性
- 执行master_ip_failover_script,保证崩溃主库所在主机的ip失活防脑裂,否则终止切换
- 只要有一个在线从库的salve io线程停止失败,那么就终止切换

** 探测出复制延迟最小的从库、复制延迟最大的从库
** 根据最新从库的slave io线程的读头,保存老主库的binlog。
- 如果崩溃主库所在主机不可达,那么久丢失binlog(Read_Master_Log_Pos to the tail)
- 如果可达,ssh连接上去,然后执行save_binary_logs --command=save,将保存后的binlog拷贝到主控机,这步称呼read_to_tail。
** 根据最新、最老从库的读头以及某些从库的可忽略失败,来决定哪个从库作为relaylog、binlog补偿的基准
- 如果所有从库的读头一致,跳过
- ssh逐一连接最新从库,执行apply_diff_relay_logs --command=find,看是否realylog包含了最老从库的读头。
- 如果没有用来补偿的基准从库,终止切换
** 选择新主库(新主库不一定是最新从库,参照“在线切换”中的描述)
** 恢复新主库
- 若果新主库的读头落后于最新从库,那么ssh连接上最新从库,执行apply_diff_relay_logs --command=generate_and_send,
从最新从库的relaylog中提取新主库读头直到最新从库读头处的二进制日志,这步称呼为read_to_latest,
$latest_slave->{Master_Log_File}:$latest_slave->{Read_Master_Log_Pos}
- 将主控机保存好的最新从库读头到主库binlog尾部的日志(read_to_tail),拷贝到新主库
- 如果不是最新从库或者有保存过read_to_tail,那么就应用差异日志。
-- 首先等待新主库上已经有的relaylog都重放完毕,停止slave sql线程
-- 读取最新复制状态
-- ssh执行save_binary_logs --command=save, 从自身relaylog中恢复exec_to_read
-- ssh执行apply_diff_relay_logs --command=apply,将前面生成的3部分补偿日志全部导入。
- 执行主控机上的master_ip_failover --command=start脚本,激活新主库的ip。
- 关闭新主库的只读,开启可写模式。
** 恢复所有从库(类似单独恢复主库的过程)
- (并发)中继补偿,生成read_to_latest
- (并发)将早生成的read_to_tail部分,拷贝到各个从库,应用差异日志,指向新主库,启动复制
- 新主库执行reset slave

* MHA在线主库切换过程

--------------------------------------------------------------------------------------------------------------------------------------
sudo /usr/bin/masterha_master_switch --master_state=alive --conf=/etc/masterha/app1.cnf --new_master_host=192.168.128.130 --new_master_port=3309 --orig_mast\
er_is_new_slave

** 识别老主库。
- 读取配置MHA配置文件;

- 连接并读取所有的数据库服务状态;
- (并发)连接所有从库,看mysql服务是否在运行,如果机器都宕机了,那就终止本次切换。
- 遍历每台从库,获取所有能获取的信息,比如:msyql服务版本号、是否开启了gtid、是否开启了log-bin、
是否只读、复制相关系统变量和状态变量。
- 统计服务器信息:离线服务器、在线服务器、在线从库、失败从库等。
- 比较所有从库的mysql服务版本,找出最老和最新的版本。
- 验证当前真正的主库是谁?
- 统计在线服务器中的“非从库”(not_slave)标记,只能为1,否则终止本次切换过程。
- 根据从库的指向来找出存在哪些主库(支持3层复制结构(主-从-从的从))。
真正的主库必须是在“线并且可写”,如果没有一台主库可写或者存在两台可写,那么终止切换。
- 判断本次切换是否支持gtid。

- 检查所有在线从库上是否有复制账户并有相应的REPLICATION SLAVE权限;
- 必要时在老主库上进行flush tables操作;
- 从老主库获取“监视锁”;
- 从所有从库获取“切换锁”;
- 检查所有在线从库的复制健康状况;
- 读取当前的复制状态;
- 判断是否有问题(IO、SQL线程是否在运行,数据延迟多久)

** 识别新主库。
- 识别数据最新的从库;
- 比较master_log_file:read_master_log_pos。
- 选择新主库;
- 识别优先从库,在线的并带有candidate_master标记。
- 识别应该忽略的从库,带有no_master标记、或者未开启log_bin、或者mysql服务版本不是最老、与最新从库相比数据延迟比较大。
- 选择优先级依次为:优先列表、最新从库列表、所有从库列表,但一定要排除忽略列表。
- 检查新老主库的复制过滤规则是否一致;
- Binlog_Do_DB、Binlog_Ignore_DB、Replicate_Do_Table等。

** 拒绝更新,防止脑裂。
- 调用master_ip_online_change脚本,stop子命令。新主库上,设置为只读;
老主库上,禁止会话级别的log_bin、优雅等待所有sql线程退出、设置为只读、
- 必要时,在老主库,锁住所有表,并检查binlog是否已经停止前进。
binlog停止前进后,记下偏移位置。

** 重新读取所有在线从库的运行状态。

** 新主库从老主库应用完所有的事件日志。
- 新主库上,执行master_pos_wait,然后记下新主库binlog的file:pos。
- 调用master_ip_online_change脚本,start。新主库上,设置为只读。

** (并发)从库应用完老主库所有的事件日志并指向新主库。
- master_pos_wait
- change_master_and_start_slave

时间: 2024-10-12 18:01:32

高可用mysql之MHA源码剖析的相关文章

高可用mysql之MHA的原理

* 参见 https://code.google.com/p/mysql-master-ha/wiki/HowMHAWorks - 创始人的ppt文档描述设计的原理 http://www.slideshare.net/matsunobu/automated-master-failover 尽管排版不是特别吸引人,但是确实涵盖了内部设计笔记,不过可能不是最新的. - 源码参见 https://github.com/yoshinorim/mha4mysql-manager/tree/master/l

分布式架构高可用架构篇_06_MySQL源码编译安装(CentOS-6.7+MySQL-5.6)

部署环境 操作系统:CentOS-6.6-x86_64-bin-DVD1.iso MySQL 版本:mysql-5.6.22.tar.gz 操作用户:root 系统 IP:192.168.1.205 主机名:edu-mysql-01 一.服务器配置: 1.配置网络 # vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE="eth0" BOOTPROTO="static" HWADDR="00:0c:29:

MySQL高可用系列之MHA(二)

一.参数说明 MHA提供了一系列配置参数,深入理解每个参数的具体含义,对优化配置.合理使用MHA非常重要,很多高可用性也都是通过合理配置一些参数而实现的. MHA包括如下配置参数,分别说明如下: hostname/ip/port (Local Only) hostname为MySQL Server的IP地址或主机名: ip为MySQL Server的IP地址,缺省从$hostname中获取:port为MySQL Server的端口号,缺省为3306 ssh_host/ssh_ip/ssh_por

mysql高可用集群——MHA架构

目录 1.下载 2.搭建mha 2.1 系统配置 2.2 架构 2.3 添加ssh公钥信任 2.4 安装mha节点 2.5 manager配置文件 2.6 检查 2.7 启动manager进程 2.8 碰到的问题 3.测试切换 3.1 正常切换测试 3.2 回切测试 3.3 雪崩测试 3.4 主从不一致切换测试 下载 mha链接地址:http://pan.baidu.com/s/1pJkDGX9#dir/path=%2Fmysql%2FHA%2Fmha 或者:https://code.googl

MySQL高可用系列之MHA(一)

MHA,即Master High Availability Manager and Tools for MySQL,是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQL Replication(二层)环境,目的在于维持Master主库的高可用性. 一.简介 学习一个高可用小软件,不但要熟悉其功能,还要了解其架构及工作原理. 1.  架构 从架构上来说,MHA分为如下两大部分: (1) Node 我们知道,MHA是基于MySQL Replication环境的,

(升级版)Spark从入门到精通(Scala编程、案例实战、高级特性、Spark内核源码剖析、Hadoop高端)

本课程主要讲解目前大数据领域最热门.最火爆.最有前景的技术——Spark.在本课程中,会从浅入深,基于大量案例实战,深度剖析和讲解Spark,并且会包含完全从企业真实复杂业务需求中抽取出的案例实战.课程会涵盖Scala编程详解.Spark核心编程.Spark SQL和Spark Streaming.Spark内核以及源码剖析.性能调优.企业级案例实战等部分.完全从零起步,让学员可以一站式精通Spark企业级大数据开发,提升自己的职场竞争力,实现更好的升职或者跳槽,或者从j2ee等传统软件开发工程

第22章 mysql 高可用MMM、MHA

2015-10-25 目录 参考资料 [1] 唐汉明.深入浅出MySQL 数据库开发.优化与管理维护(第2版)[M].北京:人民邮电出版社,2014 [2] Schwartz.高性能MySQL(第3版)[M].北京:电子工业出版社,2013 [3] 分享MYSQL中的各种高可用技术(源自姜承尧大牛) [4] MHA工作原理 [5] 技术实战:基于 MHA 方式实现 MySQL 的高可用(1) [6] mysql HA方案: MHA [7] mysql高可用方案MHA介绍 [8] Mysql5.5

MySQL高可用架构之MHA (未完,待续)

MySQL高可用架构之MHA 简介: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. 该软件由两部分组成:

mysql实现高可用架构之MHA

一.简介 MHA(Master HA)是一款开源的 MySQL 的高可用程序,它为 MySQL 主从复制架构提供了 automating master failover 功能.MHA 在监控到 master 节点故障时,会提升其中拥有最新数据的 slave 节点成为新的master 节点,在此期间,MHA 会通过于其它从节点获取额外信息来避免一致性方面的问题.MHA 还提供了 master 节点的在线切换功能,即按需切换 master/slave 节点. MHA 是由日本人 yoshinorim