GitHub，作為廣泛使用的開源代碼庫以及版本控制系統(tǒng)，其數(shù)據(jù)庫MySQL性能的優(yōu)劣對(duì)整個(gè)網(wǎng)站平臺(tái)有著舉足輕重的影響。接下來我們一起跟隨GitHub基礎(chǔ)架構(gòu)團(tuán)隊(duì)的步伐，來重溫去年8月做的一次重大MySQL更新，看是如何使得GitHub運(yùn)行得更暢順的。

任務(wù)簡(jiǎn)述

自去年開始，我們陸續(xù)地把GitHub主體架構(gòu)遷移到新的數(shù)據(jù)中心，與之配套的是世界級(jí)的硬件和網(wǎng)絡(luò)環(huán)境。我們十分希望這次升遷對(duì)后端系統(tǒng)基石MySQL的性能也有所提高。不過在一個(gè)新環(huán)境重新建立一個(gè)新的服務(wù)器集群和硬件平臺(tái)，并不是件輕易的事情，我們必須做好計(jì)劃與測(cè)試，確保遷移工作順利完成。

準(zhǔn)備工作

每當(dāng)要進(jìn)行類似的重大升級(jí)工作，對(duì)每個(gè)測(cè)量和指標(biāo)量度步驟都會(huì)提出嚴(yán)格的要求。為新機(jī)器安裝好操作系統(tǒng)后，接下來需要根據(jù)不同的配置來進(jìn)行測(cè)試。為了得到真實(shí)的負(fù)載測(cè)試數(shù)據(jù)，我們使用了tcpdump對(duì)從舊集群系統(tǒng)到新系統(tǒng)執(zhí)行的SELECT查詢進(jìn)行抓包分析。

MySQL性能調(diào)整可謂是細(xì)節(jié)決定成敗，例如眾所周知的innodb_buffer_pool_size的設(shè)置，對(duì)整體有著舉足輕重的影響。為了盡更全面地管控升級(jí)過程，我們把 innodb_thread_concurrency、innodb_io_capacity、innodb_buffer_pool_instances等參數(shù)也一并進(jìn)行分析和研究。

每次測(cè)試時(shí)我們都只改變某一個(gè)參數(shù)，然后讓系統(tǒng)連續(xù)運(yùn)行至少12小時(shí)。在這過程中不斷觀察SHOW ENGINE INNODB STATUS帶來的統(tǒng)計(jì)信息，其中SEMAPHORES欄目，能很好地反映工作負(fù)荷競(jìng)爭(zhēng)情況。當(dāng)相關(guān)設(shè)置測(cè)試通過后，接下來我們將嘗試把其中一個(gè)最大的數(shù)據(jù)表遷移到一個(gè)單獨(dú)的集群上。作為前期測(cè)試的一部分，這樣的遷移工作能為日后更大更核心的變更帶來指引。

除了對(duì)基礎(chǔ)硬件部分進(jìn)行了升級(jí)，我們還對(duì)流程和拓?fù)溥M(jìn)行了優(yōu)化。例如：延后復(fù)制，更快速和高頻的備份，提高備帶讀取能力。一切就緒后，將進(jìn)入最后的升級(jí)階段。

制定升級(jí)項(xiàng)目清單，進(jìn)行二次檢查

作為每天服務(wù)上百萬用戶的平臺(tái)，任何差錯(cuò)都將是毀滅性的。我們?cè)谶M(jìn)行真實(shí)切換前，列出了一個(gè)任務(wù)清單，確保各項(xiàng)工作有序執(zhí)行：

• 確保緩沖池在新集群中成功預(yù)熱
• 在推特等社交平臺(tái)公告維護(hù)開始
• 把網(wǎng)站轉(zhuǎn)為維護(hù)等待模式
• 等候所有與舊MySQL服務(wù)器相關(guān)的通信終止
• 把舊服務(wù)器設(shè)為只讀模式
• 從舊集群中移除主要和復(fù)制的VIPs數(shù)據(jù)
• 確認(rèn)所有寫入操作已經(jīng)終止
• 終止cluster1的復(fù)制
• 獲取cluster1復(fù)制的位置，并告知當(dāng)前線程
• 重置cluster1的復(fù)制
• 關(guān)閉cluster1的只讀模式
• 把舊集群連接到新的cluster1集群
• 按照cluster1連接配置進(jìn)行應(yīng)用程式部署
• 確保新連接能通過新集群
• 檢查后臺(tái)工具resque的任務(wù)(workers)
• 進(jìn)行階段檢查并確保一切正常
• 把網(wǎng)站轉(zhuǎn)為正常模式
• 在推特等社交平臺(tái)公告維護(hù)結(jié)束
• 把https://github.com/github/xxxx/pull/xxx整合到主頁面

遷移當(dāng)天

在周六的上午5點(diǎn)太平洋時(shí)間)，團(tuán)隊(duì)成員就位后，遷移工作正式開始。當(dāng)用戶在這段時(shí)間訪問網(wǎng)站時(shí)，會(huì)收到如下的提示：

13分鐘后，新集群即將開始正常運(yùn)作。我們終止了網(wǎng)站的維護(hù)模式，并告知大眾網(wǎng)站將回復(fù)正常。

效果評(píng)估

在接下來的幾個(gè)星期，我們密切關(guān)注了整體性能和響應(yīng)時(shí)間方面的變化。結(jié)果是令人欣喜的，頁面載入時(shí)間減少了將近三分之二：

經(jīng)驗(yàn)總結(jié)：

1. 功能劃分

在本次操作中，我們把較大的歷史數(shù)據(jù)記錄表放入單獨(dú)的集群，事后證明這是明智的做法—很好地釋放了存儲(chǔ)空間和緩沖池空間。同時(shí)，能夠把更多資源放在活躍數(shù)據(jù)處理上，連接邏輯的劃分也使得程序可以在多個(gè)集群間進(jìn)行查詢。以后我們還將采取該方法進(jìn)行升級(jí)。

2. 不斷測(cè)試

羅馬非一天建成，整個(gè)過程需要不斷進(jìn)行驗(yàn)收和回歸測(cè)試，避免意外的發(fā)生。

3. 團(tuán)隊(duì)的力量

如此重大的架構(gòu)升級(jí)需要很多小伙伴協(xié)力工作，我們主要使用GitHub上的拉請(qǐng)求功能來進(jìn)行互動(dòng)交流。部署團(tuán)隊(duì)來自世界各地：

當(dāng)開啟一個(gè)拉請(qǐng)求后，我們將進(jìn)行實(shí)時(shí)交流，例如：錯(cuò)誤處理，回歸處理等信息的交流。每個(gè)交流環(huán)節(jié)都生成一個(gè)URL，方便進(jìn)行歷史查詢和反饋。

一年后……

路遙知馬力，一年后，實(shí)踐證明這是一次成功的操作。MySQL持續(xù)表現(xiàn)符合預(yù)期，系統(tǒng)可靠性進(jìn)一步提高。還有個(gè)附加好處是：新系統(tǒng)的擴(kuò)展性得到提升，將來可進(jìn)行更大規(guī)模的升級(jí)和改造。

原文鏈接：http://www.csdn.net/article/2014-09-08/2821581-GitHub-MySQL