MySQL高可用之MHA的实现及大规模运维实践

MySQL高可用之MHA的实现及大规模运维实践高可用定义：衡量正常运行的百分比。覆盖面：系统硬件(磁盘、存储、电源)网络应用缓存中间层数据库概述1.MHA简介2.项目介绍及wiki3.MHA架构4.MHA集中化管理5.Managre配置6.切换参数7.差异Binlog和RelayLog补偿8.MHA优缺点9.MHA切换流程10.对MHA的改进11.我们遇到的问题及解决方法MHA简介全称：MasterHighAvailableManager开源：语言：perl关于作者：=1MHA0.52ManagerS1.1Master2S2.2S1.2S2.1两主多从监控机MHA组集中化管理MHAManagerslave1slave2Masterslave1salve2Mastersalve1slave2MasterManager配置重要参数：配置文件：candidate_master=1no_master=1remote_workdirmaster_binlog_dirclient_bindir=/usr/local/mysql/binclient_libdir=/usr/lib/mysqlsecondary_check_scriptmaster_ip_failover_scriptmaster_ip_online_change_scriptshutdown_scriptreport_scriptlatest_priorityping_type=select|CONNECT|INSERTping_intervalmulti_tier_slave切换参数:masterha_master_switch命令参数:--master_state=alive|dead--remove_orig_master_conf--skip_lock_all_tables--orig_master_is_new_slave--running_updates_limit--running_seconds_limit常用命令：masterha_check_sshmasterha_check_replmasterha_check_statusmasterha_conf_hostmasterha_managermasterha_master_monitormasterha_master_switchmasterha_secondary_checkmasterha_stopMHA要点总结至少3个节点Manager节点Node节点CandidateMaster心跳(ping|CONNECT|INSERT)多路检测主库GTID支持MasterRouterSwitchHost检测算法单路多路Manager监控机Binlog补偿和Relaylog补偿Masterbinlog.000010Pos:930binlogS1relaybin.000003Pos:1000binlog.000010Pos:730RelaylogS2relaybin.000005Pos:960binlog.000010Pos:830RelaylogNewMaster(S2)与Master差异Binlog:Master的binlog.000010:830至binlog.000010:930之间。S1与NewMaster(S2)差异Relaylog=S2的relaybin.000005:end_log_pos(730)至relaybin.000005:end_log_pos(830)之间。NewMaster补偿：DiffBinlogSlave补偿：DiffBinlog+DiffRelayLog补偿差异RelayLog实现CandicaterMasterRelayLogpurge:以往的MySQLHA方案1.数据一致性？2.延时导致block？3.版本的更新？MHA与MMM的比较数据丢失vip脑裂版本维护公司选择高可用方案MHA的优缺点优点切换时间短前后数据强一致性无脑裂支持多种切换方式支持GTID缺点只对Master做了高可用，slave没有依赖SSH及互信接口参数多，配置维护困难•集中化管理•国内外大公司使用及更新快•保证数据强一致性为什么选择MHA•切换时间短快速一致方便开源MHA必备条件SSH互信OS:Linuxonly单写复制限制:不支持=3层复制（0.52版本开始支持）MySQL版本:MySQL5.0+Mysqlbinlog版本=MySQL版本Binlog开启:MasterCandidateMastersGTID:0.56支持Binlog和relaylog过滤规则:所有节点相同复制用户RelayLog保留与定期purgeLOADDATA:SBR格式不要记录到Binlog检查配置主库shutdownNewMaster恢复其他Slave恢复NewMastercleanupMHA切换流程自动切换MasterManagerSlave1Slave2Slave3VIP1/RWWebServerWrite预检查MasterManagerSlave1Slave2Slave3WebServerWriteshutdown&stopvip&setread_only=1×××MasterManagerSlave2Slave3WebServerWrite3.scpDiffBinlog(本地)2.save1.NewMasterDiffrelaylog1Diffrelaylog24.生成4.生成6.Setread_only=06.VIP1/RWDiffBinlog5.Applyto7.EnablevipSlave17.Enablevip×××vipMasterManagerWebServerWrite3.scpDiffBinlog(本地)2.save1.NewMasterDiffrelaylog1Diffrelaylog2DiffBinlog5.ApplytoSlave38.并行ApplyDiffBinlog6.Setread_only=06.VIP1/RW7.EnableVIP1/RWSlave1Slave28.并行Apply4.生成4.生成+6.Setread_only=07.Enablevip10.Resetslaveinfo×××vipMasterManagerWebServerWrite3.scpDiffBinlog(本地)2.save1.NewMasterDiffrelaylog1Diffrelaylog2DiffBinlog5.ApplytoDiffBinlog9.Changetonewmaster6.VIP1/RW7.EnableVIP1/RWSlave1Slave2Slave38.并行Apply8.并行Apply4.生成4.生成+stopstartOnline切换检查配置预检查与自动切换类似Stop阶段1.在newmaster上setread_only=1.2.WaitforN*1000millseconds等当前naster的连接exit3.在当前master库上setread_only=1,阻塞写4.WaitforM*100millseconds等当前master事务和查询结束5.在当前masterstopvip6.Kill当前master@threads（除了MySQL内部和复制线程）start阶段1.Slave执行changemastertonewmaster.2.若指定orig_master_is_new_slave,主备互换.3.在newmaster上setread_only=0,打开写.4.在newmaster上startvip.切换方式自动切换：Manager节点管理多组MHAMySQL主从，每一组一份配置文件，启动一个监控进程。在线切换:主库Running时热切换。手动切换：web页面或命令行调用masterha_switch。我们做了什么Failover脑裂问题vip管理脚本控制，立即生效切换前预检查ssh链路、VIP、配置、DB等回滚方案主库机器宕机切换部署维护平台化一键初始化、配置文件自动生成及切换后自动更新GTID切换有写入非当前主库的Binlog的slave不选举为NewMaster平台化管理DB运维管理平台中运维MHAMHA页面切换目前生成库MySQL有40多组主从实例使用MHA并加入自动化运维平台管理，经过多次线上故障切换及切换演练，已经很稳定。目前面临的问题Master主机故障如何补偿差异的BinlogMySQL主从版本不一致Manger单节点多路检测并不是完美的解决方法，可以实现仲裁(哨兵)机制更好。依赖SSH需要开发Agent组件来替代SSH。接口参数过多切换“中途”失败完全回滚困难