mha mysql yuanli_高可用mysql之MHA的原理

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/MHAperl写的操作binlog的接口

https://github.com/yoshinorim/mha4mysql-node/tree/master/lib/MHA

https://github.com/ovaistariq/mha-helperpython封装的工具脚本，用来调用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的问题。