GitHub，作為廣泛使用的開源代碼庫以及版本控制系統，其數據庫MySQL性能的優劣對整個網站平臺有著舉足輕重的影響。接下來我們一起跟隨GitHub基礎架構團隊的步伐，來重溫去年8月做的一次重大MySQL更新，看是如何使得GitHub運行得更暢順的。

任務簡述

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

準備工作

每當要進行類似的重大升級工作，對每個測量和指標量度步驟都會提出嚴格的要求。為新機器安裝好操作系統后，接下來需要根據不同的配置來進行測試。為了得到真實的負載測試數據，我們使用了tcpdump對從舊集群系統到新系統執行的SELECT查詢進行抓包分析。

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

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

除了對基礎硬件部分進行了升級，我們還對流程和拓撲進行了優化。例如：延后復制，更快速和高頻的備份，提高備帶讀取能力。一切就緒后，將進入最后的升級階段。

制定升級項目清單，進行二次檢查

作為每天服務上百萬用戶的平臺，任何差錯都將是毀滅性的。我們在進行真實切換前，列出了一個任務清單，確保各項工作有序執行：

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

遷移當天

在周六的上午5點太平洋時間)，團隊成員就位后，遷移工作正式開始。當用戶在這段時間訪問網站時，會收到如下的提示：

13分鐘后，新集群即將開始正常運作。我們終止了網站的維護模式，并告知大眾網站將回復正常。

效果評估

在接下來的幾個星期，我們密切關注了整體性能和響應時間方面的變化。結果是令人欣喜的，頁面載入時間減少了將近三分之二：

經驗總結：

1. 功能劃分

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

2. 不斷測試

羅馬非一天建成，整個過程需要不斷進行驗收和回歸測試，避免意外的發生。

3. 團隊的力量

如此重大的架構升級需要很多小伙伴協力工作，我們主要使用GitHub上的拉請求功能來進行互動交流。部署團隊來自世界各地：

當開啟一個拉請求后，我們將進行實時交流，例如：錯誤處理，回歸處理等信息的交流。每個交流環節都生成一個URL，方便進行歷史查詢和反饋。

一年后……

路遙知馬力，一年后，實踐證明這是一次成功的操作。MySQL持續表現符合預期，系統可靠性進一步提高。還有個附加好處是：新系統的擴展性得到提升，將來可進行更大規模的升級和改造。

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