参考：https://code.google.com/p/mysql-master-ha/wiki/Other_HA_Solutions#Other_Solutions_and_Issues

mysql master HA各种解决方案：

手动解决

mysql复制是异步或者半同步的。当master崩溃时，一些slave很有可能尚未接收到最新的relay log事件，这就可能导致slave之间可能处于不同的状态。手动解决一致性问题并不繁杂，但若不解决一致性问题，主从复制将无法启动。手动重启主从复制往往需要花费一小时的时间。

只有一个master并只挂一个slave

只有一个master和一个slave时，不会发生一些slave过时于某一slave的情况。当master崩溃时，只要使应用将所有流量发送到slave转成的新master上即可。故障切换很简单。

M(RW)
|                          –(master crash)–>             M(RW), promoted from S
S(R)

主(读写)
|                          –(master崩溃)–>               新主(读写), 由从机生格而来
从(读)

但是本节方案有严重的问题。

首先，无法水平扩展读流量。当在一个slave运行诸如备份、分析查询、脚本任务等重量级操作时可能带来性能问题。当这个唯一的slave宕机时，master需要处理slave的所有流量。

其次是可用性，当master宕机时，只剩新主机成为单一故障点。创建新slave需要作在线备份，将数据转储到新硬件并立即开启slave。这些操作通常需要花费几个小时的时间。一些关键应用不允许数据库成为单一故障点并持续几个小时的时间。在线备份数据库会造成额外的i/o负担，所以在使用高峰时期备份也是危险的。

第三个问题是缺乏扩展性。例如，如果想要在远程数据中心建立一个只读数据库，需要至少两个slave，一个位于本地数据中心，另一个slave位于远程数据中心。只有一个slave无法建立前述架构。

单一slave在许多场景中都无法满足要求。

 一个master一个候选master及多个slave

使用标题所述架构非常常见。在当前master宕机时，候选master具有较高优先级成为新的master。有些情况下候选master配置成只读master：譬如多master的配置。

 

M(RW)—–M2(R)                                            M(RW), promoted from M2
|                                                                           |
+—-+—-+                –(master crash)–>                  +-x–+–x-+
S(R) S2(R)                                                           S(?)      S(?)
(From which position should S restart replication?)

 

M(读写)—–M2(只读)                                            M(读写), 由 M2 升格成为新master
|                                                                           |
+—-+—-+                –(master 宕机)–>                   +-x–+–x-+
S(只读) S2(只读)                                                   S(?)      S(?)
(slave应该从哪一点开始复制？)

但是前述方案作为master的灾备方案不总是可行的。当master宕机时，其余salve可能没有接收到全部的relay log时间，因此还是需要解决salve之间的一致性问题。

既不能接受一致性问题，又想立即恢复服务怎么办：将候选master升格为新master，丢弃全部slave。然后通过在线备份新master建立新的slave。这种方案与上一节“单主单从”的问题一样，剩余的slave不能用于扩展读流量，也不能用于冗余。在恢复slave规模之前，将会产生故障单点问题。

这种架构使用非常广泛，但只有少数人能够全面了解前述的潜在问题：当master宕机时，其挂载的slave变得不一致；试图直接将slave挂到新master上开启复制也会失败。如果想要保证一致性，必须舍弃全部原有的slave。

还有一种架构：两个master，一个只读。每个master都至少挂一个slave。

M(RW)–M2(R)
|           |
S(R)    S2(R)

M(读写)  —  M2(只读)
|                |
S(只读)      S2(只读)

当当前master宕机时，至少有一个slave可以继续复制。但是这种方案使用不多，它最大的缺点是太复杂。三层复制（主主从，M->M2->S2）采用了这种架构，但是管理三层复制比较复杂。例如，如果中层的服务器（M2）宕机，第三层的slave（S2）无法继续复制。在许多情况下，需要重新配置M2和S2，因此这种架构至少需要4台机器（一台空白机用于出现问题时顶上）。

（待续）