從MySQL雙主高可用架構，談戀愛關系。

發布時間：2020-08-08 19:04:14 來源：ITPUB博客閱讀：201 作者：神諭丶欄目：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）
從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

諷刺的是，slave在作為動詞，可理解成“拼命工作”。

如果把Client當做“男/女神”，或者在戀愛關系中為“強勢”的一方。
那么讀請求可理解為“給予”或者“奉獻”。
那么寫請求理解為“回饋”。
那么Primary的叫做“正牌”，或者“主角”。
那么Standby則可以被叫做“備胎”，或者“配角”。
那么Slave（也就是S）呢？按我朋友的話來說…………好吧，真不好怎么說。
從MySQL雙主高可用架構，談戀愛關系。

VIP則是確定誰當正牌的標志，誰拿到了VIP，誰就是正牌。
這里解釋一下VIP：
VIP即Virtual IP，誰有VIP在手，誰就是Primary。

將上述專業的failover過程用簡化的言語描述一下就是：
當正牌君不行了，然后在一定時間之后，備胎君轉正成為“正牌”，繼續和男/女神保持戀愛關系。

詳細一點說，可能就是：
正牌出現了問題，比如可能是正牌病了，或者死了，當然也可能是對男/女神沒那么好了，或者最簡單理解成雙方不再愛了。
此時，時刻準備著的配角，也就是備胎君在準備了一陣子之后（VIP爭用的過程中），對client說“以后我來處理讀寫請求吧！”。
但是這個架構中，比較狗血的是，當備胎君成為正牌后，原來的正牌君還是會作為“備胎”存在于這個架構中。
或許男/女神還是會想著原來的正牌君，而老正牌君也會開始懷念男/女神。
因為哪一天新正牌君也出現了問題，老正牌君還是要繼續頂替上去的。

從MySQL雙主高可用架構，談戀愛關系。

雖然不愉快，但M1和M2還是達成了共識。

等等，那slave君呢？
最慘的當然是Slave君，上文也說過，Slave君是永遠不會被男/女神選成正牌的，在計算機世界中是這樣，在現實生活中，也有這樣的存在。（心疼一下連備胎都當不了的人）
Slave君默默的奉獻著，在背后默默做著付出，而男/女神可能一次回饋（寫請求）都不會交給Slave君。
因為Slave君連成為“備胎”的資格都沒有，在項目初始階段就被設計好了。
可能只是因為Slave君運氣不好……
也可能只是因為Slave君比起正牌君和備胎君顏值低了那么一點，或者矮了那么一點（即硬件配置稍遜）。

從MySQL雙主高可用架構，談戀愛關系。

男/女神接受著Slave君的奉獻，問Slave君，“你還會在的吧”，Slave君高興的說，“我一直在”。

從MySQL雙主高可用架構，談戀愛關系。

M1和M2君也就是正牌和備胎君也拍拍Slave君的肩膀說，“老哥，穩”

當然這只是計算機世界中。
在人與人的戀愛關系中，不可能就那么簡單，并不是簡單的“哦，你不行了，我來吧”。
但反過來，如果按【Slave-正牌-備胎】的結構理解雙主復制結構，就十分簡單了吧。

后來繼續問了這個不是做DBA的朋友，他的理解是…………千斤頂。
好像沒有毛病…………只不過在這個架構里，拿來換備胎時都用不著Slave君。
從MySQL雙主高可用架構，談戀愛關系。

為什么會寫這篇文章？

聚光燈不用往這打，我本人也沒故事可以說，也沒有什么可以開始表演的。

或許只是最近在做keepalived+雙主實驗結構時，恰巧想到的一點東西。
也或許在讀過一些故事，在看過一些人的人生之后，恰巧想到的一點東西。

從MySQL雙主高可用架構，談戀愛關系。

后來啊，公司決定把這個項目被撤掉了。
因為……Client走了，自然也不再需要三臺MySQL實例了。
也就是M1、M2、S君可能都不被需要了，數據可能都要被清空了。
這些數據都是Client給他們的。

或許在清空前，三臺機器都為自己做了一個備份……
劃了一小塊硬盤，將這些數據壓縮之后放在里面。

當然也有可能就是……三臺機器的這些數據都可能會被清空。
因為它們或許被劃到了新的項目中，開始接受信任Client的數據。

也許它們仨中，有一臺機器的所有數據都不會被清空……
只是就那樣被永遠的放入了倉庫，不再被公司使用。
雖然看起來是老了，是沒了被再次使用的價值。
但說不定，這樣也是最好的結局。

如果說，這個故事還要再出番外，或許我能想到……

或許在很久很久之后的某一天……
那臺塵封的機器，被人拭去灰層，接上電源和網線，開機。
然后將那些被壓縮的數據解壓縮，并重新導入數據庫中……

“看，當時那個項目的數據還全部都在這里。”
“我還以為再也見不到了呢。”

-- the end --

作者微信公眾號（持續更新）
從MySQL雙主高可用架構，談戀愛關系。

向AI問一下細節

91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

從MySQL雙主高可用架構，談戀愛關系。

猜你喜歡

91超碰碰碰碰久久久久久综合_超碰av人澡人澡人澡人澡人掠_国产黄大片在线观看画质优化_txt小说免费全本

從MySQL雙主高可用架構，談戀愛關系。

猜你喜歡

最新資訊

相關推薦

相關標簽