【翻译】mysql master HA other solutions

参考: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台机器(一台空白机用于出现问题时顶上)。

(待续)

 

Leave a Comment

电子邮件地址不会被公开。 必填项已用*标注