高可用mysql之MHA的原理
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/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的问题。