高可用mysql之MHA的原理

MHA 如何工作的？

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

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