[[205691]]

我們 MySQL 數(shù)據(jù)庫基礎(chǔ)架構(gòu)是 Github 關(guān)鍵組件。 MySQL 提供 Github.com、 GitHub 的 API 和驗(yàn)證等等的服務(wù)。每一次的 git 請(qǐng)求都以某種方式觸及 MySQL。我們的任務(wù)是保持?jǐn)?shù)據(jù)的可用性，并保持其完整性。即使我們 MySQL 集群是按流量分配的，但是我們還是需要執(zhí)行深度清理、即時(shí)更新、在線模式schema遷移、集群拓?fù)渲貥?gòu)、連接池化pooling和負(fù)載平衡等任務(wù)。 我們建有基礎(chǔ)架構(gòu)來自動(dòng)化測(cè)試這些操作，在這篇文章中，我們將分享幾個(gè)例子，來說明我們是如何通過持續(xù)測(cè)試打造我們的基礎(chǔ)架構(gòu)的。這是讓我們一夢(mèng)到天亮的根本保障。

備份

沒有比備份數(shù)據(jù)更重要的了，如果您沒有備份數(shù)據(jù)庫，在它出事前這可能并不是什么問題。Percona 的 Xtrabackup 是我們一直用來完整備份 MySQL 數(shù)據(jù)庫的工具。如果有專門需要備份的數(shù)據(jù)，我們就會(huì)備份到另一個(gè)專門備份數(shù)據(jù)的服務(wù)器上。

除了完整的二進(jìn)制備份外，我們每天還會(huì)多次運(yùn)行邏輯備份。這些備份數(shù)據(jù)可以讓我們的工程師獲取到***的數(shù)據(jù)副本。有時(shí)候，他們希望從表中獲取一整套數(shù)據(jù)，以便他們可以在一個(gè)生產(chǎn)級(jí)規(guī)模的表上測(cè)試索引的修改，或查看特定時(shí)間以來的數(shù)據(jù)。Hubot 可以讓我們恢復(fù)備份的表，并且當(dāng)表準(zhǔn)備好使用時(shí)會(huì)通知我們。

tomkrouper

.mysql backup-list locations 

Hubot

+-----------+------------+---------------+---------------------+---------------------+----------------------------------------------+ 
| Backup ID | Table Name | Donor Host    | Backup Start        | Backup End          | File Name                                    | 
+-----------+------------+---------------+---------------------+---------------------+----------------------------------------------+ 
|   1699494 | locations  | db-mysql-0903 | 2017-07-01 22:09:17 | 2017-07-01 22:09:17 | backup-mycluster-locations-1498593122.sql.gz | 
|   1699133 | locations  | db-mysql-0903 | 2017-07-01 16:11:37 | 2017-07-01 16:11:39 | backup-mycluster-locations-1498571521.sql.gz | 
|   1698772 | locations  | db-mysql-0903 | 2017-07-01 10:09:21 | 2017-07-01 10:09:22 | backup-mycluster-locations-1498549921.sql.gz | 
|   1698411 | locations  | db-mysql-0903 | 2017-07-01 04:12:32 | 2017-07-01 04:12:32 | backup-mycluster-locations-1498528321.sql.gz | 
|   1698050 | locations  | db-mysql-0903 | 2017-06-30 22:18:23 | 2017-06-30 22:18:23 | backup-mycluster-locations-1498506721.sql.gz | 
| ... 
|   1262253 | locations  | db-mysql-0088 | 2016-08-01 01:58:51 | 2016-08-01 01:58:54 | backup-mycluster-locations-1470034801.sql.gz | 
|   1064984 | locations  | db-mysql-0088 | 2016-04-04 13:07:40 | 2016-04-04 13:07:43 | backup-mycluster-locations-1459494001.sql.gz | 
+-----------+------------+---------------+---------------------+---------------------+----------------------------------------------+ 

tomkrouper

.mysql restore 1699133 

Hubot

A restore job has been created for the backup job 1699133. You will be notified in #database-ops when the restore is complete. 

Hubot

@tomkrouper: the locations table has been restored as locations_2017_07_01_16_11 in the restores database on db-mysql-0482 

數(shù)據(jù)被加載到非生產(chǎn)環(huán)境的數(shù)據(jù)庫，該數(shù)據(jù)庫可供請(qǐng)求該次恢復(fù)的工程師訪問。

我們保留數(shù)據(jù)的“備份”的***一個(gè)方法是使用延遲副本delayed replica。這與其說是備份，不如說是保護(hù)。對(duì)于每個(gè)生產(chǎn)集群，我們有一個(gè)延遲 4 個(gè)小時(shí)復(fù)制的主機(jī)。如果運(yùn)行了一個(gè)不該運(yùn)行的請(qǐng)求，我們可以在 chatops 中運(yùn)行 mysql panic 。這將導(dǎo)致我們所有的延遲副本立即停止復(fù)制。這也將給值班 DBA 發(fā)送消息。從而我們可以使用延遲副本來驗(yàn)證是否有問題，并快速前進(jìn)到二進(jìn)制日志的錯(cuò)誤發(fā)生之前的位置。然后，我們可以將此數(shù)據(jù)恢復(fù)到主服務(wù)器，從而恢復(fù)數(shù)據(jù)到該時(shí)間點(diǎn)。

備份固然好，但如果發(fā)生了一些未知或未捕獲的錯(cuò)誤破壞它們，它們就沒有價(jià)值了。讓腳本恢復(fù)備份的好處是它允許我們通過 cron 自動(dòng)執(zhí)行備份驗(yàn)證。我們?yōu)槊總€(gè)集群設(shè)置了一個(gè)專用的主機(jī)，用于運(yùn)行***備份的恢復(fù)。這樣可以確保備份運(yùn)行正常，并且我們能夠從備份中檢索數(shù)據(jù)。

根據(jù)數(shù)據(jù)集大小，我們每天運(yùn)行幾次恢復(fù)。恢復(fù)的服務(wù)器被加入到復(fù)制工作流，并通過復(fù)制保持?jǐn)?shù)據(jù)更新。這測(cè)試不僅讓我們得到了可恢復(fù)的備份，而且也讓我們得以正確地確定備份的時(shí)間點(diǎn)，并且可以從該時(shí)間點(diǎn)進(jìn)一步應(yīng)用更改。如果恢復(fù)過程中出現(xiàn)問題，我們會(huì)收到通知。

我們還追蹤恢復(fù)所需的時(shí)間，所以我們知道在緊急情況下建立新的副本或還原需要多長(zhǎng)時(shí)間。

以下是由 Hubot 在我們的機(jī)器人聊天室中輸出的自動(dòng)恢復(fù)過程。

Hubot

gh-mysql-backup-restore: db-mysql-0752: restore_log.id = 4447  
gh-mysql-backup-restore: db-mysql-0752: Determining backup to restore for cluster 'prodcluster'.  
gh-mysql-backup-restore: db-mysql-0752: Enabling maintenance mode  
gh-mysql-backup-restore: db-mysql-0752: Setting orchestrator downtime  
gh-mysql-backup-restore: db-mysql-0752: Disabling Puppet  
gh-mysql-backup-restore: db-mysql-0752: Stopping MySQL  
gh-mysql-backup-restore: db-mysql-0752: Removing MySQL files  
gh-mysql-backup-restore: db-mysql-0752: Running gh-xtrabackup-restore  
gh-mysql-backup-restore: db-mysql-0752: Restore file: xtrabackup-notify-2017-07-02_0000.xbstream  
gh-mysql-backup-restore: db-mysql-0752: Running gh-xtrabackup-prepare  
gh-mysql-backup-restore: db-mysql-0752: Starting MySQL  
gh-mysql-backup-restore: db-mysql-0752: Update file ownership  
gh-mysql-backup-restore: db-mysql-0752: Upgrade MySQL  
gh-mysql-backup-restore: db-mysql-0752: Stopping MySQL  
gh-mysql-backup-restore: db-mysql-0752: Starting MySQL  
gh-mysql-backup-restore: db-mysql-0752: Backup Host: db-mysql-0034  
gh-mysql-backup-restore: db-mysql-0752: Setting up replication  
gh-mysql-backup-restore: db-mysql-0752: Starting replication  
gh-mysql-backup-restore: db-mysql-0752: Replication catch-up  
gh-mysql-backup-restore: db-mysql-0752: Restore complete (replication running)  
gh-mysql-backup-restore: db-mysql-0752: Enabling Puppet  
gh-mysql-backup-restore: db-mysql-0752: Disabling maintenance mode  
gh-mysql-backup-restore: db-mysql-0752: Setting orchestrator downtime  
gh-mysql-backup-restore: db-mysql-0752: Restore process complete.  

還有一件我們可以使用備份做的事情是向一組現(xiàn)有的 MySQL 服務(wù)器添加一個(gè)新的副本。我們初始化一個(gè)新的服務(wù)器，一旦我們得知它準(zhǔn)備就緒，我們就可以開始恢復(fù)該特定集群的***備份。我們有一個(gè)腳本，可以運(yùn)行所有需要手動(dòng)執(zhí)行的恢復(fù)命令。我們的自動(dòng)恢復(fù)系統(tǒng)基本上使用的是相同的腳本。這簡(jiǎn)化了系統(tǒng)構(gòu)建過程，并允許我們?cè)谝粋€(gè)啟動(dòng)運(yùn)行的主機(jī)上使用幾個(gè)對(duì)話命令(chatops)來替代一堆手動(dòng)執(zhí)行命令。下面顯示的是在該對(duì)話(chatops)中手動(dòng)執(zhí)行的恢復(fù)：

jessbreckenridge

.mysql backup-restore -H db-mysql-0007 -o -r magic_word=daily_rotating_word 

Hubot

@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Determining backup to restore for cluster 'mycluster'.  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: restore_log.id = 4449  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Enabling maintenance mode 
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Setting orchestrator downtime  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Disabling Puppet  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Stopping MySQL  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Removing MySQL files  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Running gh-xtrabackup-restore  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Restore file: xtrabackup-mycluster-2017-07-02_0015.xbstream  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Running gh-xtrabackup-prepare  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Update file ownership  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Starting MySQL  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Upgrade MySQL  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Stopping MySQL  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Starting MySQL  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Setting up replication  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Starting replication  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Backup Host: db-mysql-0201  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Replication catch-up  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Replication behind by 4589 seconds, waiting 1800 seconds before next check.  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Restore complete (replication running)  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Enabling puppet  
@jessbreckenridge gh-mysql-backup-restore: db-mysql-0007: Disabling maintenance mode  

故障轉(zhuǎn)移

我們使用協(xié)調(diào)器 來為主服務(wù)器master和中間服務(wù)器intermediate master執(zhí)行自動(dòng)化故障切換。我們期望協(xié)調(diào)器orchestrator能夠正確檢測(cè)主服務(wù)器故障，指定一個(gè)副本進(jìn)行晉升，在所指定的副本下修復(fù)拓?fù)?，完成晉升。我們預(yù)期 VIP(虛擬 IP)、連接池可以相應(yīng)地進(jìn)行變化、客戶端進(jìn)行重連、puppet 在晉升后的主服務(wù)器上運(yùn)行基本組件等等。故障轉(zhuǎn)移是一項(xiàng)復(fù)雜的任務(wù)，涉及到我們基礎(chǔ)架構(gòu)的許多方面。

為了建立對(duì)我們的故障轉(zhuǎn)移的信賴，我們建立了一個(gè)類生產(chǎn)環(huán)境的測(cè)試集群，并且我們不斷地崩潰它來觀察故障轉(zhuǎn)移情況。

這個(gè)類生產(chǎn)環(huán)境的測(cè)試集群是一套復(fù)制環(huán)境，與我們的生產(chǎn)集群的各個(gè)方面都相同：硬件類型、操作系統(tǒng)、MySQL 版本、網(wǎng)絡(luò)環(huán)境、VIP、puppet 配置、haproxy 設(shè)置 等。與生產(chǎn)集群唯一不同的是它不發(fā)送/接收生產(chǎn)流量。

我們?cè)跍y(cè)試集群上模擬寫入負(fù)載，同時(shí)避免復(fù)制滯后。寫入負(fù)載不會(huì)太大，但是有一些有意地寫入相同數(shù)據(jù)集的競(jìng)爭(zhēng)請(qǐng)求。這在正常情況下并不是很有用，但是事實(shí)證明這在故障轉(zhuǎn)移中是有用的，我們將會(huì)稍后簡(jiǎn)要描述它。

我們的測(cè)試集群有來自三個(gè)數(shù)據(jù)中心的典型的服務(wù)器。我們希望故障轉(zhuǎn)移能夠從同一個(gè)數(shù)據(jù)中心內(nèi)晉升替代副本。我們希望在這樣的限制下盡可能多地恢復(fù)副本。我們要求盡可能地實(shí)現(xiàn)這兩者。協(xié)調(diào)器對(duì)拓?fù)浣Y(jié)構(gòu)沒有先驗(yàn)假定prior assumption;它必須依據(jù)崩潰時(shí)的狀態(tài)作出反應(yīng)。

然而，我們有興趣創(chuàng)建各種復(fù)雜而多變的故障恢復(fù)場(chǎng)景。我們的故障轉(zhuǎn)移測(cè)試腳本為故障轉(zhuǎn)移提供了基礎(chǔ)：

• 它能夠識(shí)別現(xiàn)有的主服務(wù)器
• 它能夠重構(gòu)拓?fù)浣Y(jié)構(gòu)，來代表主服務(wù)器下的所有的三個(gè)數(shù)據(jù)中心。不同的數(shù)據(jù)中心具有不同的網(wǎng)絡(luò)延遲，并且預(yù)期會(huì)在不同的時(shí)間對(duì)主機(jī)崩潰做出反應(yīng)。
• 能夠選擇崩潰方式?？梢赃x擇干掉主服務(wù)器(kill -9)或網(wǎng)絡(luò)隔離(比較好的方式： iptables -j REJECT 或無響應(yīng)的方式： iptables -j DROP)方式。

腳本通過選擇的方法使主機(jī)崩潰，并等待協(xié)調(diào)器可靠地檢測(cè)到崩潰然后執(zhí)行故障轉(zhuǎn)移。雖然我們期望檢測(cè)和晉升在 30 秒鐘內(nèi)完成，但腳本會(huì)稍微放寬這一期望，并在查找故障轉(zhuǎn)移結(jié)果之前休眠一段指定的時(shí)間。然后它將檢查：

• 一個(gè)新的(不同的)主服務(wù)器是否到位
• 集群中有足夠的副本
• 主服務(wù)器是可寫的
• 對(duì)主服務(wù)器的寫入在副本上可見
• 內(nèi)部服務(wù)發(fā)現(xiàn)項(xiàng)已更新(如預(yù)期般識(shí)別到新的主服務(wù)器;移除舊的主服務(wù)器)
• 其他內(nèi)部檢查

這些測(cè)試可以證實(shí)故障轉(zhuǎn)移是成功的，不僅是 MySQL 級(jí)別的，而是在更大的基礎(chǔ)設(shè)施范圍內(nèi)成功的。VIP 被賦予;特定的服務(wù)已經(jīng)啟動(dòng);信息到達(dá)了應(yīng)該去的地方。

該腳本進(jìn)一步繼續(xù)恢復(fù)那個(gè)失敗的服務(wù)器：

• 從備份恢復(fù)它，從而隱含地測(cè)試了我們的備份/恢復(fù)過程
• 驗(yàn)證服務(wù)器配置是否符合預(yù)期(該服務(wù)器不再認(rèn)為其是主服務(wù)器)
• 將其加入到復(fù)制集群，期望找到在主服務(wù)器上寫入的數(shù)據(jù)

看一下以下可視化的計(jì)劃的故障轉(zhuǎn)移測(cè)試：從運(yùn)行良好的群集，到在某些副本上發(fā)現(xiàn)問題，診斷主服務(wù)器(7136)是否死機(jī)，選擇一個(gè)服務(wù)器(a79d)來晉升，重構(gòu)該服務(wù)器下的拓?fù)?，晉升它(故障切換成功)，恢復(fù)失敗的(原)主服務(wù)器并將其放回群集。

automated master failover

測(cè)試失敗怎么樣?

我們的測(cè)試腳本使用了一種“停止世界”的方法。任何故障切換組件中的單個(gè)故障都將導(dǎo)致整個(gè)測(cè)試失敗，因此在有人解決該問題之前，無法進(jìn)行任何進(jìn)一步的自動(dòng)化測(cè)試。我們會(huì)得到警報(bào)，并檢查狀態(tài)和日志進(jìn)行處理。

腳本將各種情況下失敗，如不可接受的檢測(cè)或故障轉(zhuǎn)移時(shí)間;備份/還原出現(xiàn)問題;失去太多服務(wù)器;在故障切換后的意外配置等等。

我們需要確保協(xié)調(diào)器正確地連接服務(wù)器。這是競(jìng)爭(zhēng)性寫入負(fù)載有用的地方：如果設(shè)置不正確，復(fù)制很容易中斷。我們會(huì)得到 DUPLICATE KEY 或其他錯(cuò)誤提示出錯(cuò)。

這是特別重要的，因此我們改進(jìn)協(xié)調(diào)器并引入新的行為，以允許我們?cè)诎踩沫h(huán)境中測(cè)試這些變化。

出現(xiàn)：混亂測(cè)試

上面所示的測(cè)試程序?qū)⒉东@(并已經(jīng)捕獲)我們基礎(chǔ)設(shè)施許多部分的問題。這些夠了嗎?

在生產(chǎn)環(huán)境中總是有其他的東西。有些特定測(cè)試方法不適用于我們的生產(chǎn)集群。它們不具有相同的流量和流量方式，也不具有完全相同的服務(wù)器集。故障類型可能有所不同。

我們正在為我們的生產(chǎn)集群設(shè)計(jì)混亂測(cè)試。 混亂測(cè)試將會(huì)在我們的生產(chǎn)中，但是按照預(yù)期的時(shí)間表和充分控制的方式來逐個(gè)破壞我們的部分生產(chǎn)環(huán)境。 混亂測(cè)試在恢復(fù)機(jī)制中引入更高層次的信賴，并影響(因此測(cè)試)我們的基礎(chǔ)設(shè)施和應(yīng)用程序的更大部分。

這是微妙的工作：當(dāng)我們承認(rèn)需要混亂測(cè)試時(shí)，我們也希望可以避免對(duì)我們的服務(wù)造成不必要的影響。不同的測(cè)試將在風(fēng)險(xiǎn)級(jí)別和影響方面有所不同，我們將努力確保我們的服務(wù)的可用性。

模式遷移

我們使用 gh-ost來運(yùn)行實(shí)時(shí)模式遷移schema migration。gh-ost 是穩(wěn)定的，但也處于活躍開發(fā)中，重大新功能正在不斷開發(fā)和計(jì)劃中。

gh-ost 通過將數(shù)據(jù)復(fù)制到 ghost 表來遷移，將由二進(jìn)制日志攔截的進(jìn)一步更改應(yīng)用到 ghost 表中，就如其正在寫入原始表。然后它將 ghost 表交換代替原始表。遷移完成時(shí)，GitHub 繼續(xù)使用由 gh-ost 生成和填充的表。

在這個(gè)時(shí)候，幾乎所有的 GitHub 的 MySQL 數(shù)據(jù)都被 gh-ost 重新創(chuàng)建，其中大部分重新創(chuàng)建多次。我們必須高度信賴 gh-ost，讓它一遍遍地操弄我們的數(shù)據(jù)，即使它還處于活躍開發(fā)中。下面是我們?nèi)绾潍@得這種信賴的。

gh-ost 提供生產(chǎn)環(huán)境測(cè)試能力。它支持在副本上運(yùn)行遷移，其方式與在主服務(wù)器上運(yùn)行的方式大致相同： gh-ost 將連接到副本，并將其視為主服務(wù)器。它將采用與實(shí)際主機(jī)遷移相同的方式解析其二進(jìn)制日志。但是，它將復(fù)制行并將二進(jìn)制日志事件應(yīng)用于副本，并避免對(duì)主服務(wù)器進(jìn)行寫入。

我們?cè)谏a(chǎn)環(huán)境中給 gh-ost 提供專用的副本。這些副本并不為生產(chǎn)環(huán)境提供服務(wù)。每個(gè)這樣的副本將檢索生產(chǎn)表的當(dāng)前列表，并以隨機(jī)順序?qū)ζ溥M(jìn)行迭代。一個(gè)接一個(gè)地選擇一個(gè)表并在該表上執(zhí)行復(fù)制遷移。遷移實(shí)際上并不修改表結(jié)構(gòu)，而是運(yùn)行一個(gè)微不足道的 ENGINE=InnoDB 更改。該測(cè)試運(yùn)行遷移時(shí)，如果表正在生產(chǎn)環(huán)境中使用，會(huì)復(fù)制實(shí)際的生產(chǎn)數(shù)據(jù)，并接受二進(jìn)制日志之外的真實(shí)的生產(chǎn)環(huán)境流量。

這些遷移可以被審計(jì)。以下是我們?nèi)绾螐膶?duì)話中(chatops)檢查運(yùn)行中的測(cè)試狀態(tài)：

ggunson

.migration test-status 

Hubot

# Migrating `prod`.`pull_requests`; Ghost table is `prod`.`_pull_requests_gho` 
# Migrating ghost-db-mysql-0007:3306; inspecting ghost-db-mysql-0007:3306; executing on ghost-db-mysql-0007 
# Migration started at Mon Jan 30 02:13:39 -0800 2017 
# chunk-size: 2500; max-lag-millis: 1500ms; max-load: Threads_running=30; critical-load: Threads_running=1000; nice-ratio: 0.000000 
# throttle-additional-flag-file: /tmp/gh-ost.throttle 
# panic-flag-file: /tmp/ghost-test-panic.flag 
# Serving on unix socket: /tmp/gh-ost.test.sock 
Copy: 57992500/86684838 66.9%; Applied: 57708; Backlog: 1/100; Time: 3h28m38s(total), 3h28m36s(copy); streamer: mysql-bin.000576:142993938; State: migrating; ETA: 1h43m12s 

當(dāng)測(cè)試遷移完成表數(shù)據(jù)的復(fù)制時(shí)，它將停止復(fù)制并執(zhí)行切換，使用 ghost 表替換原始表，然后交換回來。我們對(duì)實(shí)際替換數(shù)據(jù)并不感興趣。相反，我們將留下原始的表和 ghost 表，它們應(yīng)該是相同的。我們通過校驗(yàn)兩個(gè)表的整個(gè)表數(shù)據(jù)來驗(yàn)證。

測(cè)試能以下列方式完成：

• 成功 ：一切順利，校驗(yàn)和相同。我們期待看到這一結(jié)果。
• 失敗 ：執(zhí)行問題。這可能偶爾發(fā)生，因?yàn)檫w移進(jìn)程被殺死、復(fù)制問題等，并且通常與 gh-ost 自身無關(guān)。
• 校驗(yàn)失敗 ：表數(shù)據(jù)不一致。對(duì)于被測(cè)試的分支，這個(gè)需要修復(fù)。對(duì)于正在進(jìn)行的 master 分支測(cè)試，這意味著立即阻止生產(chǎn)遷移。我們不會(huì)遇到后者。

測(cè)試結(jié)果經(jīng)過審核，發(fā)送到機(jī)器人聊天室，作為事件發(fā)送到我們的度量系統(tǒng)。下圖中的每條垂直線代表成功的遷移測(cè)試:

automated master failover

這些測(cè)試不斷運(yùn)行。如果發(fā)生故障，我們會(huì)收到通知。當(dāng)然，我們可以隨時(shí)訪問機(jī)器人聊天室(chatops)，了解發(fā)生了什么。

測(cè)試新版本

我們不斷改進(jìn) gh-ost。我們的開發(fā)流程基于 git 分支，然后我們通過拉取請(qǐng)求(PR)來提供合并。

提交的 gh-ost 拉取請(qǐng)求(PR)通過持續(xù)集成(CI)進(jìn)行基本的編譯和單元測(cè)試。一旦通過，該 PR 在技術(shù)上就有資格合并，但更好的是它有資格通過 Heaven 進(jìn)行部署。作為我們基礎(chǔ)架構(gòu)中的敏感組件，在其進(jìn)入 master 分支前，我們會(huì)小心部署分支進(jìn)行密集測(cè)試。

shlomi-noach

.deploy gh-ost/fix-reappearing-throttled-reasons to prod/ghost-db-mysql-0007 

Hubot

@shlomi-noach is deploying gh-ost/fix-reappearing-throttled-reasons (baee4f6) to production (ghost-db-mysql-0007).  
@shlomi-noach's production deployment of gh-ost/fix-reappearing-throttled-reasons (baee4f6) is done! (2s)  
@shlomi-noach, make sure you watch for exceptions in haystack 

jonahberquist

.deploy gh-ost/interactive-command-question to prod/ghost-db-mysql-0012 

Hubot

@jonahberquist is deploying gh-ost/interactive-command-question (be1ab17) to production (ghost-db-mysql-0012).  
@jonahberquist's production deployment of gh-ost/interactive-command-question (be1ab17) is done! (2s)  
@jonahberquist, make sure you watch for exceptions in haystack 

shlomi-noach

.wcid gh-ost 

Hubot

shlomi-noach testing fix-reappearing-throttled-reasons 41 seconds ago: ghost-db-mysql-0007  
jonahberquist testing interactive-command-question 7 seconds ago: ghost-db-mysql-0012  
Nobody is in the queue. 

一些 PR 很小，不影響數(shù)據(jù)本身。對(duì)狀態(tài)消息，交互式命令等的更改對(duì) gh-ost 應(yīng)用程序的影響較小。而其他的 PR 對(duì)遷移邏輯和操作會(huì)造成重大變化，我們將嚴(yán)格測(cè)試這些，通過我們的生產(chǎn)表車隊(duì)運(yùn)行這些，直到其滿足了這些改變不會(huì)造成數(shù)據(jù)損壞威脅的程度。

總結(jié)

在整個(gè)測(cè)試過程中，我們建立對(duì)我們的系統(tǒng)的信賴。通過自動(dòng)化這些測(cè)試，在生產(chǎn)環(huán)境中，我們得到了一切都按預(yù)期工作的反復(fù)確認(rèn)。隨著我們繼續(xù)發(fā)展我們的基礎(chǔ)設(shè)施，我們還通過調(diào)整測(cè)試來覆蓋***的變化。

產(chǎn)品總會(huì)有令你意想不到的未被測(cè)試覆蓋的場(chǎng)景。我們對(duì)生產(chǎn)環(huán)境的測(cè)試越多，我們對(duì)應(yīng)用程序的期望越多，基礎(chǔ)設(shè)施的能力就越強(qiáng)。