這是一篇雜談…………
前文介紹單節點寫的雙主結構，和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在作為動詞，可理解成“拼命工作”。

如果把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雙主高可用架構，談戀愛關係。

相關文章