MySQL高可架構(gòu)設計方案

1、MySQL高可架構(gòu)設計方案2.1. 高可用環(huán)境高可用(High Availability )有兩種不同的含義，在廣義環(huán)境中，是指整個系統(tǒng)的高可用特性，在狹義方面，一般指主機的冗余接管，如主機HA。我們目前的產(chǎn)品及相關(guān)系統(tǒng)平臺主要都傾向于廣義上的高可用。一個良好的高可用環(huán)境，不僅僅能避免系統(tǒng)本身的問題，還能防止天災人禍，并且有一個簡單可靠的系統(tǒng)維護方法，同時能在最小的成本資源下產(chǎn)生最大的效益。高可用的計算方法一般以年在線率來計算，例如規(guī)定整個系統(tǒng)一年之中的可用環(huán)境要達到 99.95%，那么24*365* ( 1-99.95% ) = 4.38 小時(包括計劃維護時間)。另外，子系統(tǒng)的可用性一定會

2、高于整個系統(tǒng)的可用性，如整個系統(tǒng)的可用性為99.95%，則對于子系統(tǒng)，可用性可能就是要求達到99.999%?？捎眯约墑e= 計劃外與計劃內(nèi)停機圖 2-1 高可用級別對照表在實際產(chǎn)品開發(fā)中，很難達到100%的在線能力，即使真的達到，代價會非常大。一般能達到99.9%以上的可用性的環(huán)境，都可以認為是比較高的可用環(huán)境成本圖 2-2 收益與成本在公司收益與投入成本計算方面取得一個平衡，則是最終所希望的在線效率，但是收益與成本的計算方法則是決策者與實施者需要著重考慮的問題，適合自己的高可用環(huán)境即是最好的，不能盲目地追逐過高的可用性。2.2. 主要風險在一個高可用的環(huán)境中，會遇到各種風險，主要的風險如下系統(tǒng)

3、失敗或崩潰( System faults and crashes )? 應用層或中間層錯誤( Application and middleware failures )網(wǎng)絡失敗( Network failures)介質(zhì)失效，一般指存放數(shù)據(jù)的媒體介質(zhì)故障( Media failures )人為失誤( Human Error )分級與容災( Disasters and extended outages )計劃宕機與維護( Planned downtime, maintenance and management tasks2.3. 面臨的主要問題使用MySQL+PC服務器來構(gòu)建高可用的MySQL集群

4、會遇到一些主要的問題，這些問題如果忽略了或者沒有去解決好，是會對高可用造成影響的，設置直接影響到整個產(chǎn)品及系統(tǒng)的穩(wěn)定運行。MySQL會丟數(shù)據(jù)嗎MySQL自身的穩(wěn)定性怎么樣MySQL的性能怎么樣MySQL如何快速自動切換MySQL如何進行可靠的容災MySQL主備庫數(shù)據(jù)的一致性校驗MySQL備庫同步延遲，備庫跟不上主庫MySQL在線DDL鎖表（阻塞寫）怎么解決相比商業(yè)軟件成熟的解決方案，MySQL+PC架構(gòu)其高可用性如何保證3. MySQL 數(shù)據(jù)可靠性3.1. 背景MySQL實例Down掉會不會丟數(shù)據(jù)MySQL服務器Down掉（比如斷電、CPU、存損壞等）會不會丟數(shù)據(jù)硬盤壞掉會不會丟數(shù)據(jù)說明：My

5、SQL丟數(shù)據(jù)更多地是指，MySQL采用PC服務器，PC服務器存在硬件損壞的可能性（比如CPU、存、硬盤壞掉），從而導致丟數(shù)據(jù)。3.2. 解決方案1、傳統(tǒng)思路共享存儲2、非共享存儲思路可以分開對MySQL和應用兩個方面進行一定的設置和處理，相當于是雙保險的方式，使數(shù)據(jù)不丟失。對于 MySQL設置 innodb_flush_log_at_trx_commit = 1設置為 1 ：每個事務日志都Flush 到磁盤設置為 2：每個事務刷到log file 中，每秒Flush 到磁盤設置 sync_binlog = 1設置為0：事務提交后，MySQL不做fsync 之類的磁盤同步命令刷新binlog_c

6、ache中的數(shù)據(jù)到磁盤，而讓文件系統(tǒng)自行決定什么時候同步，或Cache滿了后才同步到磁盤。設置為1：事務提交后，MySQL會將binlog_cache 中的數(shù)據(jù)強制寫入磁盤，是最安全的設置。設置 innodb_support_xa = true設置為1：是否支持分布式事務（默認是打開）設置為0：不支持分布式事務如果確認應用中不需要使用分布式事務，可關(guān)閉該參數(shù)Slave 遠程 binlog通過 Slave 來保證數(shù)據(jù)不丟失，binlog 實時傳送到遠程Slave ，如果主備庫之間的網(wǎng)絡較好的話，一般的（依賴于RTT） ，備庫的時間基本上在毫秒之。半同步復制（Semi-Sync）半同步復制總體上可

7、以保證數(shù)據(jù)的零丟失，但是可能對性能會有少許影響，會造成約20%的TPS下降。說明：1、 innodb_flush_log_at_trx_commit 、 sync_binlog 、 innodb_support_xa 三個參數(shù)的設置在保證數(shù)據(jù)安全性和可靠性的同時，對性能是有一定的犧牲的。innodb_flush_log_at_trx_commit、sync_binlog都為0 時，性能比其中一個設置為1高出約幾百倍；innodb_flush_log_at_trx_commit、sync_binlog都為1 時，性能比其中一個設置為1相差約幾倍；sync_binlog 為 0 和 1 時的系統(tǒng)寫

8、入性能差距可能會達到5 倍或更多對于應用應用雙寫（寫兩份）應用將同一記錄寫兩份到不同的庫中應用通過記錄log 來實現(xiàn)可以通過應用程序（Java、 C+）自己寫獨立的日志來記錄數(shù)據(jù)，也可以通過開源的消息中間件來實現(xiàn)日志記錄。4. MySQL 數(shù)據(jù)一致性4.1. 背景MySQL主庫異常Down掉，會導致主備庫之間的數(shù)據(jù)不一致MySQL主備切換后，備庫成為主庫，數(shù)據(jù)存在不一致MySQL的邏輯復制理論上是有風險的，極端情況下可能存在主備數(shù)據(jù)不一致4.2. 解決方案4.2.1. 常規(guī)設置innodb_flush_log_at_trx_commit = 1設置sync_binlog = 1設置innodb

9、_support_xa = true半同步復制(Semi-Sync)主備庫盡量采用row 模式復制，不要采用statement 模式復制主備庫定期數(shù)據(jù)一致性校驗數(shù)據(jù)生命周期的binlog 盡量保存下來4.2.2. 主備切換Master 宕機后，有三個選擇Slave 立即提供服務，存在數(shù)據(jù)不一致風險Slave 不提供服務，等待Master 恢復，保證數(shù)據(jù)一致Slave 提供部分服務(比如只能新建，不允許修改)，等待 Master 恢復后，保持數(shù)據(jù)一對于我們的MySQL高可用環(huán)境，我們采用的處理策略1、 Slave 立即提供服務2、 Slave （舊）Master （新）3、 Master （舊）

10、Rollback4、 Master （舊）Slave （新）5、 Master （新）ReplayRollback & ReplayMasterSlaveReplayRollbackRollback Master 回滾，保持與Slave重新恢復主備復制關(guān)系Replay Slave 重放，減少數(shù)據(jù)丟失沖突檢測機制5. MySQL 容災5.1. 背景互聯(lián)網(wǎng)應用以普通的PC服務器為主通過業(yè)務功能的寫入主庫通常只有一個，造成單點意外操作 導致數(shù)據(jù)丟失會遇到不可抗力因素或異常導致宕機emi-Syncwrite分布式數(shù)據(jù)中間層writeAppSlaveread-only = offSlave2My

11、SQL復制模式是M-M-S，切換時只需修改read-onlyRemi-SyncMaster應用寫入數(shù)據(jù)時，記錄應用日志，日志可以用來恢復丟失的數(shù)據(jù)MySQL主從采用半同步復制(Remi-Sync)Slave 作為備庫，Slave2 也是備庫，作為容災庫6. MySQL 自動切換6.1. 背景互聯(lián)網(wǎng)應用以普通的PC服務器為主MySQL的主庫Down掉后，需要保持提供高可用的服務人工調(diào)整切換時間太長多個MySQL的主庫Down掉后，需要及時切換6.2. 解決方案6.2.1. 架構(gòu)方式1、整體架構(gòu)說明：SwitchAppZookAgSlaveAgent1Agent2MasterAgSwitch Ma

12、nager 是頁面化操作管理切換，目前暫時不實現(xiàn)，采用App+動態(tài)數(shù)據(jù)源直接與 Zookeeper 進行通信。2、詳細架構(gòu)連接管理器，連接不可用，或者監(jiān)控到Zookeeper 中的主備地址變化時（通過事件的方式可以獲得，無需定時檢查），從zookeeper 獲取新的數(shù)據(jù)庫Master 地址，建立新的連接/basedbMaster-:5000-:5001Agent定期檢查Zookeeper上的鎖更新時間，如果Master 更新超時，那么把 Slave 狀態(tài)變成master,readonly 屬性關(guān)閉同時更新zookeeper 上的Mas

13、ter地址，為原來Slave 的地址管理工具-lock=:5000-servers-:5000監(jiān)控 Master 狀態(tài)，定期更新 Zookeeper 上的鎖的時間，聲明 自己可用。1. 監(jiān)控主從狀態(tài)2. 主動主從切換（當主 恢復的時候，需要此功 能）3、整體思路主備庫構(gòu)成分布式環(huán)境，但是有狀態(tài)確保 Agent 可以重啟，可以任意次重啟，但是有超時限制主庫切換邏輯可以通過Zookeeper 實現(xiàn)鎖的升級實現(xiàn)切換時，MySQL的 read-only 的設置很重要切換時，需要將異常的故障節(jié)點+App 數(shù)據(jù)源一起切換1、首先在Zookeeper 初始化，創(chuàng)建對應

14、的節(jié)點，寫入模塊信息、數(shù)據(jù)庫源名稱、數(shù)據(jù)庫 IP、數(shù)據(jù)庫端口信息等，然后寫入下面的數(shù)據(jù)庫子節(jié)點中，并添加watcher ，增加監(jiān)視事件。2、 創(chuàng)建 lock 子節(jié)點， 不需要設置watcher ， 如果當前client 的 id 是當前最小的節(jié)點，則獲得了lock ，退出。否則繼續(xù)等待，如果id 不存在，則創(chuàng)建子節(jié)點3、當發(fā)生異常master 宕機后，則watcher 事件觸發(fā)，然后從當前id 序列中得到最小的 id, 將該節(jié)點置為新的master ，同時將DB的 read-only 置為on，保證可以讀寫1.1.2. 流程設計流程1： Agent 啟動流程 2：數(shù)據(jù)庫監(jiān)控正常開始流程3： 數(shù)

15、據(jù)庫監(jiān)控數(shù)據(jù)庫Down流程4： Master 庫正常停止流程五：應用啟動，初始化數(shù)據(jù)庫連接池dfd Data Flow結(jié)束流程六：應用監(jiān)聽到Active 數(shù)據(jù)庫宕機1.1.3. 應用層切換設計目前我們連接池重建連接的過程是當在連接上執(zhí)行DB操作時發(fā)生特定異常時觸發(fā)連接池關(guān)閉不可用連接，重新向數(shù)據(jù)源獲取連接。在使用Oracle 的 RAC配置特性時，Oracle 在驅(qū)動層會自行判斷數(shù)據(jù)源是否可用，若不可用則嘗試從另外一個數(shù)據(jù)源獲取連接，Oracle的這個特性可以理解為對等數(shù)據(jù)源的優(yōu)先選擇。但 MYSQL的復制機制（非共享存儲）決定了其驅(qū)動層不能支持當主庫出問題時自動連接到從庫上，因此我們考慮使用

16、GroupDataSource來實現(xiàn)類似Oracle 驅(qū)動做的事情，即數(shù)據(jù)源組中的首選數(shù)據(jù)源不可用時，我們嘗試同組中的其他數(shù)據(jù)源來獲取連接，對于連接池來說這個過程是透明的。連接池還是保持之前當連接異常時，觸發(fā)執(zhí)行關(guān)閉不可用連接并重新獲取連接即可。主備切換和按權(quán)重選擇、按優(yōu)先級選擇數(shù)據(jù)源的選擇策略是不一樣的，因此設計DbSelector 來描述數(shù)據(jù)源的選擇策略，不同的選擇策略在同一數(shù)據(jù)源組中會同時存在，一個 GroupDataSource 包括寫數(shù)據(jù)源選擇策略、讀數(shù)據(jù)源選擇策略和運行時切換策略，使用何種具體策略取決于組數(shù)據(jù)源的配置。待選擇的數(shù)據(jù)源要對等的，即讀數(shù)據(jù)源選擇策略只針對標識為讀的數(shù)據(jù)源

17、，不能把讀寫數(shù)據(jù)源混在一起選擇。引入了 Zookeeper 之后，我們可以通過Zookeeper 感知到主數(shù)據(jù)庫的狀態(tài)。Zookeeper在完成主備切換后會通知應用程序主數(shù)據(jù)庫發(fā)生了變更，應用程序收到通知后，需要關(guān)閉連接池中之前已建立的主數(shù)據(jù)庫連接，重新創(chuàng)建新的主庫連接。基于Zookeeper 的通知機制，我們在 AtomDataSource 中接收數(shù)據(jù)源配置變化的信息, 收到變化通知后更新數(shù)據(jù)源本身的狀態(tài)，同時建立listner 機制，把數(shù)據(jù)源狀態(tài)變化發(fā)布給連接池等對象進行相應的處理。1、類圖：class DataSourceObject?interface?DataSourceDsStat

18、eChangeEv ent<DsState>+ getOldValue() : DsState+ getNewValue() : DsState+ getSource() : DataSource2、獲取連接時序圖s d Get Connectionsd Activ e Sw itchcloseNaConnections()s d Activ e Sw itchcloseNaConnections()7.2.1 中的架構(gòu)方式為基準進行的1、 Agent 異常No異常表現(xiàn)觸發(fā)動作說明a1異常退出要求在recv_timeout 的時間可重啟，否則會進行切換需 要 記 住 client

19、端 的 session ， 否 則 進 行 自 動 recover 。 無 法 設 置 read-only ，需要第三方a2與 MySQL的通信異常與 MySQL進行讀寫測試，重試機制、重試次數(shù)、間隔可控制若 MySQL正常，通信問題可 以忽略（同一臺機器）a3與 zk 之間的網(wǎng)絡異常（設置read-only ）通過超時來控制，大于recv_timeount 則切換由于session 的綁定無法恢復，需進行切換a4機器死機（設置read-only ）與 zk 之間的通信中斷，在大于 recv_timeout 之后進行自動切換2、 MySQL異常No異常表現(xiàn)觸發(fā)動作說明m1訪問異常定期進行讀寫（

20、設置 read-only ）主庫：插入時間戳（可重試，重試間隔可設置）從庫：讀取時間戳（同上）若 MySQL連接被 kill 掉，重新創(chuàng)建連接若異常，認為MySQL掛掉，進行切換m2機器死機同 a4m3機器的網(wǎng)絡異常同 a3m4所在的整個機房down掉（ Zookeeper 也掛掉，被踢出集群）發(fā)起自動切換6.2.6.Zookeeper 節(jié)點設計固定節(jié)點，存放Zookeeper 運行節(jié)點設計RunTime 狀態(tài)說明：1、 basedb 這一級的節(jié)點，當進行分庫擴展的時候，就在后面加上數(shù)值進行區(qū)分，比如basedb1、 basedb2 等6.3. 部署及使用場景6.3.1. 部署方式對MySQL

21、進行水平切分，拆分成很多套數(shù)據(jù)庫，主備庫可以部署在不同機房MySQL的復制模式采用Master ( read-only ) Master ( rw) Slave ( read-only )數(shù)據(jù)庫中間層(動態(tài)數(shù)據(jù)源包括在)部署在程序端，配置推送采用 IP 的方式采用可靠的Zookeeper 集群保障，Zookeeper 可以部署在三個機房優(yōu)勢多機房部署可實現(xiàn)IDC容災不受限于DNS可以進行全頁面操作的方式在人工情況下可以將主庫切換到任意備庫TipsZookeeper 集群中機器的可靠性可以保障，只要半數(shù)以上的機器存活即可，是穩(wěn)定的第三方。Zookeeper 集群為了保證其自身的穩(wěn)定性，機器的最少

22、數(shù)量為3，因此對應的MySQL在一個集群節(jié)點中的最少部署數(shù)量也為3 個庫， 兩個 Master 庫分別為只讀和讀寫，一個 Slave庫作為容災庫。1、場景 1：單機房部署IDC1 機房主庫（ read-only ）主庫（ rw ）從庫（容災read-only ）2、場景2：多機房部署IDC1 機房IDC2 機房IDC3 機房主庫(read-only )主庫(rwAgent1Agent2Zookeeper1Zookeeper2Zookeeper)從庫(容災read-only )Agent3Zookeeper3集群6.4. 頁面化管理及監(jiān)控6.4.1. 切換管理目前暫時不實現(xiàn)6.4.2. Zook

23、eeper 監(jiān)控Zookeeper 提供一些簡單但是功能強大的4 字命令， 通過對這些4 字命令的返回容進行解析，可以獲取不少關(guān)于ZK運行時的信息。用 jmx 也能獲取一些運行的信息/doc/r3.4.3/zookeeperJMX.html開源的瀏覽器查看Zookeeper 插件6.5.1. 測試環(huán)境測試環(huán)境硬件環(huán)境1 臺MySQL主庫服務器（2個實例master1、master2 ）1 臺MySQL從庫服務器（2個實例slave1 、slave2 ）1 臺Zookeeper服務器（1個實例）操作系統(tǒng)RedHat6 2.6.32-71 64 位軟件環(huán)境M

24、ySQL 5.6.11-log 二進制分發(fā)版Zookeeper 3.4.5 stable版6.5.2. 測試用例用例編號ha001測試場景MySQL連接中斷場景描述Agent 與 MySQL之間的連接中斷測試目的Agent 的自動重連機制及連接失敗后的切換處理前提條件1、 、 Agent 與 Zookeeper 之間的通信正常2、 Agent 與 MySQL之間的通信正常3、 Agent 正常運行4、 Zookeeper 正常運行5、 MySQL正常運行測試方法在 MySQL服務器上殺掉Agent 的連接進程輸入 / 動作在 MySQL中 Kill 掉 Agent 的連接進程期望的輸出1 、

25、Agent 在設置的間隔時間進行自動重連，連續(xù)嘗試5 次，如果沒有連接成功，則發(fā)起自動切換，重連的間隔和時間是可以設置的2、 Agent 如果自動重連成功，則返回成功的消息3、 MySQL的連接如果是被Kill 掉了，則需要創(chuàng)建連接用例編號ha002測試場景MySQL連接超時場景描述Agent 與 MySQL的一次連接超過設置的連接超時時間測試目的Agent 的自動重連機制及處理策略前提條件1、 、 Agent 與 Zookeeper 之間的通信正常2、 Agent 與 MySQL之間的通信正常3、 Agent 正常運行4、 Zookeeper 正常運行5、 MySQL正常運行測試方法將 My

26、SQL的連接超時時間設置的足夠小輸入 / 動作設置MySQL的 wait_timeout 參數(shù)期望的輸出1 、 Agent 在設置的間隔時間進行自動重連，連續(xù)嘗試5 次，如果沒有連接成功，則發(fā)起自動切換，重連的間隔和時間是可以設置的2 、 Agent 如果自動重連成功，則返回成功的消息用例編號ha003測試場景MySQL主庫的單個實例掛掉場景描述MySQL主庫上的1 個實例直接掛掉了測試目的MySQL主庫上的實例掛掉后能否及時切換并提供正常的服務前提條件1、 、 Agent 與 Zookeeper 之間的通信正常2、 Agent 與 MySQL之間的通信正常3、 Agent 正常運行4、 Zo

27、okeeper 正常運行5、 MySQL正常運行測試方法人為停掉MySQL主庫上的1 個實例輸入 / 動作通過mysqladmin shutdown 關(guān)閉MySQL實例通過kill -9 殺掉MySQL主庫的實例期望的輸出1 、 Agent 發(fā)起自動切換，在較短的時間將1 個從庫置為主庫，并提供MySQL服務2、如果在可接受的時間恢復了MySQL， Agent 不發(fā)起自動切換用例編號ha004測試場景MySQL服務器掛掉場景描述MySQL主庫服務器直接掛掉不可用測試目的MySQL主庫服務器掛掉后能否進行正常的MySQL服務前提條件1、 、 Agent 與 Zookeeper 之間的通信正常2、

28、 Agent 與 MySQL之間的通信正常3、 Agent 正常運行4、 Zookeeper 正常運行5、 MySQL正常運行測試方法人為關(guān)閉MySQL的主庫服務器輸入 / 動作通過shutdown 命令關(guān)掉MySQL的主庫服務器期望的輸出1 、 Agent 發(fā)起自動切換，在較短的時間將1 個從庫置為主庫，并提供MySQL服務2、如果在可接受的時間恢復了MySQL， Agent 不發(fā)起自動切換用例編號ha005測試場景MySQL主從連接斷掉場景描述MySQL主庫的1 個實例與從庫的1 個實例主從復制異常中斷測試目的MySQL主從復制異常中斷能否進行自動切換前提條件1、 、 Agent 與 Zo

29、okeeper 之間的通信正常2、 Agent 與 MySQL之間的通信正常3、 Agent 正常運行4、 Zookeeper 正常運行5、 MySQL的主庫和備庫上的1 個實例是正常運行的測試方法關(guān)閉MySQL主庫上的1 個實例停止MySQL從庫的復制進程輸入 / 動作用 mysqladmin shutdown 命令關(guān)閉MySQL主庫上的1 個實例用 stop slave 關(guān)閉從庫的復制進程期望的輸出1 、 Agent 能夠在可接受的時間對MySQL進行切換，并將從庫置為新的主庫， read-only 屬性為可寫2、如果在規(guī)定的時間將MySQL主從復制恢復正常，則Agent 不需要發(fā)起自動切換用例編號ha006測試場景Agent 出現(xiàn)異常退出場景描述Agent 因為異常或壓力過大導致退出測試目的Agent 的自動恢復機制是否完