PagerDuty實戰分析：將MySQL遷移至XtraDB并成功運行EC2

【編者按】 PagerDuty是一家新興的互聯網創業公司，它是一款能夠在服務器出問題是發送提醒的產品，包括屏幕顯示、電話呼叫、短信通知、電郵通知等。目前AdMob、37Signals、StackOverflow、Instagram等均采用了PagerDuty作為消息通知以及突發事件處理工具。本文作者Doug Barth分享了PagerDuty是如何成功地把現有系統MySQL遷移至XtraDB集群，以及在這一過程中遇到的利與弊。

---

在半年前，PagerDuty公司成功地把現有系統從MySQL遷移至XtraDB集群，并在其上運行亞馬遜EC2。

舊系統配置分析

從配置上看，這是一個非常典型的MySQL環境：

• 一對Percona服務器負責對一個DRBD卷進行數據寫入。
• 以主副EBS雙機對DRBD卷進行備份。
• 設立兩個同步復制數據庫，當主服務器出現問題時，能把業務系統無縫轉移到次服務器。
• 配置一系列異步復制機，以應對重大災難、緊急備份、突發變更維護。

存在的問題

兢兢業業的舊系統服務多年后，面對日益突出的可靠性問題，開始顯現出力不從心了。此外，每次進行主服務器切換，無疑于是一場悲?。阂M行DRBD主機切換，首先得在主服務器上中斷MySQL，脫機DRBD卷，把從服務器狀態變更為主服務器，重新載入DRBD，最后重啟MySQL。而這一整套過程會導致服務中斷，因為MySQL在由中斷到重啟的過程中，我們設置了一個冷卻緩沖池，在系統服務重回正軌前這個冷卻機制需要時間預熱。

我們嘗試通過Percona的緩沖池恢復(buffer-pool-restore)功能來減少中斷時間，但這相對于我們體型龐大的緩沖池來說如同蚍蜉撼樹。同時該功能會增加額外的系統資源開銷。還有個問題是，一旦發生意外的主服務器切換，異步從服務器將停止運作，必須手動重啟。

擁抱XtraDB集群的原因

XtraDB集群的特色：相校于之前的雙機系統，集群中采用的是三機同時運作，兩兩進行同步備份。因此連接切換時間大為減少。

支持多主服務器同時在線，每個主服務器擁有一個熱緩沖池。異步從服務器可以選擇任何節點作為主機，節點間的轉移不會中斷備份復制進程。

自動化的節點機制與我們目前的自動化系統配合良好。配置新節點后，我們只需提交一個節點地址，新節點將會自動收到一個數據備份集，同步數據后會加載到主服務器群中。

前期準備

將XtraDB集群接入現行系統，需要進行一定的前期準備。部分是簡單的MySQL微調，其余的是一些基礎化的操作。

在MySQL上的操作：

• 確保只在InnoDB數據表中設置主鍵。
• 確保不使用query cache(查詢緩存)，由于cluster不支持。
• 復制方式由基于語句的方式變更為基于行的方式。

除上述MySQL端的操作，為了能在DRBD服務器上進行獨立的測試，應用系統端需要進行如下的變更：

• 采用分布式鎖機制，由于MySQL采用的是從本地到集群節點的，例如：執行SELECT FOR UPDATE語句。
• 用Zookeeper鎖替換MySQL鎖。
• 為了檢驗所有寫入的數據能在所有節點上進行數據同步，我們對作業邏輯作出變更，以大量小規模數據處理代替一次性大規模數據處理。

模式變更的選擇

在XtraDB集群中進行模式變動是牽一發而動全身的。在集群有兩種實現方式，一種是total order isolation (TOI，總序分離式)，另外一種是rolling schema upgrade (RSU，滾動模式升級)。

在RSU模式下，允許單獨地對節點進行更新。當執行DDL語句時，按序同步各個節點，執行完畢后再重新加入集群。但是這個功能會招致不穩定性，同時數據的大量刷新動作引起的系統問題是不可避免的，由于RSU需要等待DDL語句執行完畢才能進行緩存刷新。

相比之下，TOI的更新操作是一次性同步所有節點，阻斷集群通信直到更新完成。我們衡量一番后，決定采用TOI模式。由于系統中斷時間較短，所以這次沒有對集群進行阻斷。

遷移過程

首先，我們在現系統中建立一個集群作為現DRBD數據庫的一個從屬。當該從屬數據庫接收到所有寫入操作時，我們可以進行壓力測試，看看它的承載能力如何；同時會進行相關數據收集和分析。

在進行一系列相關基準測試后，我們發現了兩點技術細節是能夠幫助實現遷移前后的系統性能趨于一致：

• 把innodb_flush_log_at_trx_commit的值設為0或2，可以獲得最優寫入性能。由于所有變更都是被復制到3個節點的，即使出現失效情況都不會出現數據丟失情況。
• innodb_log_file_size的值需要設置成較大數值，我們將其設置為1GB。

進行一番測試后，XtraDB集群的各項指標令人滿意，我們接下來開始著手進行實際切換。

首先把所有測試環境下的配置進行備份。因為一旦cluster出現宕機，我們可以快速恢復其至一個單一節點cluster。我們編寫了具體的操作程序以及進行了相關壓力測試。

在對現有系統的兩個DRBD服務器進行從屬服務器設置后，我們還設置了其余服務器的從屬設置（例如：災難恢復，備份等）。一切就緒后，我們執行了一次常規的從屬升級操作把系統切換到新環境中。

切換前后的架構變化如下圖所示：

切換后的優點分析

對正在運行的cluster進行重啟和更新時，成功避免了之前造成的通信中斷影響。成功以TOI模式（pt-online-schema-change）進行模式變更。寫入沖突處理能力得到優化提升。當發現一個沖突后，XtraDB Cluster會返回一個死鎖錯誤信息，在以TOI模式執行DDL語句時同樣可觸發該錯誤信息返回。之后，沖突錯誤會導致應用程序服務器返回一個503錯誤，而我們的負載平衡層設置會捕獲該錯誤，隨后會嘗試在另外的服務器上重新遞交寫入請求。

切換后的缺點分析

部分cluster的關鍵狀態計數器是按狀態改變的，例如在執行顯示全局狀態指令后(SHOW GLOBAL STATUS)，其值會重設為0。這樣會造成很難根據計數器來進行重要的狀態監控，例如流控制，因為其值的頻繁變更會造成無法準確監控系統的狀態（在使用XtraDB Cluster 5.6的Galera 3.x系統中，該問題已得到解決）。當一寫入操作沖突發生時，MySQL動態記錄適配器會忽略來自交互語句拋出的異常。

對于系統冷卻預熱問題仍待進一步改進。目前，我們的應用程序服務器是連接到一個本地的HAproxy實例，該實例會把自身的連接數據發送給一個cluster節點。在執行計劃維護任務時，我們只能緩慢地把數據推入另一個節點，以在其能完全承載整個系統負荷前進行緩沖池的預熱。在將來，我們會按計劃完全轉變為多主機環境設置，以確保所有節點都有一個就緒的緩沖池。

英文出自： Highscalability