从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）：
如果把Client当做“男/女神”，或者在恋爱关系中为“强势”的一方。
那么读请求可理解为“给予”或者“奉献”。
那么写请求理解为“回馈”。
那么Primary的叫做“正牌”，或者“主角”。
那么Standby则可以被叫做“备胎”，或者“配角”。
那么Slave（也就是S）呢？按我朋友的话来说…………好吧，真不好怎么说。
VIP则是确定谁当正牌的标志，谁拿到了VIP，谁就是正牌。
这里解释一下VIP：
VIP即Virtual IP，谁有VIP在手，谁就是Primary。
将上述专业的failover过程用简化的言语描述一下就是：
当正牌君不行了，然后在一定时间之后，备胎君转正成为“正牌”，继续和男/女神保持恋爱关系。
详细一点说，可能就是：
正牌出现了问题，比如可能是正牌病了，或者死了，当然也可能是对男/女神没那么好了，或者最简单理解成双方不再爱了。
此时，时刻准备着的配角，也就是备胎君在准备了一阵子之后（VIP争用的过程中），对client说“以后我来处理读写请求吧！”。
但是这个架构中，比较狗血的是，当备胎君成为正牌后，原来的正牌君还是会作为“备胎”存在于这个架构中。
或许男/女神还是会想着原来的正牌君，而老正牌君也会开始怀念男/女神。
因为哪一天新正牌君也出现了问题，老正牌君还是要继续顶替上去的。
虽然不愉快，但M1和M2还是达成了共识。
等等，那slave君呢？
最惨的当然是Slave君，上文也说过，Slave君是永远不会被男/女神选成正牌的，在计算机世界中是这样，在现实生活中，也有这样的存在。（心疼一下连备胎都当不了的人）
Slave君默默的奉献着，在背后默默做着付出，而男/女神可能一次回馈（写请求）都不会交给Slave君。
因为Slave君连成为“备胎”的资格都没有，在项目初始阶段就被设计好了。
可能只是因为Slave君运气不好……
也可能只是因为Slave君比起正牌君和备胎君颜值低了那么一点，或者矮了那么一点（即硬件配置稍逊）。
.jpg)
男/女神接受着Slave君的奉献，问Slave君，“你还会在的吧”，Slave君高兴的说，“我一直在”。
M1和M2君也就是正牌和备胎君也拍拍Slave君的肩膀说，“老哥，稳”
当然这只是计算机世界中。
在人与人的恋爱关系中，不可能就那么简单，并不是简单的“哦，你不行了，我来吧”。
但反过来，如果按【Slave-正牌-备胎】的结构理解双主复制结构，就十分简单了吧。
后来继续问了这个不是做DBA的朋友，他的理解是…………千斤顶。
好像没有毛病…………只不过在这个架构里，拿来换备胎时都用不着Slave君。
为什么会写这篇文章？
聚光灯不用往这打，我本人也没故事可以说，也没有什么可以开始表演的。
或许只是最近在做keepalived+双主实验结构时，恰巧想到的一点东西。
也或许在读过一些故事，在看过一些人的人生之后，恰巧想到的一点东西。
后来啊，公司决定把这个项目被撤掉了。
因为……Client走了，自然也不再需要三台MySQL实例了。
也就是M1、M2、S君可能都不被需要了，数据可能都要被清空了。
这些数据都是Client给他们的。
或许在清空前，三台机器都为自己做了一个备份……
划了一小块硬盘，将这些数据压缩之后放在里面。
当然也有可能就是……三台机器的这些数据都可能会被清空。
因为它们或许被划到了新的项目中，开始接受信任Client的数据。
也许它们仨中，有一台机器的所有数据都不会被清空……
只是就那样被永远的放入了仓库，不再被公司使用。
虽然看起来是老了，是没了被再次使用的价值。
但说不定，这样也是最好的结局。
如果说，这个故事还要再出番外，或许我能想到……
或许在很久很久之后的某一天……
那台尘封的机器，被人拭去灰层，接上电源和网线，开机。
然后将那些被压缩的数据解压缩，并重新导入数据库中……
“看，当时那个项目的数据还全部都在这里。”
“我还以为再也见不到了呢。”
-- the end --
作者微信公众号（持续更新）
网站题目：从MySQL双主高可用架构，谈恋爱关系。
URL链接：http://azwzsj.com/article/jsosch.html
前文介绍单节点写的双主结构，和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
讽刺的是，slave在作为动词，可理解成“拼命工作”。
奴隶 slave
奴 slave
附件 annex, attachment, accessory, appendix, enclosure, slave
verb
拼命工作 slave
如果把Client当做“男/女神”，或者在恋爱关系中为“强势”的一方。
那么读请求可理解为“给予”或者“奉献”。
那么写请求理解为“回馈”。
那么Primary的叫做“正牌”，或者“主角”。
那么Standby则可以被叫做“备胎”，或者“配角”。
那么Slave（也就是S）呢？按我朋友的话来说…………好吧，真不好怎么说。
VIP则是确定谁当正牌的标志，谁拿到了VIP，谁就是正牌。
这里解释一下VIP：
VIP即Virtual IP，谁有VIP在手，谁就是Primary。
将上述专业的failover过程用简化的言语描述一下就是：
当正牌君不行了，然后在一定时间之后，备胎君转正成为“正牌”，继续和男/女神保持恋爱关系。
详细一点说，可能就是：
正牌出现了问题，比如可能是正牌病了，或者死了，当然也可能是对男/女神没那么好了，或者最简单理解成双方不再爱了。
此时，时刻准备着的配角，也就是备胎君在准备了一阵子之后（VIP争用的过程中），对client说“以后我来处理读写请求吧！”。
但是这个架构中，比较狗血的是，当备胎君成为正牌后，原来的正牌君还是会作为“备胎”存在于这个架构中。
或许男/女神还是会想着原来的正牌君，而老正牌君也会开始怀念男/女神。
因为哪一天新正牌君也出现了问题，老正牌君还是要继续顶替上去的。
虽然不愉快，但M1和M2还是达成了共识。
等等，那slave君呢？
最惨的当然是Slave君，上文也说过，Slave君是永远不会被男/女神选成正牌的，在计算机世界中是这样，在现实生活中，也有这样的存在。（心疼一下连备胎都当不了的人）
Slave君默默的奉献着，在背后默默做着付出，而男/女神可能一次回馈（写请求）都不会交给Slave君。
因为Slave君连成为“备胎”的资格都没有，在项目初始阶段就被设计好了。
可能只是因为Slave君运气不好……
也可能只是因为Slave君比起正牌君和备胎君颜值低了那么一点，或者矮了那么一点（即硬件配置稍逊）。
男/女神接受着Slave君的奉献，问Slave君，“你还会在的吧”，Slave君高兴的说，“我一直在”。
M1和M2君也就是正牌和备胎君也拍拍Slave君的肩膀说，“老哥，稳”
当然这只是计算机世界中。
在人与人的恋爱关系中，不可能就那么简单，并不是简单的“哦，你不行了，我来吧”。
但反过来，如果按【Slave-正牌-备胎】的结构理解双主复制结构，就十分简单了吧。
后来继续问了这个不是做DBA的朋友，他的理解是…………千斤顶。
好像没有毛病…………只不过在这个架构里，拿来换备胎时都用不着Slave君。
为什么会写这篇文章？
聚光灯不用往这打，我本人也没故事可以说，也没有什么可以开始表演的。
或许只是最近在做keepalived+双主实验结构时，恰巧想到的一点东西。
也或许在读过一些故事，在看过一些人的人生之后，恰巧想到的一点东西。
后来啊，公司决定把这个项目被撤掉了。
因为……Client走了，自然也不再需要三台MySQL实例了。
也就是M1、M2、S君可能都不被需要了，数据可能都要被清空了。
这些数据都是Client给他们的。
或许在清空前，三台机器都为自己做了一个备份……
划了一小块硬盘，将这些数据压缩之后放在里面。
当然也有可能就是……三台机器的这些数据都可能会被清空。
因为它们或许被划到了新的项目中，开始接受信任Client的数据。
也许它们仨中，有一台机器的所有数据都不会被清空……
只是就那样被永远的放入了仓库，不再被公司使用。
虽然看起来是老了，是没了被再次使用的价值。
但说不定，这样也是最好的结局。
如果说，这个故事还要再出番外，或许我能想到……
或许在很久很久之后的某一天……
那台尘封的机器，被人拭去灰层，接上电源和网线，开机。
然后将那些被压缩的数据解压缩，并重新导入数据库中……
“看，当时那个项目的数据还全部都在这里。”
“我还以为再也见不到了呢。”
-- the end --
作者微信公众号（持续更新）
网站题目：从MySQL双主高可用架构，谈恋爱关系。
URL链接：http://azwzsj.com/article/jsosch.html
