# 在 PagerDuty 遷移到 EC2 中的 XtraDB 群集 > 原文： [http://highscalability.com/blog/2014/6/16/migrating-to-xtradb-cluster-in-ec2-at-pagerduty.html](http://highscalability.com/blog/2014/6/16/migrating-to-xtradb-cluster-in-ec2-at-pagerduty.html)  *這是軟件通才 [Doug Barth](https://twitter.com/dougbarth) 的來賓帖子，他目前發現自己在 [PagerDuty](https://www.pagerduty.com/) 從事運營工作。 在加入 PagerDuty 之前，他曾在芝加哥的 Signal 和在線旅游公司 Orbitz 任職。* 大約六個月前，PagerDuty 將其生產 MySQL 數據庫切換為在 EC2 內部運行的 [XtraDB 群集](http://www.percona.com/software/percona-xtradb-cluster) 。 這是我們為什么以及如何進行更改的故事。 ## 在之前的數據庫外觀 PagerDuty 的 MySQL 數據庫是相當典型的部署。 我們有： * 一對 Percona 服務器將數據寫入支持 [DRBD](http://www.drbd.org/) 的卷。 * 支持 DRBD 卷的主服務器和輔助服務器的 EBS 磁盤。 * 生產數據庫的兩個同步副本。 （如果主服務器發生故障，我們希望能夠快速切換到輔助服務器而不丟失任何數據。） * 許多異步復制從屬服務器，用于災難恢復，備份和意外修改恢復。 ## 舊設置出現問題 我們的數據庫設置已經為我們服務了好幾年，但是它提供的故障轉移架構沒有達到我們的可靠性目標。 另外，更改主機很麻煩：要從一臺 DRBD 主機切換到另一臺主機，我們必須在主服務器上停止 MySQL，卸載 DRBD 卷，將輔助服務器更改為主服務器狀態，在該輔助服務器上安裝該卷并啟動 MySQL。 該設置需要停機-并且一旦 MySQL 在新服務器上啟動并運行，我們就有了一個冷緩沖池，需要在應用程序性能恢復正常之前進行預熱。 我們嘗試使用 Percona 的 buffer-pool-restore 功能來縮短停機時間，但是我們的緩沖池太大了。 我們發現，恢復保存的緩沖池頁面使用的系統資源要比緩慢處理傳入請求的流量要多。 另一個問題：如果發生計劃外的翻轉，我們的異步奴隸將無法恢復。 我們將 binlog 存儲在單獨的，非 DRBD 支持的磁盤上，并禁用了 sync_binlog（由于引入了性能上的損失）。 這種設置意味著我們需要在計劃外翻轉之后從備份中還原異步從屬服務器。 ## 我們喜歡 XtraDB 群集 關于 XtraDB Cluster 的一些事情很突出。 * 不用擁有主動和被動服務器對，我們可以讓 三個 實時服務器在彼此之間同步復制更改。 這將使我們能夠更快地移動連接。 * 由于 XtraDB 群集是多主服務器，因此它使我們可以將流量發送到多臺服務器，從而確保每臺服務器始終具有暖緩沖區。 在 XtraDB 群集中，異步從屬服務器可以將任何節點用作主服務器，并且可以在節點之間移動而不會破壞復制流。 * 群集的自動節點配置非常適合我們現有的自動化。 配置新節點后，我們要做的就是提供另一個節點的地址-新節點將自動接收數據集的副本（并在同步后加入集群）。 ## 我們準備了什么 為 XtraDB Cluster 準備我們的應用程序確實涉及一些新的約束。 其中一些是簡單的 MySQL 調整，大部分對應用程序邏輯是隱藏的，而另一些則是更基本的更改。 在 MySQL 方面： * 我們需要確保僅使用具有主鍵的 InnoDB 表。 * 我們必須確保我們的應用程序不依賴于啟用的查詢緩存（因為集群不支持它）。 * 我們必須從基于語句的復制切換到基于行的復制。 除了這些 MySQL 配置更改（我們能夠在 DRBD 服務器端隔離測試）之外，還需要更改應用程序邏輯： * 我們需要使用分布式鎖定機制，因為 MySQL 鎖定（例如 SELECT FOR UPDATE 語句）對于群集節點而言是本地的。 * 因此，我們用 [Zookeeper](http://zookeeper.apache.org/) 鎖替換了我們的 MySQL 鎖（Zookeeper 已在該系統的其他部分中用于該目的）。 * 考慮到需要將寫入集同步發送到所有節點這一事實，我們更改了進行較大更改的作業（通常是存檔作業）的邏輯，以使用許多較小的事務而不是一個較大的事務。 ## 我們如何處理架構變更 模式更改在 XtraDB 群集中尤其重要。 有兩個選項可用于控制如何在集群中應用架構更改：總訂單隔離（TOI）和滾動架構升級（RSU）。 RSU 允許您單獨升級每個節點，在 DDL 語句運行時從群集中取消該節點的同步，然后重新加入群集。 但是這種方法可能會帶來不穩定性-RSU 無法避免大型表上的架構更改帶來的操作問題（因為它會在 DDL 語句完成之前將寫集緩沖在內存中）。 相比之下， TOI 在所有 集群節點上同時對 應用模式升級，阻塞集群直到更改完成。 我們決定將 TOI 與 Percona 的在線模式更改工具（pt-online-schema-change）一起使用。 它確保任何阻塞操作都很快，因此不會阻塞群集。 ## 遷移過程 建立了 XtraDB Cluster 引入的約束后，我們開始了推廣過程。 首先，我們在生產中建立了一個集群，作為現有 DRBD 數據庫的從屬。 通過使該群集在生產環境中運行并接收所有寫入流量，我們可以開始了解它在實際生產負載下的行為。 我們還設置了指標收集和儀表板來關注集群。 與此同時，我們花了一些時間對測試集群進行負載測試，以量化其相對于現有 DRBD 設置的性能。 運行這些基準測試使我們發現，必須對一些 MySQL 配置進行調整才能獲得我們一直喜歡的性能水平： * 將 innodb_flush_log_at_trx_commit 設置為 0 或 2 可獲得最佳寫入性能（相反，將其設置為 1，則將測試可擴展性限制為只能在我們的測試 VM 上使用 4 個線程）。 由于所有更改都被復制到 3 個節點，因此即使出現單個節點的磁盤一致性寬松的情況，我們也不會丟失任何數據。 * 需要一個大的 innodb_log_file_size 值。 我們最終為生產服務器提供了 1GB 的文件。 在讓我們感到滿意的是 XtraDB Cluster 能夠處理我們的生產負荷之后，我們開始了將其移入生產用途的過程。 首先將所有測試環境切換到群集設置（并針對它們運行負載和故障測試）。 如果集群掛起，我們需要一種方法來快速將我們的系統重新配置為回退到單節點集群。 我們編寫了該過程的腳本，并在負載下對其進行了測試。 實際上，將生產服務器移動到集群是一個多步驟的過程。 我們已經將生產集群設置為現有 DRBD 服務器的從屬服務器，因此我們站起來并從屬另一對 DRBD。 （這臺 DRBD 服務器在那里，以防萬一切換出現嚴重錯誤，我們需要退回到基于 DRBD 的解決方案，幸好我們最終不必這樣做。） 然后，我們將其余的異步從屬設備（災難恢復，備份等）移到了 XtraDB 集群后面。 那些奴隸坐在 XtraDB 集群后面，我們執行了正常的奴隸升級過程，將生產流量轉移到新系統。   ## 實際效果：收益 經過六個多月的生產使用，我們發現在 XtraDB 群集上運行有很多好處： * 我們已經成功執行了生產集群的滾動重啟和升級，而沒有停止生產流量。 * 我們已經使用 pt-online-schema-change 在生產系統上執行了模式修改。 * 我們已經優化了如何處理寫沖突。 XtraDB Cluster 在遇到沖突時會返回死鎖錯誤-即使使用 pt-online-schema-change 執行快速 DDL 語句時也是如此。 沖突導致我們的應用服務器返回 503 響應，負載平衡層將捕獲該響應。 負載平衡器隨后將在另一臺服務器上重試該請求。 ## 現實世界的表現：煩惱 在此過程中，我們還發現了一些令人沮喪的問題： * 某些集群的關鍵狀態計數器是有狀態的，這意味著它們在運行“ SHOW GLOBAL STATUS”后重置為零。 這使得很難監視系統中的關鍵計數器（例如流量控制），這些計數器很少增加，但對于了解系統的行為至關重要。 （但是，此問題已在 XtraDB Cluster 5.6 使用的 Galera 3.x 中修復。） * ActiveRecord 的 MySQL 適配器隱藏了事務語句引發的異常，這些異常在發生寫入集沖突時發生。 （此錯誤已在 Rails 4.1 中修復了 [。）](https://github.com/rails/rails/pull/12779) * 我們還有很多工作要做，以解決服務器不正常的問題。 當前，我們的應用程序服務器連接到本地 HAproxy 實例，該實例將其連接轉發到單個群集節點。 為了進行計劃內的維護，我們在將流量完全分配給另一個群集節點之前，先將其緩慢釋放到另一個群集節點以對其緩沖池進行預熱。 將來，我們計劃切換到完全多主機設置，以確保所有節點都具有熱緩沖池。 很棒的帖子！ 出于好奇，您是否發現具有 RBR 的集群提高了總體交易吞吐量？ 您有可衡量的性能提升嗎？ 在查看 pt-online-schema-change 時，看來基于行的復制格式可能存在一些問題，尤其是在涉及觸發器時（pt-osc 用于確保將更改寫入新的臨時表） 。 這是您必須處理的事情嗎？ http://dev.mysql.com/doc/refman/5.5/en/replication-features-triggers.html ＃1221372 如果服務器是基于行的復制中的從服務器 ，則 pt-online-schema-change 應該會出錯 https://bugs.launchpad.net/percona-toolkit/+bug/1221372 ＃1225577 pt-online-schema-change 可以靜默刪除行 https://bugs.launchpad.net/percona-toolkit/+bug/1225577 對于使用 pxc 的人來說，架構更新過程是什么樣的？ 問候。 集群中有多少數據（大致數字）？ 我正在嘗試將數據遷移到具有非常大的表的類似設置（大約 60 GB）中，并始終使用臨時空間來打不同類型的障礙，并且在使用 mysqldumps 時集群不響應。 舊設置包含一個相當舊的 MySQL 版本。 香港專業教育學院 在為群集提供生產寫入流量之前，我們僅對群集運行人為基準。 這些基準測試表明群集的性能與獨立服務器一樣，但應注意，sysbench 不會強調 RBR 與 SBR 的局限性。 （在單個事務中修改的行數很大） 因為我們的表都沒有使用觸發器，所以我們不需要處理任何觸發器問題。 如果您在表上定義了觸發器，則 pt-osc 將不起作用。 錯誤＃1221372 不會影響我們，因為我們總是在主服務器上運行 pt-osc。 根據操作類型的不同，我們的架構升級會有所不同。 使用 Rails 遷移運行創建/刪除表。 Alter 表是使用 pt-osc 運行的，我們手動插入 Rails 遷移行以將該遷移標記為完成。 什么， 我們的數據庫有幾百個 GB，表的大小各不相同（幾兆最大> 100 GB）。 我還沒有遇到任何有關臨時空間的問題。 對于 mysqldump，也許您遇到流控制問題？ 如果讓 mysqldump 針對群集節點運行并且執行 FTWRL，則由于該節點無法提交掛起的寫集，因此將迅速啟動流控制。 如果要從群集節點提取備份，則需要處理該問題。 您可以在備份期間將節點從群集中取消同步，切換到另一個備份系統（如 xtrabackup），或使用事務進行一致的備份（僅需要 InnoDB 表）。 對于我們來說，我們有一個專用于備份的主機，它是集群的異步從機。 這樣，備份過程帶來的任何額外負擔都不會影響我們的生產集群。 希望有幫助！ Mika, 我們正在運行一個非常相似的系統。 從 Doug 的描述中，聽起來就像他們遵循了 PXC“參考體系結構”一樣。 對我們來說，無論數據集大小如何，它都可以完美地工作。 一些現成的 Web 應用程序不能很好地與 PXC 配合使用，并且其中的大多數約束已在 OP 中列出。 我想在幾點上進行擴展： 1-最新版本支持“更多”查詢緩存，并且可以在啟動配置中對其進行配置。 我們通過在 MySQL 進程啟動后讓操作員將 QC 大小設置為非零來解決早期的限制。 2-臨時 MyISAM 表不復制。 當 DDL 指向其他表時，這將導致在其他節點上記錄錯誤。 它還可以防止依賴臨時表的應用程序擴展到單個節點之外。 3-編碼不正確的應用程序可能會在群集上遇到認證錯誤（沖突），并且不會重試該語句。 可以將自動提交配置為對依賴它的應用程序自動重試。 InnoDB 上的 4- FULLTEXT 索引僅在 5.6 上受支持。 但是 5.6 對我來說似乎還不完全成熟-從 PXC 版本中已修復的錯誤數量來看。 但是至少 Percona 似乎在努力工作。 有一個僅在 5.6 中修復的 bug 擊中了我們，但它本身表現為在群集的滾動更新期間 mysql 進程崩潰，因此該更新僅在零停機時間內回滾。 Percona 很快就解決了這個問題，即使我們不是付費客戶，我也非常滿意他們的溝通（可以為從事 PXC 工作的人員找到聯系信息）。 要回答您的問題（部分是這樣）：Percona 創建了一個出色的工具“ XtraBackup”，可以進行在線備份。 在體驗了 XtraBackup 之后，真的沒有回過 mysqldump 了。 看看，確實沒有與該工具進行備份的比較。 道格， 如果使用 PHP，是否嘗試在客戶端主機上使用 mysqlnd_ms 而不是 HAProxy？ 關于 mysqlnd_ms 的任何評論？ 看起來很有趣，但是我不確定我是否愿意放棄客戶端主機上 HAProxy 提供的穩定性，控制性和可見性。 -V 我們在一個國家/地區中確實有一個 percona Xtra 數據庫集群（Master-Master -Master）設置，而我們希望在其他國家/地區中設置災難恢復設置。請提出一種最佳的實現方法嗎？ 提前致謝！