新聞中心
這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
從MySQL雙主高可用架構(gòu),談戀愛關(guān)系。
這是一篇雜談…………
前文介紹單節(jié)點(diǎn)寫的雙主結(jié)構(gòu),和failover。
后文…………就當(dāng)個(gè)段子看看吧,是談?wù)撋畹碾s談。
在MySQL HA方案中,有一個(gè)基于復(fù)制的簡(jiǎn)單架構(gòu),需要三臺(tái)MySQL實(shí)例,正常的情況下,結(jié)構(gòu)是這樣的,其中紅色的箭頭代表寫請(qǐng)求。
可以把它叫作“單節(jié)點(diǎn)寫主主復(fù)制”。
注,此處為簡(jiǎn)化,Proxy的存在被略去。

簡(jiǎn)單的介紹一下這個(gè)結(jié)構(gòu):
雖說是雙主,但此處的復(fù)制結(jié)構(gòu)為單節(jié)點(diǎn)寫,按Oracle Dataguard的說法:
即M1作為真正的Primary,而M2作為Standby,S作為Primary的從庫。
假設(shè)M1和M2和S為姓名,那么Primary和standby就是它的職能……
而Client在此處作為三臺(tái)實(shí)例存在的必要,因?yàn)橛蠧lient的業(yè)務(wù)請(qǐng)求,才有M1、M2和S的存在。
那么這三臺(tái)實(shí)例(或者說三個(gè)數(shù)據(jù)庫成員)在這樣的架構(gòu)中,起到什么作用呢?
M1:
作為Primary,一直在頂著client給它的各種請(qǐng)求,包括寫,也包括讀。
M2:
當(dāng)M1出現(xiàn)故障的時(shí)候,作為Standby的M2會(huì)頂替M1,搶占VIP,此時(shí)M2的開始接收client給它的讀寫請(qǐng)求。
S:
它的作用……就比較悲慘了,它是不重要但可能又不能少的:
可能它要需要為Primary分擔(dān)讀請(qǐng)求的壓力……
可能它硬件配置也不如M1或者M(jìn)2……
可能它會(huì)每天被拿來做備份,承擔(dān)高密集的IO壓力……
可能還會(huì)被當(dāng)做部分?jǐn)?shù)據(jù)不一致的主要
最最最慘的是,這臺(tái)slave:
永遠(yuǎn)是M1或者M(jìn)2的slave……
永遠(yuǎn)是被設(shè)置上read_only=1,super_read_only=1的存在……
連給Client讀寫請(qǐng)求的賬戶都不需要?jiǎng)?chuàng)建。
也就是說,這臺(tái)實(shí)例永遠(yuǎn)不能成為Primary。
當(dāng)M1出現(xiàn)故障時(shí),此時(shí)架構(gòu)圖就變成了:
(這個(gè)切換Primary的過程被稱作failover)

當(dāng)M1出現(xiàn)問題的時(shí)候,比如宕機(jī),自身進(jìn)程crash等等。
此時(shí)M2拿到了VIP,并宣告:“我就是Primary”,一般把這種“切換”叫做failover。
這個(gè)切換時(shí)間取決于keepalived的判斷(比如是否真的不可用,是否M2有落后等)。
此時(shí),Client會(huì)開始將讀寫請(qǐng)求發(fā)送給新的Primary也就是M2。
S則會(huì)開始復(fù)制M2的數(shù)據(jù),繼續(xù)默默工作。
當(dāng)然,S則還是那個(gè)slave,繼續(xù)為了Client做著“犧牲”。
而且,以后的每一次failover,都和S關(guān)系不大。
本著嚴(yán)謹(jǐn),認(rèn)認(rèn)真真對(duì)這個(gè)HA方案做了介紹。
上面如果說是給DBA從業(yè)人員看的。
那么下面就是我想說的,也是任何人都可以看的。
先來看看上述“專業(yè)名詞”在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當(dāng)做“男/女神”,或者在戀愛關(guān)系中為“強(qiáng)勢(shì)”的一方。
那么讀請(qǐng)求可理解為“給予”或者“奉獻(xiàn)”。
那么寫請(qǐng)求理解為“回饋”。
那么Primary的叫做“正牌”,或者“主角”。
那么Standby則可以被叫做“備胎”,或者“配角”。
那么Slave(也就是S)呢?按我朋友的話來說…………好吧,真不好怎么說。

VIP則是確定誰當(dāng)正牌的標(biāo)志,誰拿到了VIP,誰就是正牌。
這里解釋一下VIP:
VIP即Virtual IP,誰有VIP在手,誰就是Primary。
將上述專業(yè)的failover過程用簡(jiǎn)化的言語描述一下就是:
當(dāng)正牌君不行了,然后在一定時(shí)間之后,備胎君轉(zhuǎn)正成為“正牌”,繼續(xù)和男/女神保持戀愛關(guān)系。
詳細(xì)一點(diǎn)說,可能就是:
正牌出現(xiàn)了問題,比如可能是正牌病了,或者死了,當(dāng)然也可能是對(duì)男/女神沒那么好了,或者最簡(jiǎn)單理解成雙方不再愛了。
此時(shí),時(shí)刻準(zhǔn)備著的配角,也就是備胎君在準(zhǔn)備了一陣子之后(VIP爭(zhēng)用的過程中),對(duì)client說“以后我來處理讀寫請(qǐng)求吧!”。
但是這個(gè)架構(gòu)中,比較狗血的是,當(dāng)備胎君成為正牌后,原來的正牌君還是會(huì)作為“備胎”存在于這個(gè)架構(gòu)中。
或許男/女神還是會(huì)想著原來的正牌君,而老正牌君也會(huì)開始懷念男/女神。
因?yàn)槟囊惶煨抡凭渤霈F(xiàn)了問題,老正牌君還是要繼續(xù)頂替上去的。

雖然不愉快,但M1和M2還是達(dá)成了共識(shí)。
等等,那slave君呢?
最慘的當(dāng)然是Slave君,上文也說過,Slave君是永遠(yuǎn)不會(huì)被男/女神選成正牌的,在計(jì)算機(jī)世界中是這樣,在現(xiàn)實(shí)生活中,也有這樣的存在。(心疼一下連備胎都當(dāng)不了的人)
Slave君默默的奉獻(xiàn)著,在背后默默做著付出,而男/女神可能一次回饋(寫請(qǐng)求)都不會(huì)交給Slave君。
因?yàn)镾lave君連成為“備胎”的資格都沒有,在項(xiàng)目初始階段就被設(shè)計(jì)好了。
可能只是因?yàn)镾lave君運(yùn)氣不好……
也可能只是因?yàn)镾lave君比起正牌君和備胎君顏值低了那么一點(diǎn),或者矮了那么一點(diǎn)(即硬件配置稍遜)。
.jpg)
男/女神接受著Slave君的奉獻(xiàn),問Slave君,“你還會(huì)在的吧”,Slave君高興的說,“我一直在”。

M1和M2君也就是正牌和備胎君也拍拍Slave君的肩膀說,“老哥,穩(wěn)”
當(dāng)然這只是計(jì)算機(jī)世界中。
在人與人的戀愛關(guān)系中,不可能就那么簡(jiǎn)單,并不是簡(jiǎn)單的“哦,你不行了,我來吧”。
但反過來,如果按【Slave-正牌-備胎】的結(jié)構(gòu)理解雙主復(fù)制結(jié)構(gòu),就十分簡(jiǎn)單了吧。
后來繼續(xù)問了這個(gè)不是做DBA的朋友,他的理解是…………千斤頂。
好像沒有毛病…………只不過在這個(gè)架構(gòu)里,拿來換備胎時(shí)都用不著Slave君。


為什么會(huì)寫這篇文章?
聚光燈不用往這打,我本人也沒故事可以說,也沒有什么可以開始表演的。
或許只是最近在做keepalived+雙主實(shí)驗(yàn)結(jié)構(gòu)時(shí),恰巧想到的一點(diǎn)東西。
也或許在讀過一些故事,在看過一些人的人生之后,恰巧想到的一點(diǎn)東西。

后來啊,公司決定把這個(gè)項(xiàng)目被撤掉了。
因?yàn)椤瑿lient走了,自然也不再需要三臺(tái)MySQL實(shí)例了。
也就是M1、M2、S君可能都不被需要了,數(shù)據(jù)可能都要被清空了。
這些數(shù)據(jù)都是Client給他們的。
或許在清空前,三臺(tái)機(jī)器都為自己做了一個(gè)備份……
劃了一小塊硬盤,將這些數(shù)據(jù)壓縮之后放在里面。
當(dāng)然也有可能就是……三臺(tái)機(jī)器的這些數(shù)據(jù)都可能會(huì)被清空。
因?yàn)樗鼈兓蛟S被劃到了新的項(xiàng)目中,開始接受信任Client的數(shù)據(jù)。
也許它們仨中,有一臺(tái)機(jī)器的所有數(shù)據(jù)都不會(huì)被清空……
只是就那樣被永遠(yuǎn)的放入了倉庫,不再被公司使用。
雖然看起來是老了,是沒了被再次使用的價(jià)值。
但說不定,這樣也是最好的結(jié)局。
如果說,這個(gè)故事還要再出番外,或許我能想到……
或許在很久很久之后的某一天……
那臺(tái)塵封的機(jī)器,被人拭去灰層,接上電源和網(wǎng)線,開機(jī)。
然后將那些被壓縮的數(shù)據(jù)解壓縮,并重新導(dǎo)入數(shù)據(jù)庫中……
“看,當(dāng)時(shí)那個(gè)項(xiàng)目的數(shù)據(jù)還全部都在這里。”
“我還以為再也見不到了呢。”
-- the end --
作者微信公眾號(hào)(持續(xù)更新)

標(biāo)題名稱:從MySQL雙主高可用架構(gòu),談戀愛關(guān)系。
網(wǎng)頁路徑:http://www.ef60e0e.cn/article/jsosch.html
前文介紹單節(jié)點(diǎn)寫的雙主結(jié)構(gòu),和failover。
后文…………就當(dāng)個(gè)段子看看吧,是談?wù)撋畹碾s談。
在MySQL HA方案中,有一個(gè)基于復(fù)制的簡(jiǎn)單架構(gòu),需要三臺(tái)MySQL實(shí)例,正常的情況下,結(jié)構(gòu)是這樣的,其中紅色的箭頭代表寫請(qǐng)求。
可以把它叫作“單節(jié)點(diǎn)寫主主復(fù)制”。
注,此處為簡(jiǎn)化,Proxy的存在被略去。

簡(jiǎn)單的介紹一下這個(gè)結(jié)構(gòu):
雖說是雙主,但此處的復(fù)制結(jié)構(gòu)為單節(jié)點(diǎn)寫,按Oracle Dataguard的說法:
即M1作為真正的Primary,而M2作為Standby,S作為Primary的從庫。
假設(shè)M1和M2和S為姓名,那么Primary和standby就是它的職能……
而Client在此處作為三臺(tái)實(shí)例存在的必要,因?yàn)橛蠧lient的業(yè)務(wù)請(qǐng)求,才有M1、M2和S的存在。
那么這三臺(tái)實(shí)例(或者說三個(gè)數(shù)據(jù)庫成員)在這樣的架構(gòu)中,起到什么作用呢?
M1:
作為Primary,一直在頂著client給它的各種請(qǐng)求,包括寫,也包括讀。
M2:
當(dāng)M1出現(xiàn)故障的時(shí)候,作為Standby的M2會(huì)頂替M1,搶占VIP,此時(shí)M2的開始接收client給它的讀寫請(qǐng)求。
S:
它的作用……就比較悲慘了,它是不重要但可能又不能少的:
可能它要需要為Primary分擔(dān)讀請(qǐng)求的壓力……
可能它硬件配置也不如M1或者M(jìn)2……
可能它會(huì)每天被拿來做備份,承擔(dān)高密集的IO壓力……
可能還會(huì)被當(dāng)做部分?jǐn)?shù)據(jù)不一致的主要
最最最慘的是,這臺(tái)slave:
永遠(yuǎn)是M1或者M(jìn)2的slave……
永遠(yuǎn)是被設(shè)置上read_only=1,super_read_only=1的存在……
連給Client讀寫請(qǐng)求的賬戶都不需要?jiǎng)?chuàng)建。
也就是說,這臺(tái)實(shí)例永遠(yuǎn)不能成為Primary。
當(dāng)M1出現(xiàn)故障時(shí),此時(shí)架構(gòu)圖就變成了:
(這個(gè)切換Primary的過程被稱作failover)

當(dāng)M1出現(xiàn)問題的時(shí)候,比如宕機(jī),自身進(jìn)程crash等等。
此時(shí)M2拿到了VIP,并宣告:“我就是Primary”,一般把這種“切換”叫做failover。
這個(gè)切換時(shí)間取決于keepalived的判斷(比如是否真的不可用,是否M2有落后等)。
此時(shí),Client會(huì)開始將讀寫請(qǐng)求發(fā)送給新的Primary也就是M2。
S則會(huì)開始復(fù)制M2的數(shù)據(jù),繼續(xù)默默工作。
當(dāng)然,S則還是那個(gè)slave,繼續(xù)為了Client做著“犧牲”。
而且,以后的每一次failover,都和S關(guān)系不大。
本著嚴(yán)謹(jǐn),認(rèn)認(rèn)真真對(duì)這個(gè)HA方案做了介紹。
上面如果說是給DBA從業(yè)人員看的。
那么下面就是我想說的,也是任何人都可以看的。
先來看看上述“專業(yè)名詞”在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在作為動(dòng)詞,可理解成“拼命工作”。
奴隸 slave
奴 slave
附件 annex, attachment, accessory, appendix, enclosure, slave
verb
拼命工作 slave
如果把Client當(dāng)做“男/女神”,或者在戀愛關(guān)系中為“強(qiáng)勢(shì)”的一方。
那么讀請(qǐng)求可理解為“給予”或者“奉獻(xiàn)”。
那么寫請(qǐng)求理解為“回饋”。
那么Primary的叫做“正牌”,或者“主角”。
那么Standby則可以被叫做“備胎”,或者“配角”。
那么Slave(也就是S)呢?按我朋友的話來說…………好吧,真不好怎么說。

VIP則是確定誰當(dāng)正牌的標(biāo)志,誰拿到了VIP,誰就是正牌。
這里解釋一下VIP:
VIP即Virtual IP,誰有VIP在手,誰就是Primary。
將上述專業(yè)的failover過程用簡(jiǎn)化的言語描述一下就是:
當(dāng)正牌君不行了,然后在一定時(shí)間之后,備胎君轉(zhuǎn)正成為“正牌”,繼續(xù)和男/女神保持戀愛關(guān)系。
詳細(xì)一點(diǎn)說,可能就是:
正牌出現(xiàn)了問題,比如可能是正牌病了,或者死了,當(dāng)然也可能是對(duì)男/女神沒那么好了,或者最簡(jiǎn)單理解成雙方不再愛了。
此時(shí),時(shí)刻準(zhǔn)備著的配角,也就是備胎君在準(zhǔn)備了一陣子之后(VIP爭(zhēng)用的過程中),對(duì)client說“以后我來處理讀寫請(qǐng)求吧!”。
但是這個(gè)架構(gòu)中,比較狗血的是,當(dāng)備胎君成為正牌后,原來的正牌君還是會(huì)作為“備胎”存在于這個(gè)架構(gòu)中。
或許男/女神還是會(huì)想著原來的正牌君,而老正牌君也會(huì)開始懷念男/女神。
因?yàn)槟囊惶煨抡凭渤霈F(xiàn)了問題,老正牌君還是要繼續(xù)頂替上去的。

雖然不愉快,但M1和M2還是達(dá)成了共識(shí)。
等等,那slave君呢?
最慘的當(dāng)然是Slave君,上文也說過,Slave君是永遠(yuǎn)不會(huì)被男/女神選成正牌的,在計(jì)算機(jī)世界中是這樣,在現(xiàn)實(shí)生活中,也有這樣的存在。(心疼一下連備胎都當(dāng)不了的人)
Slave君默默的奉獻(xiàn)著,在背后默默做著付出,而男/女神可能一次回饋(寫請(qǐng)求)都不會(huì)交給Slave君。
因?yàn)镾lave君連成為“備胎”的資格都沒有,在項(xiàng)目初始階段就被設(shè)計(jì)好了。
可能只是因?yàn)镾lave君運(yùn)氣不好……
也可能只是因?yàn)镾lave君比起正牌君和備胎君顏值低了那么一點(diǎn),或者矮了那么一點(diǎn)(即硬件配置稍遜)。
.jpg)
男/女神接受著Slave君的奉獻(xiàn),問Slave君,“你還會(huì)在的吧”,Slave君高興的說,“我一直在”。

M1和M2君也就是正牌和備胎君也拍拍Slave君的肩膀說,“老哥,穩(wěn)”
當(dāng)然這只是計(jì)算機(jī)世界中。
在人與人的戀愛關(guān)系中,不可能就那么簡(jiǎn)單,并不是簡(jiǎn)單的“哦,你不行了,我來吧”。
但反過來,如果按【Slave-正牌-備胎】的結(jié)構(gòu)理解雙主復(fù)制結(jié)構(gòu),就十分簡(jiǎn)單了吧。
后來繼續(xù)問了這個(gè)不是做DBA的朋友,他的理解是…………千斤頂。
好像沒有毛病…………只不過在這個(gè)架構(gòu)里,拿來換備胎時(shí)都用不著Slave君。


為什么會(huì)寫這篇文章?
聚光燈不用往這打,我本人也沒故事可以說,也沒有什么可以開始表演的。
或許只是最近在做keepalived+雙主實(shí)驗(yàn)結(jié)構(gòu)時(shí),恰巧想到的一點(diǎn)東西。
也或許在讀過一些故事,在看過一些人的人生之后,恰巧想到的一點(diǎn)東西。

后來啊,公司決定把這個(gè)項(xiàng)目被撤掉了。
因?yàn)椤瑿lient走了,自然也不再需要三臺(tái)MySQL實(shí)例了。
也就是M1、M2、S君可能都不被需要了,數(shù)據(jù)可能都要被清空了。
這些數(shù)據(jù)都是Client給他們的。
或許在清空前,三臺(tái)機(jī)器都為自己做了一個(gè)備份……
劃了一小塊硬盤,將這些數(shù)據(jù)壓縮之后放在里面。
當(dāng)然也有可能就是……三臺(tái)機(jī)器的這些數(shù)據(jù)都可能會(huì)被清空。
因?yàn)樗鼈兓蛟S被劃到了新的項(xiàng)目中,開始接受信任Client的數(shù)據(jù)。
也許它們仨中,有一臺(tái)機(jī)器的所有數(shù)據(jù)都不會(huì)被清空……
只是就那樣被永遠(yuǎn)的放入了倉庫,不再被公司使用。
雖然看起來是老了,是沒了被再次使用的價(jià)值。
但說不定,這樣也是最好的結(jié)局。
如果說,這個(gè)故事還要再出番外,或許我能想到……
或許在很久很久之后的某一天……
那臺(tái)塵封的機(jī)器,被人拭去灰層,接上電源和網(wǎng)線,開機(jī)。
然后將那些被壓縮的數(shù)據(jù)解壓縮,并重新導(dǎo)入數(shù)據(jù)庫中……
“看,當(dāng)時(shí)那個(gè)項(xiàng)目的數(shù)據(jù)還全部都在這里。”
“我還以為再也見不到了呢。”
-- the end --
作者微信公眾號(hào)(持續(xù)更新)

標(biāo)題名稱:從MySQL雙主高可用架構(gòu),談戀愛關(guān)系。
網(wǎng)頁路徑:http://www.ef60e0e.cn/article/jsosch.html