mysql高可用方案MHA介绍(二)

但是这并不作为master故障转移方案。当前master挂掉，剩余slave不一定接受全部relay log events，修复数据一致性还是问题。

这种架构使用广泛，但是不是所有人都能深刻理解上述问题。当前master挂掉，slave变得不统一或者slave不能从新的master复制数据。

也许双master，其中一个master只读，每个master都至少有一个slave也许可能解决问题。

M(RW)--M2(R)

| |

S(R) S2(R)

Pacemaker + DRBD

Pecemaker(Heartbeat)+DRBD+Mysql是一个通用方案。但是这个方案也有以下问题

1 费用问题，特别是跑大量主从环境。Pecemaker+DRBD是主动/被动的解决方案，因此需要一台被动服务器对外不提供任何应用服务。基本的需要四台mysql服务器，one active master，one passive master，two slaves。

2 宕机时间(downtime)。Pacemaker+DRBD是主备集群，主master挂掉，备用master启用。这可能花费长的时间，特别是没有用innodb plugin。即使用innodb plugin，花费几分钟开始在备用master上接受连接也不寻常。另外，因为备用master上数据/文件缓存是空的，恢复时间，热身(填充数据到data buffer pool)花费不可忽视的时间。实践中，需要一台或更多slave提供足够的读服务。在热身时间内，空缓存导致写性能降低

3 写问题下降或一致性问题。为了让主动/被动集群真正的工作，每次提交(commit)后，必须刷新事务日志(binary log和innodb log)，也就是必须设置innodb-flush-log-at-trx-commit=1,sync-binlog=1。设置sync-binlog=1会降低写性能，因为fsync()函数被序列化(sync-binlog=1，group commit失效)。大部分案例中，不设置sync-binlog=1.如果没有设置sync-binlog=1，活动master crash，新的master(先前被动服务器)可能会丢失一些已经发送到slave的binary log events。假如 master 挂掉，slave A接受到mysqld-bin.000123,位置1500。binlog data刷新到硬盘的位置在1000，那么新的master数据也只能mysqld-bin.000123的1000处，然后在启动时创建一个新的binary log mysqld-bin.000124。如果发生这种情况，slave A不能继续复制，因为新的master 没有mysqld-bin.000123位置1500.

4 复杂。对多数人来说，安装/初始化pacemake和DRBD不是容易的事情。相对于其他案例，初始化DRBD需要重新创建 系统分区也不容易。要求dba在DRBD和linux内核层有足够的技能。如果dba执行了一个错误命令（如执行drbdadm–overwrite-data-of-peer primary 在被动节点），那么将会损坏活动的数据。重要的是另外一旦硬盘io层出现问题，多数dba处理这种问题不是容易的。

MySQL Cluster

Mysql cluster是真正的高可用解决方案，但是必须得用NDB存储引擎。如果你用innodb，将不能发挥mysql cluster集群优势。

Semi-Synchronous Replication

半同步复制大大降低了binlog event仅仅存在于崩溃master上的这种风险。这非常有用的能避免数据丢失。但是半同步不能解决所有一致性问题，只能保证一个（不是所有）slave接受到master端的commit的binlog events，其他slave也许还没有接受全部的binlog events。不能apply不同的binlog events 从新的slave到 其他slave上，也不能保证相互一致性

Global Transaction ID

GlobalTransaction ID所要达到的目的跟MHA相同，但它覆盖更多。MHA只是两级复制，但是global transaction id覆盖任何级别的复制环境，即使第两级复制失败，dba也能覆盖第三级。Check Google'sglobal transaction id project for details。