企业网站 html模板下载,如何自己申请商标注册,wordpress添加关键词后在哪能看到,注册新公司的流程MySQL MHA介绍 MHA简介 MHA是一位日本MySQL大牛用Perl写一套MySQL故障切换方案#xff0c;来保证数据库系统的高可用#xff0c;在宕机的事件内#xff08;通常10-30秒#xff09;#xff0c;完成故障转意#xff0c;部署MHA#xff0c;可避免主从一致性问题#xff0c… MySQL MHA介绍 MHA简介 MHA是一位日本MySQL大牛用Perl写一套MySQL故障切换方案来保证数据库系统的高可用在宕机的事件内通常10-30秒完成故障转意部署MHA可避免主从一致性问题节约购买新服务器的费用不影响服务器性能易安装不改变现有部署 MHA在生产环境的作用 一主多从的环境下MySQL的主从复制是异步或是半同步。 Master发生故障的时候有可能一部分或者全部的Slave未能获取到最新的binlog造成Slave之间的binlog转发发生偏差。 如下图所示Master宕机之后id102的binlog未能被发送到任何一个Slave上id101的binlog只有save2上有slave3上未能收到id100和id-101的binlog 如果想要正确恢复 Master必须发出的ID102的binlog还要消除各个Slave之间的差异性 MHA可以全自动的处理以上这些 MHA架构 可实现master工作状态的监控以及宕机时的故障转移 要求MySQL版本要在5.0以上 MHA原理 1、等待SQL线程执行完毕2、解析最新的Slave上的中继日志relay log的日志头log Header为其他各个服务器确定出差异位置3、将i1–i2–X 全部组成一个二进制日志MHA的主要特性 从master的监控到故障转移全部都能自动完成故障转移也可手动执行可在秒级单位内实现故障转移可将任意Slave提升至master具备在多个点上调用外部脚本扩展的技能可以用在电源OFF或者IP地址的故障转移上。安装和卸载不用停止当前的mysql进程MHA 自身不会增加服务器负担不会降低性能不用追加服务器不依赖Storage Engine不依赖二进制文件的格式不论是statement模式还是Row模式 拓展性 seconary_check_script 调用该脚本从多个网络路径判断MASTER是否宕机 MASTER连接错误时会被调用 MHA标配的脚本masterhaseconarycheck方便 shutdown_script 电源强制OFF等 故障转移前的瞬间被调用 SSH可以链接到的情况下mysqldmysqld_safe强制killssh连不到的情况下关闭电源 master_ip_failover_script MASTER的IP地址更新新建和应用程序连接所需要的用户 故障转移前的瞬间和转移到新MASTER(差异反映结束后)被调用 根据用途的不同来写脚本可以实现不需要更改应用程序端就可以连接到新的MASTER MASTER IP使用虚拟IP的场合 将VIP让给新的MASTER5. 用catalog database等来管理MASTER的IP地址的场合 更新该catalog database 中的信息report_script 发邮件通知故障转移成功或失败等的详细情况 故障转移结束后被调用 案例分析 在DeNA的服务中主要是社交游戏针对有超过150组对MASTER/SLAVE的服务器引入MHAMySQL一般不会出现服务宕机通常是由OS和H/W故障引起拓展 检测MASTER是否宕机 除了Manager会对MASTER进行监控外另外还通过其他两处的远程数据中心来检测是否可以连接到MASTER强制宕机MASTER ssh可以连接到的情况下用kill -9 mysqld mysqld_safessh连接不到的情况下ipmitool等工具强制关闭电源。针对OS挂掉的故障转移检测系统是否挂掉需要10秒故障转移仅需4秒 MASTER的生死判定 3*4-3 9秒-12秒判定是否可以进行故障转移
默认情况只有其他所有的SLAVE都存货的情况下才进行故障转移检测SLAVE判断其工作状态不到1秒故障转移处理 强制将显著的MASTER关机SSH可以连接到的情况下将有差异的二进制日志保存下来确定新MASTER将重新MASTER的IP地址有效化重开其他的SLAVE从新的MASTER之间的主从复制 准备工作 一个可以写的MASTER和多个SLAVE或只读MASTER
当MASTER崩溃时MHA会修复SLAVE之间的一致性问题。另外MHA会尝试从崩溃的MASTER保存未能发送的二进制日志并应用到所有Slave。如果仅有一台SLAVE服务器就不需要担心SLAVE之间的一致性问题。但是即使只有一台SLAVE服务器在SSH可以连通的情况下MHA在MASTER崩溃时抢救日志上也会非常有帮助当然通过半同步也可以解决这个问题。从MHA Manager 0.52 开始支持多个MASTER(multi master)的复制。下面是MHA在多MASTER复制时注意的事项只允许有一个MASTER可写。在其他MASTER上必须设置MySQL全局变量”read-only1″缺省情况下所有被管理的服务器在配置文件中定义的服务器应该是2层级联复制。 在0.52版本以前MHA仅在所有SLAVE都从同一个MASTER上进行复制才能进行检测监控和故障转移操作。也就是说MHA不支持多主的配置形式。一般情况下只要MHA可以管控自动故障转移使用多MASTER配置的意义会很有限比如在线模式更改。如果只是尝试使用多MASTER配置比如仅仅为了在线模式更改仅需在操作期间停止MHA并配置多主设置。当操作结束后重新改为单主多从的配置并重启MHA。管理3层或更多曾的及联复制环境
MHA默认不支持三次或更多曾的级联复制架构比如Master-Master2-Slave3。MHA仅在SLAVE直接从当前主要MASTER进行复制时才会进行故障转移和恢复操作。MHA可以管理MASTER1和MASTER2并且当MASTER1崩溃提升MASTER为主MASTER但是MHA不能监控和恢复SLAVE3因为SLAVE3从不同的MASTER(MASTER2)上进行主从复制。为了让MHA在这种架构下能进行工作需要以下设置在MHA的配置文件中设置MASTER和二层级联中的主机MASTER1和MASTER2使用multi_tier_slave1 参数并在MHA配置文件中设置所有主机。 不管在那种情况中MHA都只管理主MASTER和第二层的级联SLAVE即使MASTER崩溃MASTER2会成为主要MASTER,从MASTER进行复制的SLAVE依然可以运行 MySQL5.0或更高的版本
MHA支持MySQL5.0或更高的版本。MHA不支持MySQL4.1因为MySQL5.0开始二进制日志的格式发生了改变binlog v4 MHA分析二进制日志并确定位置点时止支持v4版本所以MySQL4.1 在这里不能工作。MySQL5.0或更高版本中的mysqlbinlog同样也需要v4版本的binlog格式。在早起的MySQL版本中主从复制处理存在一些非常严重的问题所以高度推荐使用高版本的MySQL.特别是如果你还在使用MYSQL 5.06.0 以前的版本请考虑升级在候选MASTER 上必须开启log-bin
如果当前SLAVE未设置log-bin很明显他们都不能成为MASTERMHA Manager内部将会检查log-bin的设置不会将未开启binlog的Slave提升为MASTER、如果当前的Slave都没有设置log-binMHA将会不尽兴故障转移在所有服务器上二进制日志和中继日志过滤规则必须一致
所有服务器上的主从复制过滤规则binlog-do-dbreplicate-ignore-db等MHA在启动时检查过滤规则如果发现各服务器之间的配置不一致将不会进行监控或故障转移在被选MASTER上必须存在具有复制权限的用户
当故障转移完成后所有Slave将执行CHANGE MASTER TO 语句。必须存在一个具有复制权限的用户才能进行复制
