MHA原理

MHA工做原理

　　主库挂了，可是主库的binlog都被所有从库接收，此时会选中应用binlog最全的一台从库做为新的主库，其余从主只须要从新指定一下主库便可(由于此时,全部从库都是一致的，因此只须要从新指定一下从库便可)。

　　主库挂了，全部的binlog都已经被从库接收了，可是，主库上有几条记录尚未sync到binlog中，因此从库也没有接收到这个event，若是此时作切换，会丢失这个event。此时，若是主库还能够经过ssh访问到，binlog文件能够查看，那么先copy该event到全部的从库上，最后再切换主库。若是使用半同步复制，能够极大的减小此类风险。

　　主库挂了，从库上有部分从库没有接收到全部的events，选择出最新的slave，从中拷贝其余从所缺乏的events。

问题一、

　　如何肯定哪些event没有成功接收。

问题二、

　　如何让全部从库保持一致。

致使复制问题的缘由是由于MySQL采用异步复制，并不保证全部事件被从库接收，对于此类问题的解决方案:

一、Heartbeat + DRBD

　　代价：额外的被动master，而且不处理任何流量。

　　性能：为了保证事件被及时写入，innodb_flush_log_at_trx_commit=1,sync_binlog=1. 这样就会致使性能急速降低。

二、MySQL Cluster

　　真正的高可用，可是只支持InnoDB。

三、Semi_synchronous Replication (5.5+)

　　半同步复制极大减小了"binlog事件只存在于master上"的风险。保证至少有一台从库接收到了提交的binlog事件。其余的从可能没有接收，可是不影响提交了。

四、Global Transaction ID

　　由谷歌开发的插件。

MHA的切换步骤

一、从down的主上面获取到binlog事件。

二、肯定最新(最全)的从库。

三、分别应用不一样的relay log事件到其余从库。

四、应用从主库上获取的binlog事件(发生故障时的事件)。

五、提高一个从库为新的主库(此时从库已经一致)。

六、将其余从库的主库从新指定，同时，自动检测主库故障。

如何肯定最近从库以及丢失的events

一、Master_Log_File,Read_Master_Log_Pos 能够肯定(从库的IO线程)读取主库的binlog的最新进度。

二、Relay_Log_File,Relay_Log_Pos 肯定SQL线程执行本地Relay_Log的最新进度。

三、因为Relay_Log的进度和binlog是不同的。因此若是只看Relay_Log的信息没法肯定执行事件的实际位置，Relay_Master_Log_File,Exec_Master_Log_Pos 本地SQL线程实际上执行binlog位置(用于计算seconds_behind_master)。

四、各个从库之间，比较Master_Log_File,Read_Master_Log_Pos能够肯定哪台从库接收到的日志是最完整的。

五、当找出最新最全的从库以后，应用diff到其余从库。

　　仅仅比较上面2个参数是不够肯定具体缺失的events，在relay log中日志开头会指定是读哪一个binlog，文尾的end_log_pos表示最后读到binlog的位置。经过对比不一样从库上，最新的relay_log中的binlog file和end_log_pos位置来对比还有哪些events缺失(每一个at xxx就是一个event)。若是是一个很大的事务，产生了不少日志信息(事务只会保存在一个binlog文件中,可是会出如今2个relay_log中。)面对这种情形,若是只接受到了部分的events信息。从库是不会重作这些relay_log。此时的Master_Log_File,Read_Master_Log_Pos 会指向读取到的binlog的最新位置(这是IO线程负责的)，而Relay_Master_Log_File,Exec_Master_Log_Pos只会指向最后执行的commit事务。这样就保证了不会使数据库进入不一致状态。那么在接受到其余从库最新日志的时候，也是完整的执行一次该事务(即便本身的Relay log已经有部分记录了)。

MHA须要考虑的注意事项

一、若是使用mysqlbinlog打开binlog和relaylog，会自动在文本里面添加rollback关键字因此要在日志中清理掉由mysqlbinlog添加的rollback。

　　ROLLBACK /* added by mysqlbinlog */

二、因为mha默认关闭relay_log_purge。因此要手动按期清理。为了保证在发生故障时，能有足够多的relay log用户恢复，因此不该该自动清理。关闭这个参数以后，SQL线程不会按期清理Relay_log，因此很快会填满磁盘空间。Relay_log没有像binlog同样有自动过时参数expire_logs_days。

按期清理的方式：

　　set global relay_log_purge=1;

　　flush logs;/* SQL线程会自动清理多余的Relay_Log_File */

　　set global relay_log_purge=0;

　　若是有较大的日志，让SQL线程自动删，会致使SQL线程锁住，从库落后主库。

　　ln relay-log.* /tmp/archive_dir/

　　mysql -e"set global relay_log_purge=1;flush logs;set global relay_log_purge=0;"

　　rm -rf /tmp/archive_dir/*   */

　　这样就不会占用宝贵的SQL线程了。即使如此也不要在全部的从库上同一时间执行一个计划任务(清除Relay_Log),不然会致使没有Relay_Log用户恢复的情形出现。

三、要肯定SQL线程是否执行完全部的events。

　　(1)、等待事物执行。

　　(2)、select MASTER_POS_WAIT(master_log_file,read_master_log_pos);若是全部从库已经与主库一致了，上面的命令失效，若是只有部分事物日志传送到从库，SQL线程也不会同步到Read_Master_Log_Pos。

　　(3)、show processlist查看输出。提示:"Has read all relay log;waiting for the slave I/O thread to update it"

　　(4)、要处理恶意查询，恶意查询：insert into t1 values(0,0,"ROLLBACK");

　　(5)、有多个从库时，并行恢复。

　　(6)、采用ROW FORMAT，对于采用row格式记录的日志，可能出现多个"#at"条目+相同的"end_log_pos"条目。Table_map+Write_rows+STMT_END 

故障自动转移的内容

一、检测master failure。

二、Node Fencing(经过干掉故障master 避免脑裂)。

三、更新写入IP(VIP)。

经过脚本完成自动转移，同时在故障发生时要自动调用脚本。

　　(1)、确保文件和对应的目录存在，SSH互信成功----避免由于低级错误致使转移失败。

　　(2)、若是有从库服务器挂掉，或者SQL线程挂掉，或者在8个小时内发生过转移了----都再也不执行故障转移。

若是发生故障：发送邮件报警，停掉新主库上的备份任务，更新内部工具的管理地址(从旧库指向新库)。

MHA工具介绍

在manager上

　　master_monitor：检测master状态。

　　master_switch：执行故障转移(手动执行，若是自动则要使用masterha_manager)。

　　masterha_manager：启动mha，执行mha的管理操做。

在node上

　　save_binary_logs：复制主库二进制日志。

　　apply_diff_relay_logs:从最全的slave上生成diff Relay log,应用全部从主库copy来的的binlog中的events。

　　filter_mysqlbinlog:清理掉有mysqlbinlog工具带来的ROLLBACK events。

　　purge_relay_logs:在不中止SQL线程的前提下删除Relay_log。

MHA处理案例

master上内核崩溃，10内检查master状态，肯定master不可用以后power off，选择新的master,recovery，并行恢复其余从库。

MHA的限制

不支持多级复制 M->M->S。且不支持日志为statment级别(SBR)的load data infile和MySQL5.0之前的版本。