首页 > 代码库 > 高可用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/lib/MHA		perl写的操作binlog的接口		https://github.com/yoshinorim/mha4mysql-node/tree/master/lib/MHA		https://github.com/ovaistariq/mha-helper		python封装的工具脚本,用来调用perl写的命令接口。*	如何辨别从哪个偏移量开始进行中继日志补偿?!	    很久之前,MHA的作者使用mysqlbinlog来识别中继日志的偏移,但现在不用了,自己解析那个二进制文件的事件头部	就行了,就可以辨别事件的起始偏移量。	    不适用mysqlbinlog的原因有几个,最主要是因为mysqlbinlog总是打印出所有事件的所有内容,不仅仅只是打印出事件头部,	但我们仅仅需要的是去分析头部而已。因为必要的定位信息都在头部,包括事件类型、master id、事件长度、下一个事件的偏移量。	事件体我们并不关心,那么,使用mysqlbinlog不仅在读取二进制日志时增加了性能开销,也让我们需要格外警惕一些与日志中的关键字	“撞衫”的sql语句,比如end_log_pos\# at等等。	    为了避免错误的识别起始偏移信息,mysqlbinlog加上--base64-output=always选项是有帮助的,但是这个选项只在mysql 5.1和mysql 5.5	中支持,5.0不支持,5.6中被移除了。而且这个选项说不定会漏掉某些事件。	    上面的行不通的话,只能逆向来搜索了,rotate事件是个好的地标。	*	快速的中继日志定位	    假定待恢复的目标从库中的master_log_file:pos是mysqld-bin.000001:504810023,最新从库中的io线程的读头在 mysqld-bin.000001:504810689,	而且最新的中继日志文件是mysqld-relay-bin.000001并且超过了500M。目标从库和最新从库的IO线程读头只相差几百个字节。如果MHA从中继日志	头部开始解析,那么故障切换的时间就太长了。			$latest_mlf = Master_Log_File on the latest slave			$target_mlf = Master_Log_File on the recovery target slave			$latest_rmlp = Read_Master_Log_Pos on the latest slave 			$target_rmlp = Read_Master_Log_Pos on the recovery target slave			$offset = $latest_rmlp - $target_rmlp			$filesize = File size of the latest relay log file on the latest slave			if ($latest_mlf eq $target_mlf) && ($filesize > $offset),那么MHA就可以决定下来,起始恢复点是最新从库的最新中继文件中的			($filesize - $offset)偏移处,		*	如何为待恢复的目标从库生成relaylog补偿和binlog补偿	总的来说,分三段来完成补偿:		- 目标从库的exec_master_log_pos到目标从库的read_master_log_pos			由于中继日志中待回放的事件必须组成一个完整的事务,begin和commit之间的所有内容,如果主库宕机前从库并未收到完整的事务事件,			那么exec_master_log_pos < read_master_log_pos,他们之间只是事务的一部分,没得到重放执行。		- 目标从库的read_master_log_pos到最新从库的read_master_log_pos			目标从库的中继日志可能落后于最新从库。		- 最新从库的read_master_log_pos到崩溃主库的binlog结尾处	之前,MHA的作者是每段都采用mysqlbinlog输出的,这样会带来两个问题:		- 在每个binlog文件开始处和每次mysqlbinlog输出的结尾处都添加rollback语句。需要显式过滤。		-	如果row-based event刚好被割裂到两个文件中,那么mysqlbinlog的输出可能不正确。	现在,改为三段都是通过直接解析二进制文件的事件头部来定位和搜索,接着将三段组合成一个大的二进制文件,然后再交给	mysqlbinlog来输出,只输出一次,方便过滤rollback,也没有了割裂row event的问题。	

  

高可用mysql之MHA的原理