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

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


在MySQL HA方案中,有一个基于复制的简单架构,需要三台MySQL实例,正常的情况下,结构是这样的,其中红色的箭头代表写请求。
可以把它叫作“单节点写主主复制”。
注,此处为简化,Proxy的存在被略去。
从MySQL双主高可用架构,谈恋爱关系。
简单的介绍一下这个结构:
虽说是双主,但此处的复制结构为单节点写,按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)
从MySQL双主高可用架构,谈恋爱关系。
当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://lszwz.com/article/dcpdsc.html

其他资讯

售后响应及时

7×24小时客服热线

数据备份

更安全、更高效、更稳定

价格公道精准

项目经理精准报价不弄虚作假

合作无风险

重合同讲信誉,无效全额退款