PagerDuty數(shù)據(jù)庫遷移EC2XtraDBMySQL
摘要：PagerDuty是一款IT警報系統(tǒng)工具，作者Doug Barth分享了PagerDuty是如何成功地把現(xiàn)有系統(tǒng)MySQL遷移至XtraDB Cluster，以及在這一過程中遇到的利與弊。
【編者按】 PagerDuty是一家新興的互聯(lián)網(wǎng)創(chuàng)業(yè)公司，它是一款能夠在服務器出問題是發(fā)送提醒的產(chǎn)品，包括屏幕顯示、電話呼叫、短信通知、電郵通知等。目前AdMob、37Signals、StackOverflow、Instagram等均采用了PagerDuty作為消息通知以及突發(fā)事件處理工具。本文作者Doug Barth分享了PagerDuty是如何成功地把現(xiàn)有系統(tǒng)MySQL遷移至XtraDB集群，以及在這一過程中遇到的利與弊。
在半年前，PagerDuty公司成功地把現(xiàn)有系統(tǒng)從MySQL遷移至XtraDB集群，并在其上運行亞馬遜EC2。
舊系統(tǒng)配置分析
從配置上看，這是一個非常典型的MySQL環(huán)境：
一對Percona服務器負責對一個DRBD卷進行數(shù)據(jù)寫入。
以主副EBS雙機對DRBD卷進行備份。
設立兩個同步復制數(shù)據(jù)庫，當主服務器出現(xiàn)問題時，能把業(yè)務系統(tǒng)無縫轉(zhuǎn)移到次服務器。
配置一系列異步復制機，以應對重大災難、緊急備份、突發(fā)變更維護。
存在的問題
兢兢業(yè)業(yè)的舊系統(tǒng)服務多年后，面對日益突出的可靠性問題，開始顯現(xiàn)出力不從心了。此外，每次進行主服務器切換，無疑于是一場悲劇：要進行DRBD主機切換，首先得在主服務器上中斷MySQL，脫機DRBD卷，把從服務器狀態(tài)變更為主服務器，重新載入DRBD，后重啟MySQL。而這一整套過程會導致服務中斷，因為MySQL在由中斷到重啟的過程中，我們設置了一個冷卻緩沖池，在系統(tǒng)服務重回正軌前這個冷卻機制需要時間預熱。
我們嘗試通過Percona的緩沖池恢復(buffer-pool-restore)功能來減少中斷時間，但這相對于我們體型龐大的緩沖池來說如同蚍蜉撼樹。同時該功能會增加額外的系統(tǒng)資源開銷。還有個問題是，一旦發(fā)生意外的主服務器切換，異步從服務器將停止運作，必須手動重啟。
擁抱XtraDB集群的原因
XtraDB集群的特色：相校于之前的雙機系統(tǒng)，集群中采用的是三機同時運作，兩兩進行同步備份。因此連接切換時間大為減少。
支持多主服務器同時在線，每個主服務器擁有一個熱緩沖池。異步從服務器可以選擇任何節(jié)點作為主機，節(jié)點間的轉(zhuǎn)移不會中斷備份復制進程。
自動化的節(jié)點機制與我們目前的自動化系統(tǒng)配合良好。配置新節(jié)點后，我們只需提交一個節(jié)點地址，新節(jié)點將會自動收到一個數(shù)據(jù)備份集，同步數(shù)據(jù)后會加載到主服務器群中。
前期準備
將XtraDB集群接入現(xiàn)行系統(tǒng)，需要進行一定的前期準備。部分是簡單的MySQL微調(diào)，其余的是一些基礎化的操作。
在MySQL上的操作：
確保只在InnoDB數(shù)據(jù)表中設置主鍵。
確保不使用query cache(查詢緩存)，由于cluster不支持。
復制方式由基于語句的方式變更為基于行的方式。
除上述MySQL端的操作，為了能在DRBD服務器上進行獨立的測試，應用系統(tǒng)端需要進行如下的變更：
采用分布式鎖機制，由于MySQL采用的是從本地到集群節(jié)點的，例如：執(zhí)行SELECT FOR UPDATE語句。
用Zookeeper鎖替換MySQL鎖。
為了檢驗所有寫入的數(shù)據(jù)能在所有節(jié)點上進行數(shù)據(jù)同步，我們對作業(yè)邏輯作出變更，以大量小規(guī)模數(shù)據(jù)處理代替一次性大規(guī)模數(shù)據(jù)處理。
模式變更的選擇
在XtraDB集群中進行模式變動是牽一發(fā)而動全身的。在集群有兩種實現(xiàn)方式，一種是total order isolation (TOI，總序分離式)，另外一種是rolling schema upgrade (RSU，滾動模式升級)。
在RSU模式下，允許單獨地對節(jié)點進行更新。當執(zhí)行DDL語句時，按序同步各個節(jié)點，執(zhí)行完畢后再重新加入集群。但是這個功能會招致不穩(wěn)定性，同時數(shù)據(jù)的大量刷新動作引起的系統(tǒng)問題是不可避免的，由于RSU需要等待DDL語句執(zhí)行完畢才能進行緩存刷新。
相比之下，TOI的更新操作是一次性同步所有節(jié)點，阻斷集群通信直到更新完成。我們衡量一番后，決定采用TOI模式。由于系統(tǒng)中斷時間較短，所以這次沒有對集群進行阻斷。
遷移過程
首先，我們在現(xiàn)系統(tǒng)中建立一個集群作為現(xiàn)DRBD數(shù)據(jù)庫的一個從屬。當該從屬數(shù)據(jù)庫接收到所有寫入操作時，我們可以進行壓力測試，看看它的承載能力如何；同時會進行相關數(shù)據(jù)收集和分析。
在進行一系列相關基準測試后，我們發(fā)現(xiàn)了兩點技術細節(jié)是能夠幫助實現(xiàn)遷移前后的系統(tǒng)性能趨于一致：
?把innodb_flush_log_at_trx_commit的值設為0或2，可以獲得優(yōu)寫入性能。由于所有變更都是被復制到3個節(jié)點的，即使出現(xiàn)失效情況都不會出現(xiàn)數(shù)據(jù)丟失情況。
innodb_log_file_size的值需要設置成較大數(shù)值，我們將其設置為1GB。
進行一番測試后，XtraDB集群的各項指標令人滿意，我們接下來開始著手進行實際切換。
首先把所有測試環(huán)境下的配置進行備份。因為一旦cluster出現(xiàn)宕機，我們可以快速恢復其至一個單一節(jié)點cluster。我們編寫了具體的操作程序以及進行了相關壓力測試。
在對現(xiàn)有系統(tǒng)的兩個DRBD服務器進行從屬服務器設置后，我們還設置了其余服務器的從屬設置（例如：災難恢復，備份等）。一切就緒后，我們執(zhí)行了一次常規(guī)的從屬升級操作把系統(tǒng)切換到新環(huán)境中。
切換后的優(yōu)點分析
對正在運行的cluster進行重啟和更新時，成功避免了之前造成的通信中斷影響。成功以TOI模式（pt-online-schema-change）進行模式變更。寫入沖突處理能力得到優(yōu)化提升。當發(fā)現(xiàn)一個沖突后，XtraDB Cluster會返回一個死鎖錯誤信息，在以TOI模式執(zhí)行DDL語句時同樣可觸發(fā)該錯誤信息返回。之后，沖突錯誤會導致應用程序服務器返回一個503錯誤，而我們的負載平衡層設置會捕獲該錯誤，隨后會嘗試在另外的服務器上重新遞交寫入請求。
切換后的缺點分析
部分cluster的關鍵狀態(tài)計數(shù)器是按狀態(tài)改變的，例如在執(zhí)行顯示全局狀態(tài)指令后(SHOW GLOBAL STATUS)，其值會重設為0。這樣會造成很難根據(jù)計數(shù)器來進行重要的狀態(tài)監(jiān)控，例如流控制，因為其值的頻繁變更會造成無法準確監(jiān)控系統(tǒng)的狀態(tài)（在使用XtraDB Cluster 5.6的Galera 3.x系統(tǒng)中，該問題已得到解決）。當一寫入操作沖突發(fā)生時，MySQL動態(tài)記錄適配器會忽略來自交互語句拋出的異常。
對于系統(tǒng)冷卻預熱問題仍待進一步改進。目前，我們的應用程序服務器是連接到一個本地的HAproxy實例，該實例會把自身的連接數(shù)據(jù)發(fā)送給一個cluster節(jié)點。在執(zhí)行計劃維護任務時，我們只能緩慢地把數(shù)據(jù)推入另一個節(jié)點，以在其能完全承載整個系統(tǒng)負荷前進行緩沖池的預熱。在將來，我們會按計劃完全轉(zhuǎn)變?yōu)槎嘀鳈C環(huán)境設置，以確保所有節(jié)點都有一個就緒的緩沖池。
本站文章版權歸原作者及原出處所有 。內(nèi)容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構(gòu)成任何投資及應用建議。本站是一個個人學習交流的平臺，網(wǎng)站上部分文章為轉(zhuǎn)載，并不用于任何商業(yè)目的，我們已經(jīng)盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯(lián)系我們，我們將根據(jù)著作權人的要求，立即更正或者刪除有關內(nèi)容。本站擁有對此聲明的最終解釋權。
