MySQL複製（三） --- 高可用性和複製

實現高可用性的原則很簡單：

1. 冗餘(Redundancy)：若是一個組件出現故障，必須有一個備用組件。這個備用組件能夠是standing by的，也能夠是當前系統部署中的一部分。
2. 應急計劃(Contigency plans)：若是一個組件出現故障，你必須知道作什麼。這依賴於哪一個組件出現故障以及如何發生故障。
3. 程序(Procedure)：若是一個組件出現故障，你可以及時發現並迅速有效的執行你的計劃。

冗餘(Redundancy)

只要有單點故障(SPOF:Single Point of Failure)的存在，就沒法保證系統的高可用性（關於單點故障能夠參考Fenng的這篇文章，比較通俗易懂）。

爲了搞清楚哪裏須要冗餘機制，咱們須要找到部署中全部潛在的單點。雖說起來簡單，可是須要一點想象力，以確保真正找到所有單點。交換機，路由器，網卡甚至電纜都是單點，除了這些，電源和物理設施也很重要。還有一些也爲成爲單點，好比只有一個員工知道如何處理某種類型的故障，全部的網絡都被集中到一個web頁面進行管理等。但定位到全部的單點並不意味着你必需要所有消除它們，由於有些單點或許由於經濟上，技術上或者地理上的緣由而沒法徹底消除，但知道這些單點的存在將有助於出錯時排錯。

在考慮要不要消除某個單點，有些因素須要考慮：複製組件的成本，不一樣組件發生故障的機率，替換組件的時機以及修復組件時的擔當的風險。好比你替換一個組件須要一週時間，在這一週期間，運行中的備用組件也有可能出現故障，這些你都必需要考慮到。

一旦肯定要消除的單點，接下來就須要考慮如何創建冗餘機制，有兩種方案可供選擇：1）爲每個組件創建一個備用組件，若是原始組件發生故障，當即啓用備用組件；2）系統自己有額外的容量，當一個組件出現故障時仍能hold住。第一種方案，雖然看起來簡單，可是成本高。你必須讓備用組件處於standby狀態，一直和主組件保持一致。其優勢就是在切換組件的時候不會損失性能，並且切換到standby組件所花的時間一般要比從新構建組件快。方案二爲系統構建額外容量的方案可讓你使用全部組件(資源)來運行系統，這樣系統能夠處理更高的瞬間峯值負載。但有一點必須明白，這種方案時，系統必須擁有額外的容量以保證在某些組件出現故障時系統仍然能hold住。有時候只爲一個服務器發生故障留有餘地還不夠，這個時候你須要權衡，以及這種狀況出現的機率是多少。好比安裝了100臺服務器，其中一臺服務器發生故障的機率是1%，那麼1臺，2臺，3臺服務器發生故障的機率會是多少呢？根據二項式定理計算可獲得依次爲100%，20.33%，16.17%。

 

應急計劃(Contigency plans)

只作冗餘仍是不夠，當你一個組件發生故障時，你還須要知道如何去應對。在以前的例子裏，當Slave服務器出現故障時很容易去處理，由於只需把新的鏈接所有重定向到能工做的Slave服務器，同時你須要考慮：1）現有的鏈接怎麼處理？僅僅停止程序並給用戶返回一個出錯信息明顯不是一個好主意。一般狀況下，在用戶和數據庫之間有一個應用層，這個時候應該讓應用層向別的服務器提交查詢；2）若是Master發生故障怎麼處理？假設你已經提供了一個額外的Master作冗餘，你還必須提供機制讓全部Slave重定向新的Master。

下面介紹一下如何處理各類拓撲結構下MySQL服務器宕機的技術。通常來講，須要考慮三種角色：Master，Slave，Relay。

• Slave故障：這是最簡單處理的故障。由於Slave僅僅是用於讀查詢，只需通知負載均衡器該Slave出故障，而後負載均衡器就會把新的請求都重定向到工做中的其餘Slave。這就須要剩下的Slave可以處理這些額外的負載。除了這以外，發生故障的Slave通常來講不會影響複製機制的拓撲結構，也就不用去考慮特殊的拓撲結構以保證在Slave發生故障時易於管理。當Slave發生故障時，對於已經提交給該Slave並等待響應的查詢，須要從新向工做的其餘Slave提交查詢請求。
• Master故障：若是Master發生故障，就必須用備用的Master替換以保證部署的系統能正常運行，而且要快。當Master發生故障時，全部的寫請求當即終止，所以首先要作的就是啓用新Master並把全部的寫請求重定位過去。由於主Master發生故障了，全部的Slave都失去了Master鏈接。這就意味着Slave上數據已不是最新的，雖然還可以繼續響應讀請求。儘管如此，若是有些請求須要監聽到達Slave的變化，這些請求可能會被阻止，而有些請求或許把本身寫進Slave中繼日誌，並最終由Slave執行，這類請求就無需考慮。Master發生故障時，對於那些正在Master上等待某個事件的請求來講狀況更加糟糕。對於這種狀況，須要進行處理，通常來講就是用戶被通知請求失敗，而後須要從新發送請求。
• Relay故障：Relay服務器發生故障時須要進行一些特殊處理。若是Relay服務器發生故障，其餘的Slave必須被重定向到其餘的Relay服務器或者直接定向到Master。由於Relay服務器是用於緩解Master的負載，那麼有可能出現Master沒法處理Relay上的負載。
• 災難恢復：在高可用性的世界裏，災難並不意味着地震或者洪水，它只是表示服務器發生了極壞的情況，並非局部的情況。好比說數據中心斷電了。災難的本質在於不少事情都同時出現故障，沒法在一個數據中心經過備份服務器提供冗餘解決問題。所以有必要要確保數據被保存在另一個安全的地方。不少公司會把不一樣的組件放在不一樣的辦公室，即便公司相對較小的時候也這麼幹。

程序(Procedure)

若是你管理一個小站點，你能夠不用規劃並手動管理這些服務器，可是隨着服務器數量的快速增加，自動化就變得頗有必要。特別是下列的這些工做：

• 追加新Slave：追加新Slave的方法有不少。通常的步驟是先獲取現有一個服務器的快照，一般是一個Slave服務器，而後在新服務器上恢復快照，並在正確的位置開始複製。這個裏須要注意的是獲取服務器快照這一步，由於這將直接決定你能夠多長時間讓一個新Slave服務器上線。獲取快照的方法有如下幾種：
  • 使用mysqldump：使用mysqldump安全但比較慢。這種方法容許你用與以前不一樣的存儲引擎去恢復數據。若是使用InnoDB表的話，還能夠獲得一致性快照，這也意味着你不須要脫機進行快照。
  • 複製數據庫文件：這個相對來講要快一點，可是須要脫機。
  • 使用在線備份方法：有不一樣的方法，好比InnoDB的熱備份（Hot Backup）
  • 使用LVM獲取快照：在Linux系統，可使用Logical Volume Manager(LVM)來得到卷快照。它要求你事先建立好特殊的LVM卷。
  • 使用文件系統的快照方法：Solaris ZFS文件系統支持內置快照，這種方法用於備份很是快。除了mysqldump之外，這些方法都不能使用一個不一樣的存儲引擎來重建數據。
• 刪除Slave：刪除Slave只須要通知負載均衡器該Slave不可以使用便可。
• 切換Master：對於平常維護，將連在Master上的全部Slave切換到備份Master上，並通知負載均衡器該Master不可以使用，是一件很日常的事。這個過程應該能夠無須宕機處理。這個能夠經過Slave提高來完成，也能夠採用更簡單的host standby來解決。
• 處理Slave故障：Slave會出現故障，這只是一個頻率問題。因此處理Slave故障在任何部署中都必須做爲一個常規事件來對待。若是檢測到Slave不在，通知負載均衡器該Slave不可以使用便可。
• 處理Master故障：當Master忽然出現故障時，你必須檢測到這個故障，並把全部的Slave都連到一個備用服務器上，或者把其中一個Slave提高爲新Master。
• Slave升級：把Slave升級到一個新版本通常不會有問題，但會暫時不可以使用，跟刪除Slave操做差很少。
• Master升級：爲了升級Master，常常有必要首先升級全部的Slave。但這也不必定。升級的時候，Master確定不可用，這跟處理Master故障操做差很少。

 熱備份(Hot Standby)

最簡單的複製服務器的拓撲就是熱備份的拓撲。該拓撲結構裏面包括一個Master和一個被稱做熱備份的專用服務器。工做原理就是當Master發生故障時，熱備份當即充當Master的鏡像服務器，全部的客戶端和Slave服務器所有切換到熱備份服務器進行工做。不過切換的時候須要考慮一些細節的問題：1）當切換到熱備份的服務器時，你須要從新定位須要從哪裏開始複製二進制日誌，通常熱備份的日誌位置信息和Master不同；2）某個Slave可能須要的二進制日誌在熱備份服務器上不必定有；3）當修好的Master切換回來的時候，它上面的有些修改可能任何其餘Slave都將來得及複製。

首先，問題簡單化，咱們看看從Master切換到熱備份服務器的過程，該過程Master並不宕機。默認狀況下，slave線程執行的事件並不寫入二進制日誌，可是做爲熱備份的slave明顯是須要這些二進制日誌的，因此爲熱備份服務器增長這樣一個參數。

[mysqld]
log-slave-updates

切換時的主要問題在於，如何使得從熱備份服務器開始複製的位置和從Master中止複製的位置徹底相同。有不少緣由可使得熱備服務器和Master服務器的二進制日誌位置信息不一致，好比Master啓動的時候熱備份服務器並無連上，即便這個沒問題，也不能保證同一個事件寫入Master和熱備份服務器二進制日誌的過程和時機徹底同樣。

切換的基本思路是：確認讓slave和熱備份服務器在同一點上中止複製，而後讓salve連到熱備份服務器。

standby>SHOW SLAVE STATUS\G
...
Relay_Master_Log_File: master-bin.000096
...
Exec_Master_Log_Pos: 756648

slave>SHOW SLAVE STATUS\G
...
Relay_Master_Log_File: master-bin.000096
...
Exec_Master_Log_Pos: 743456

# 從上可知說明熱備份服務器的日誌位置要領先於Slave，因此須要讓Slave從Master繼續複製到和熱備份同樣的位置

slave>START SLAVE UNTIL MASTER_LOG_FILE = 'master-bin.000096' MASTER_LOG_POS = 756648;
slave>SELECT MASTER_POS_WAIT('master-bin.000096', 756648);

# 如今Slave和熱備份服務器都在同一個點中止複製，就可讓Slave連到熱備份服務器上，可是指定從哪一個文件和位置開始複製呢。對於同一個複製點在Master上的文件和位置和熱備份上的文件和位置是不同的。
standby>SHOW MASTER STATUS\G
                      File: standby-bin.000019
               Position: 56447
      Binlog_Do_DB:
Binlog_Ignore_DB:

slave>CHANGE MASTER TO
              MASTER_HOST = 'standby-1',
              MASTER_PORT = 3306,
              MASTER_USER = 'repl_user',
              MASTER_PASSWORD = 'xyzzy',
              MASTER_LOG_FILE = 'standby-bin.000019',
              MASTER_LOG_POS = 56447;
slave>START SLAVE;

若是Slave的複製位置在熱備份服務器以前的話，咱們只需互換一下上面的步驟。下一節咱們將考慮如何處理Master意外中止的狀況。

雙Master(Dual Master)

雙Master拓撲結構中，兩個Master互相複製數據以保持同步。由於是對稱的，這種設置容易使用。這種設置中，服務器能夠是主動的(active)，也能夠是被動(passive)的。主動的服務器是指接受寫操做，而後這些變化經過複製傳播到其餘Slave上。被動的服務器是指不接受寫而僅僅是跟隨主動Master，隨時準備切換。兩個服務器有兩種設置，一種是active-active，一種是active-passive，第二種很像熱備份的的拓撲，帶是因爲是對稱，切換起來比較方便。在雙Master配置中，passive服務器並不必定要求接受讀請求，這個時候其實就是一個冷備份。在雙Master的拓撲中，並不必定非要經過複製來保證兩個Master的同步。

active-active型雙Master的經常使用的一個場景就是讓服務器在物理上接近不一樣的用戶組。用戶使用本地服務器，更改會被複制到另一臺服務器來保持二者同步。因爲事務是在本地提交的，因此響應比較快。但因爲事務是本地提交的，兩個服務器並非時時刻刻徹底一致的。這就會有些問題：1）若是同一個信息在兩臺服務器上更新，將會服務器將會產生衝突，複製也會終止。你能夠只讓其中一臺接受寫操做，能夠在某種程度上避免衝突的發生。2）若是兩臺服務器在處於不一致狀態下發生故障，有些事務將會丟失，這也是異步複製的硬傷，不過你能夠經過使用半同步複製(MySQL 5.5引入)來限制事務丟失的個數。

對於active-passive型的來講，你可能使用passive的Master來作服務器升級這樣的管理工做。active-passive有一個根本性的問題須要解決。split-brain syndrome：當網絡鏈接短期內中斷，從而使得從服務器主動升級爲主服務器，而後網絡又恢復了。若是在他們各自爲主服務器的時間裏，更改在兩臺服務器上都執行就會產生衝突。當使用共享磁盤的方式時，兩臺服務器同時寫磁盤會產生有趣的問題。

對於如何實現雙Master直接的同步，有幾種方案。

共享磁盤(Shared Disks)

 

 這是最直接的雙Master方案：兩個Master經過一個像SAN(Storage Area Network)的共享磁盤架構鏈接在一塊兒，並被設置成使用相同的文件。由於其中一個是passive，它不會寫任何東西到文件中，

使用DRBD複製磁盤(Replicated disks using DRBD)

 

雙向複製(bidirectional replication)

 

半同步複製(Semisynchronous Replication)

 

Slave提高(Slave Promotion)