文档章节

MHA工作原理

stayfool
 stayfool
发布于 2014/09/15 17:18
字数 1818
阅读 8472
收藏 4
点赞 0
评论 1

MHA工作原理:

主库挂了,但是主库的binlog都被全部从库接收

此时会选中应用binlog最全的一台从库作为新的主库,其他从主只需要重新指定一下主库即可(因为此时,所有从库都是一致的,所以只需要重新指定一下从库即可)。


主库挂了,所有的binlog都已经被从库接收了,但是,主库上有几条记录还没有sync到binlog中,所以从库也没有接收到这个event,如果此时做切换,会丢失这个event。

此时,如果主库还可以通过ssh访问到,binlog文件可以查看,那么先copy该event到所有的从库上,最后再切换主库。


如果使用半同步复制,可以极大的减少此类风险。


主库挂了,从库上有部分从库没有接收到所有的events

选择出最新的slave,从中拷贝其他从所缺少的events

问题1、

如何确定哪些event没有成功接收

问题2、

如何让所有从库保持一致


导致复制问题的原因是因为MySQL采用异步复制,并不保证所有事件被从库接收


对于此类问题的解决方案:


Heartbeat + DRBD

代价:额外的被动master,并且不处理任何流量。

性能:为了保证事件被及时写入,innodb_flush_log_at_trx_commit=1,sync_binlog=1. 这样就会导致性能急速下降


MySQL Cluster

真正的高可用,但是只支持InnoDB


Semi_synchronous Replication (5.5+)

半同步复制极大减少了"binlog事件只存在于master上"的风险。

保证至少有一台从库接收到了提交的binlog事件。其他的从可能没有接收,但是不影响提交了


Global Transaction ID

由谷歌开发的插件。



MHA的实施步骤

1、从down的主上面获取到binlog事件

2、确定最新(最全)的从库

3、分别应用不同的relay log事件到其他从库

4、应用从主库上获取的binlog事件(发生故障时的事件)

5、提升一个从库为新的主库(此时从库已经一致)

6、将其他从库的主库重新指定


同时,自动检测主库故障。



---------------------------------------------------------------------------------

如何确定最近从库以及丢失的events


1、Master_Log_File,Read_Master_Log_Pos 可以确定(从库的IO线程)读取主库的binlog的最新进度。

2、Relay_Log_File,Relay_Log_Pos 确定SQL线程执行本地Relay_Log的最新进度。

3、由于Relay_Log的进度和binlog是不一样的。所以如果只看Relay_Log的信息无法确定执行事件的实际位置

Relay_Master_Log_File,Exec_Master_Log_Pos 本地SQL线程实际上执行binlog位置(用于计算seconds_behind_master)


4、各个从库之间,比较Master_Log_File,Read_Master_Log_Pos可以确定哪台从库接收到的日志是最完整的。


5、当找出最新最全的从库之后,应用diff到其他从库

仅仅比较上面2个参数是不够确定具体缺失的events


在relay log中日志开头会指定是读哪个binlog,文尾的end_log_pos表示最后读到binlog的位置。

通过对比不同从库上,最新的relay_log中的binlog file和end_log_pos位置来对比还有哪些events缺失(每个at xxx就是一个event)。



----------------------------------------------------------------------------------

如果是一个很大的事务,产生了很多日志信息(事务只会保存在一个binlog文件中,但是会出现在2个relay_log中。)


面对这种情形,如果只接受到了部分的events信息。从库是不会重做这些relay_log。

此时的Master_Log_File,Read_Master_Log_Pos 会指向读取到的binlog的最新位置(这是IO线程负责的),

而Relay_Master_Log_File,Exec_Master_Log_Pos只会指向最后执行的commit事务。


这样就保证了不会使数据库进入不一致状态。那么在接受到其他从库最新日志的时候,也是完整的执行一次该事务(即使自己的Relay log已经有部分记录了)


-----------------------------------------------------------------------------------

MHA需要考虑的注意事项:


1、如果使用mysqlbinlog打开binlog和relaylog,会自动在文本里面添加rollback关键字所以要在日志中清理掉由mysqlbinlog添加的rollback。

ROLLBACK /* added by mysqlbinlog */

2、由于mha默认关闭relay_log_purge。所以要手动定期清理。

为了保证在发生故障时,能有足够多的relay log用户恢复,所以不应该自动清理。

关闭这个参数之后,SQL线程不会定期清理Relay_log,所以很快会填满磁盘空间。


Relay_log没有像binlog一样有自动过期参数expire_logs_days

定期清理的方式:

set global relay_log_purge=1;

flush logs;/* SQL线程会自动清理多余的Relay_Log_File */

set global relay_log_purge=0;


如果有较大的日志,让SQL线程自动删,会导致SQL线程锁住,从库落后主库。

ln relay-log.* /tmp/archive_dir/

mysql -e"set global relay_log_purge=1;flush logs;set global relay_log_purge=0;"

rm -rf /tmp/archive_dir/*   */

这样就不会占用宝贵的SQL线程了。


即便如此也不要在所有的从库上同一时间执行一个计划任务(清除Relay_Log),否则会导致没有Relay_Log用户恢复的情形出现。


3、要确定SQL线程是否执行完所有的events

1、等待事物执行

2、select MASTER_POS_WAIT(master_log_file,read_master_log_pos);

如果所有从库已经与主库一致了,上面的命令失效

如果只有部分事物日志传送到从库,SQL线程也不会同步到Read_Master_Log_Pos。

3、show processlist查看输出。提示:"Has read all relay log;waiting for the slave I/O thread to update it"


4、要处理恶意查询

恶意查询:insert into t1 values(0,0,"ROLLBACK");



5、有多个从库时,并行恢复。



6、采用ROW FORMAT

对于采用row格式记录的日志、

可能出现多个"#at"条目+相同的"end_log_pos"条目。

Table_map+Write_rows+STMT_END 


-----------------------------------------------------------------------------------------------



故障自动转移的内容:

1、检测master failure

2、Node Fencing(通过干掉故障master 避免脑裂)

3、更新写入IP(VIP)


通过脚本完成自动转移,同时再故障发生时要自动调用脚本.

1、确保文件和对应的目录存在,SSH互信成功----避免因为低级错误导致转移失败

2、如果有从库服务器挂掉,或者SQL线程挂掉,或者在8个小时内发生过转移了----都不再执行故障转移


如果发生故障:

发送邮件报警

停掉新主库上的备份任务

更新内部工具的管理地址(从旧库指向新库)..

..

..

..


-------------------------------------------------------------------------------------------

MHA工具介绍


在manager上


master_monitor:检测master状态

master_switch:执行故障转移(手动执行,如果自动则要使用masterha_manager)

masterha_manager:启动mha,执行mha的管理操作


在node上

save_binary_logs:复制主库二进制日志

apply_diff_relay_logs:从最全的slave上生成diff Relay log,应用所有从主库copy来的的binlog中的events

filter_mysqlbinlog:清理掉有mysqlbinlog工具带来的ROLLBACK events

purge_relay_logs:在不停止SQL线程的前提下删除Relay_log


MHA处理案例:

master上内核崩溃

10内检查master状态。

确定master不可用之后power off

选择新的master,recovery

并行恢复其他从库



MHA的限制:

不支持多级复制 M->M->S

不支持日志为statment级别(SBR)的load data infile 

不支持MySQL5.0以前的版本


© 著作权归作者所有

共有 人打赏支持
stayfool
粉丝 2
博文 16
码字总数 9906
作品 0
深圳
数据库管理员
加载中

评论(1)

落叶刀
落叶刀
请教一下,mysql现在比较靠谱的中间件有哪个?
linux 服务原理

1 nginx 工作原理 2 keepalived 工作原理 3 mysql 主从复制原理 mha 高可用原理 4 inotify 实时同步原理 5 nfs原理 rpcbind服务原理 6 rsync 工作原理 7 ssh 工作原理 8 ansible 工作原理...

小辛linux ⋅ 2017/06/04 ⋅ 0

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

MySQL高可用架构之MHA 简介: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作...

jinyan2049 ⋅ 2015/03/18 ⋅ 0

企业中MySQL主流高可用架构实战三部曲之MHA

老张最近两天有些忙,一些老铁一直问,啥时更新博文,我可能做不到天天更新啊,但保证以后一有空就写一些干货知识分享给大家。 我们如果想要做好技术这项工作,一定要做到理论与实践先结合。...

superZS ⋅ 2017/07/27 ⋅ 0

第7章 二篇、【MHA】介绍

【2016年11月30日】 MHA作者是yoshinori Matsunobu,目前就职与facebook,它与MMM架构都是采用perl语言编写,可在宕机时间(通常为10~30s)内完成故障切换工作。并且还支持在线切换,从当前运...

刘彬51cto ⋅ 2016/11/30 ⋅ 0

keepalived+MHA实现mysql主从高可用集群

本节索引 原理分析 实验环境准备 主从复制集群 安装MHA包 初始化MHA 配置Keepalived 故障出现 故障恢复 总结 一 原理分析 1 MHA简介: MHA(Master High Availability)目前在MySQL高可用方面...

vincenteve ⋅ 2017/11/14 ⋅ 0

MySQL高可用之MHA—MHA介绍

MHA简介 MHA是由日本人yoshinorim(原就职于DeNA现就职于FaceBook)开发的比较成熟的MySQL高可用方案。MHA能够在30秒内实现故障切换,并能在故障切换中,最大可能的保证数据一致性。目前淘宝...

844365389 ⋅ 2016/05/09 ⋅ 0

浅谈秒级故障切换!用MHA轻松实现MySQL高可用(一)

MHA简介 MHA是由日本人youshimaton(原就职于DeNA,现就职于FaceBook)开发的比较成熟的MySQL高可用方案。MHA能够在30秒内实现故障切换,并能在故障切换中,最大可能的保证数据一致性。目前淘...

凛冬一壶酒 ⋅ 2017/08/06 ⋅ 0

MySQL高可用架构之MHA

MHA简介: MHA是由日本人yoshinorim(原就职于DeNA现就职于FaceBook)开发的比较成熟的MySQL高可用方案。MHA能够在30秒内实现故障切换,并能在故障切换中,最大可能的保证数据一致性。 该软件...

LUksl ⋅ 2017/11/23 ⋅ 0

构建MHA实现MySQL高可用集群架构

一、MHA简介 MHA(Master HighAvailability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环...

51tanxiaojun ⋅ 04/22 ⋅ 0

基于Docker的mysql mha 的集群环境构建实践

12月2日,云计算高级工程师王佩老师,在【DBA+社群】中间件用户组进行了一次主题为“基于Docker的mysql mha 的集群环境构建实践”的线上分享。小编特别整理出其中精华内容,供大家学习交流。...

王佩 ⋅ 2015/12/04 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

Linux中的端口大全

1 被LANA定义的端口 端口 名称 描述 1 tcpmux TCP 端口服务多路复用 5 rje 远程作业入口 7 echo Echo 服务 9 discard 用于连接测试的空服务 11 systat 用于列举连接了的端口的系统状态 13 d...

寰宇01 ⋅ 17分钟前 ⋅ 0

Confluence 6 如何备份存储文件和页面信息

备份的 ZIP 文件包含有 entities.xml,这个 XML 文件包含有 Confluence 的所有页面内容和存储附件的目录。 备份 Zip 文件结构 页面的附件是存储在附件存储目录中的,通过页面和附件 ID 进行识...

honeymose ⋅ 19分钟前 ⋅ 0

【每天一个JQuery特效】根据状态确定是否滑入或滑出被选元素

主要效果: 本文主要采用slideToggle()方法实现以一行代码同时实现以展开或收缩的方式显示或隐藏被选元素。 主要代码如下: <!DOCTYPE html><html><head><meta charset="UTF-8">...

Rhymo-Wu ⋅ 23分钟前 ⋅ 0

度量.net framework 迁移到.net core的工作量

把现有的.net framework程序迁移到.net core上,是一个非常复杂的工作,特别是一些API在两个平台上还不能同时支持。两个类库的差异性,通过人工很难识别全。好在微软的工程师们考虑到了我们顾...

李朝强 ⋅ 28分钟前 ⋅ 0

请不要在“微服务”的狂热中迷失自我!

微服务在过去几年一直是一个非常热门的话题(附录1)。何为“微服务的疯狂”,举个例子: 众所周知,Netflix在DevOps上的表现非常棒。Netfix可以做微服务。因此:如果我做微服务,我也将非常...

harries ⋅ 30分钟前 ⋅ 0

oAuth2 升级Spring Cloud Finchley.RELEASE踩坑分享

背景 6.19号,spring团队发布了期待已久的 Spring Cloud Finchley.RELEASE 版本。 重要变化: 基于Spring Boot 2.0.X 不兼容 Spring Boot 1.5.X 期间踩过几个坑,分享出来给大伙,主要是关于...

冷冷gg ⋅ 今天 ⋅ 0

OSChina 周一乱弹 —— 理发师小姐姐的魔法

Osc乱弹歌单(2018)请戳(这里) 【今日歌曲】 @冰冰棒- :分享田馥甄的单曲《My Love》 《My Love》- 田馥甄 手机党少年们想听歌,请使劲儿戳(这里) @Li-Wang :哎,头发又长了。。。又要...

小小编辑 ⋅ 今天 ⋅ 8

Kafka1.0.X_消费者API详解2

偏移量由消费者管理 kafka Consumer Api还提供了自己存储offset的功能,将offset和data做到原子性,可以让消费具有Exactly Once 的语义,比kafka默认的At-least Once更强大 消费者从指定分区...

特拉仔 ⋅ 今天 ⋅ 0

NEO智能合约之发布和升级(二)

接NEO智能合约之发布和升级(一),我们接下来说说智能合约的升级功能。 一 准备工作 合约的升级需要在合约内预先设置好升级接口,以方便在升级时调用。接下来我们对NEO智能合约之发布和升级...

红烧飞鱼 ⋅ 今天 ⋅ 0

个人博客的运营模式能否学习TMALL天猫质量为上?

心情随笔|个人博客的运营模式能否学习TMALL天猫质量为上? 中国的互联网已经发展了很多年了,记得在十年前,个人博客十分流行,大量的人都在写博客,而且质量还不错,很多高质量的文章都是在...

原创小博客 ⋅ 今天 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部