从MySQL双主高可用架构，谈恋爱关系。-创新互联

这是一篇杂谈…………
前文介绍单节点写的双主结构，和failover。
后文…………就当个段子看看吧，是谈论生活的杂谈。

---

在MySQL HA方案中，有一个基于复制的简单架构，需要三台MySQL实例，正常的情况下，结构是这样的，其中红色的箭头代表写请求。
可以把它叫作“单节点写主主复制”。
注，此处为简化，Proxy的存在被略去。

简单的介绍一下这个结构：
虽说是双主，但此处的复制结构为单节点写，按Oracle Dataguard的说法：
即M1作为真正的Primary，而M2作为Standby，S作为Primary的从库。
假设M1和M2和S为姓名，那么Primary和standby就是它的职能……
而Client在此处作为三台实例存在的必要，因为有Client的业务请求，才有M1、M2和S的存在。
那么这三台实例（或者说三个数据库成员）在这样的架构中，起到什么作用呢？
M1：
作为Primary，一直在顶着client给它的各种请求，包括写，也包括读。
M2：
当M1出现故障的时候，作为Standby的M2会顶替M1，抢占VIP，此时M2的开始接收client给它的读写请求。
S：
它的作用……就比较悲惨了，它是不重要但可能又不能少的：
可能它要需要为Primary分担读请求的压力……
可能它硬件配置也不如M1或者M2……
可能它会每天被拿来做备份，承担高密集的IO压力……
可能还会被当做部分数据不一致的主要
最最最惨的是，这台slave：
永远是M1或者M2的slave……
永远是被设置上read_only=1，super_read_only=1的存在……
连给Client读写请求的账户都不需要创建。
也就是说，这台实例永远不能成为Primary。
当M1出现故障时，此时架构图就变成了：
（这个切换Primary的过程被称作failover）

当M1出现问题的时候，比如宕机，自身进程crash等等。
此时M2拿到了VIP，并宣告：“我就是Primary”，一般把这种“切换”叫做failover。
这个切换时间取决于keepalived的判断（比如是否真的不可用，是否M2有落后等）。
此时，Client会开始将读写请求发送给新的Primary也就是M2。
S则会开始复制M2的数据，继续默默工作。
当然，S则还是那个slave，继续为了Client做着“牺牲”。
而且，以后的每一次failover，都和S关系不大。

---

本着严谨，认认真真对这个HA方案做了介绍。
上面如果说是给DBA从业人员看的。
那么下面就是我想说的，也是任何人都可以看的。
先来看看上述“专业名词”在translate.google.com上的解释：
Primary（也可以叫做Master）：
adjective
 主 main, primary
 主要 main, major, primary, principal, chief

Standby（也可以叫做Secondary）：
noun
 依靠 stand-by
 支撑 bracing, brace, steady, foothold, stand-by
 支援 stand-by
adjective
 待用 stand-by, inactive
Slave（好像只能被叫做Slave）：
noun
 奴隶 slave
 奴 slave
 附件 annex, attachment, accessory, appendix, enclosure, slave
verb
 拼命工作 slave


文章题目：从MySQL双主高可用架构，谈恋爱关系。-创新互联
本文链接：http://dzwzjz.com/article/dcpdsc.html