MySQL高可架構(gòu)設(shè)計(jì)方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

29、okeeper 之間的通信正常2、 Agent 與 MySQL之間的通信正常3、 Agent 正常運(yùn)行4、 Zookeeper 正常運(yùn)行5、 MySQL的主庫(kù)和備庫(kù)上的1 個(gè)實(shí)例是正常運(yùn)行的測(cè)試方法關(guān)閉MySQL主庫(kù)上的1 個(gè)實(shí)例停止MySQL從庫(kù)的復(fù)制進(jìn)程輸入 / 動(dòng)作用 mysqladmin shutdown 命令關(guān)閉MySQL主庫(kù)上的1 個(gè)實(shí)例用 stop slave 關(guān)閉從庫(kù)的復(fù)制進(jìn)程期望的輸出1 、 Agent 能夠在可接受的時(shí)間對(duì)MySQL進(jìn)行切換，并將從庫(kù)置為新的主庫(kù)， read-only 屬性為可寫(xiě)2、如果在規(guī)定的時(shí)間將MySQL主從復(fù)制恢復(fù)正常，則Agent 不需要發(fā)起自動(dòng)切換用例編號(hào)ha006測(cè)試場(chǎng)景Agent 出現(xiàn)異常退出場(chǎng)景描述Agent 因?yàn)楫惓；驂毫^(guò)大導(dǎo)致退出測(cè)試目的Agent 的自動(dòng)恢復(fù)機(jī)制是否完