《mysql的mha》.docxVIP

Mysql高可用概述 自动对master进行监控，失效切换 交互式对master进行切换（master已经失效） 非交互对master失败切换（master已经失效） 在线对master进行切换（master还活着） 失效切换例1 所有的slave都获取了master上必威体育精装版的binlog日志，所有的slave均可作为新的master。这可以说是最理想的失效切换了。 但事实上有些时候失效切换其实并不简单。因为会引起数据不一致。在一主多从的情况下，当master崩溃的时候，slave上有可能收集的binlog不全，有可能各个slave上binlog的缺少程度也不一样。那么如果选举出一台slave做master之后，剩下的slave去连新的master，会出现数据不一致的情况。 失效切换例2 所有slave获取的binlog是相同的。但是都不全，master的mysql服务在宕掉的时候，slave都没有获取到id=102这一条日志，如果这时候直接失效切换的话，那么id=102这条日志涉及的数据就会丢失，因为这是在master上执行成功的。如果想要数据完整的话，需要登录master这台服务器，但是前提是master这台服务器只是服务挂了，而不是服务器，然后把id=102这条记录取过来应用到所有slave上，然后再进行失效切换。 失效切换例3 一些slave的binlog是全的，一些不全，而且不全的程度也不一样。对于这个例子来说slave2的抓取的binlog是全的，所以要通过slave2来补全其他slave，然后再进行失效切换。 失效切换4 这种情况最为复杂，包含了上面几个例子的问题。 这需要先从master把id=102拷贝到slave2，然后再用slave2将其他slave的log补齐，这样才可以达到不丢数据，并且一致。 目前已有mysql的ha方案 简单的一主一从结构，主负责读写，从负责读，当主挂了让应用把所有读写请求都发到从上。 一个主和一个备用主，再接N个slave，当主宕机之后切到备用主。这样有可能会出现多台slave不一致的情况 双master方式。这种方式当master宕了之后，备用主以及备用主下的从库不会受到影响，但是这种结构负责度较高，因为是a-b-c这种架构，所以当备用主当机时，后面的从要恢复同步是比较麻烦的。 Heartbeat+DRBD+MySQL：也存在一些问题：写性能有损失；备用主是不能启动的，不能作用来读，所以比较浪费资源；由于是网络raid，所以主上当机之后表损坏了，那么备份主启动之后还得执行修表操作，即便是innodb，启动后还得进行redo和undo；另外由于备用主的进行是关闭的，还有一个预热的问题，切换之后内存里没有任何数据瞬时的访问可能会承受不了。 MySQL Cluster：用于使用人比较少，不够稳定，所以暂时不敢用。 半同步：半同步其实是把在主从同步中丢日志的情况降至最低的一种功能，防止数据丢失。其实半同步不算一种高可用方案，但是和mha配合起来应该比较完美，半同步来保证主从同步数据不丢失，mha保证切换时所有从库都是一致的。 全局事务ID：为了解决a-b-c这种同步方式当b宕机的时候，c找不到a上pos的问题。 Mha体系结构 当master宕机后，mha恢复剩余的slave操作如下： 在不同的slave上需要执行如上图的操作。 先要等这些slave执行完剩下的relay log的所有events 然后执行i1，i1指的是一个不完整的事务，因为master宕机的原因完成的事务日志没有传过来。 然后执行i2，i2是日志最全的那个slave和其他slave上relay log的诧异（当这个slave就是日志全的那个slave时，这一步忽略） 执行X，X就是当master服务宕时，所有slave都没有获取到的那部分binlog，但是如果master的服务器都宕机的则无法获取到这部分数据。 Mha的组成部分 Mha插件安装文件一共有两个包儿，一个是manager，一个是node 例如：mha4mysql-node-0.52.tar.gz?和mha4mysql-manager-0.52.tar.gz Mha的manager主要是负责监控master的，控制master的故障转移。 Mha的node需要部署在所有mysql上，包含有故障转移和解析binlog和relay log的脚本 当mha的manager执行故障转移的时候，manager会去连接node通过ssh去执行一些命令。 Mha还可以允许你用自定义脚本去更新master的ip或者更新虚拟ip，因为怎么修改master的ip取决于用户的情况，所以mha不会强制用户来用哪一种方法。 Mha manager包含的一些脚本： seconda