亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

MySQL復制(三) --- 高可用性和復制

系統 1840 0

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

  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)

?

MySQL復制(三) --- 高可用性和復制

?這是最直接的雙Master方案:兩個Master通過一個像SAN(Storage Area Network)的共享磁盤架構連接在一起,并被設置成使用相同的文件。因為其中一個是passive,它不會寫任何東西到文件中,

使用DRBD復制磁盤(Replicated disks using DRBD)

MySQL復制(三) --- 高可用性和復制

?

雙向復制(bidirectional replication)

MySQL復制(三) --- 高可用性和復制

?

半同步復制(Semisynchronous Replication)

?

Slave提升(Slave Promotion)

?

?

?

?

?

?

?

?

?

?

?

MySQL復制(三) --- 高可用性和復制


更多文章、技術交流、商務合作、聯系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 免费视频久久看 | 四虎影视国产精品永久在线 | 深夜视频在线 | 久久这里只有精品1 | 色资源在线 | 99视频精品国在线视频艾草 | 国产精品免费看久久久麻豆 | 永久黄网站色视频免费观看99 | 国产精品99r8在线观看 | 九色网址 | 亚洲精品久久玖玖玖玖 | 国产精品免费入口视频 | 欧美特黄aaaaaa | 在线麻豆 | 日本亚欧乱色视频在线网站 | 国产人成午夜免视频网站 | 中文国产成人久久精品小说 | 一本色道久久综合亚洲精品高清 | 91大片| 亚洲欧洲尹人香蕉综合 | 欧美 亚洲 另类 热图 | 中文字幕三级久久久久久 | 在线不卡视频 | 日本特黄一级午夜剧场毛片 | 天天天天天天天操 | 国产日产欧美精品一区二区三区 | 手机福利在线 | 欧美综合图区亚欧综合图区 | 日本在线观看一级高清片 | 性欧美高清久久久久久久 | 无遮挡又黄又爽又色1000部 | 黄色成人在线网站 | 婷婷综合激情五月中文字幕 | 四虎地址 | 深夜福利网站在线观看 | 久久精品久久精品久久精品 | 亚洲欧美日韩高清专区一区 | 国产精品入口麻豆 | 国产精品一区二 | 日韩欧一级毛片在线播无遮挡 | 国产美女mm131爽爽爽免费 |