高可用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的问题。