Facebook擁有世界上最大的MySQL數據庫集群，其中包含了成千上萬臺服務器，這些服務器分布在跨越兩個大洲的多個數據中心里。

通過幾乎將所有的任務全部自動化，這個集群只有一只非常小的MySQL DBA團隊來進行管理，集群甚至可以自己運行。而實現這種自動化的核心組件之一就是所謂的MPS系統，即“MySQL Pool Scanner”。

MPS是一個大部分用Python寫的復雜狀態機。它能夠代替DBA執行很多例行任務，并且可以讓我們以很少或是不施加人為干預就能執行批量維護工作。

單一數據庫結點

在Facebook數以千計的數據庫服務器中，每一個都能存儲一定數量的MySQL實例。一個實例是一個單獨的MySQL進程，以其自身的數據集監聽著一個單獨的端口。簡單來說，我們假設在圖表和示例中每個服務器正好有兩個實例。

整個數據集分割為無數的shard，并且每個實例都擁有一組這樣的shard，每個都在其自身的數據庫Schema里。一個Facebook用戶的信息在其創建的時候會分配給一個shard，這樣每個shard就會包含有成千上萬用戶的相關數據。

用一個單一數據庫服務器的圖表可以更容易解釋這一點：

每個實例在駐留于不同服務器上的其他實例上都有幾個副本，而這些服務器通常是在不同數據中心里的。這樣做主要是為了實現兩個目的：

1. 高可用性：如果一臺服務器宕機了，我們在其他地方還有可用數據來提供服務。
2. 性能：不同的地理位置擁有它們自己的副本，這樣便可以使讀取服務本地化。

這里是一個簡單的replica set示意，它的每個服務器都只有一個實例，并且其他實例為空（我們稱這些是spares）：

一個服務器本質上是實例容器，所以現實中的情況可以會變得更為復雜。

例如，一個單一服務器擁有一個主實例也可能擁有一個不同主實例的從實例，像下面這樣：

這里MPS依賴于兩個重要的“building block”操作：

1. 創建一個副本/放置服務器

第一個building block操作是在一臺不同的主機上創建一個實例的副本。我們使用Xtrabackup的修改版本來執行大多數復制操作。如果我們在復制成功完成后移除實例，替代過程也是同樣的操作。

首先，系統為此操作分配一個空閑實例。我們選擇其中一個從實例或主實例并復制其數據到新分配的空閑實例。下表顯示了這一替代操作，它在復制完成后將實例移除：

2. 升級主實例

第二個building block操作是將一個不同的實例升級為一個replica set的主實例。

在升級過程中，我們首先選擇一個目標，停止寫入到replica set，將從實例改為從新的主實例進行復制，并恢復寫入。在下圖中演示了一個刪除操作，即在升級成功完成之后舊實例會被丟棄。為簡單起見，下面的replica set只包含三個實例：

這兩個操作對于大多數使用MySQL的公司來說通常是很復雜的過程，而在Facebook，它不需要人為干預的情況下就已經可以由MPS快速而安全的全自動化運行。

主機管理和狀態

通過上文我們已經解決了基本問題，現在可以利用這些building block來探索更為抽象的概念。

MPS會連接到一個存有當前所有數據庫主機狀態和元數據的庫，這個庫還包含了當前和過期MPS的復制操作。注冊表是由數據庫服務器自身進行管理，因此數據庫集群和MPS可與不需要安裝一個復雜的應用服務器。MPS本身實際上是無狀態的，它在自己的主機池上運行并依賴于上述的庫來進行狀態管理。而狀態是分別并行處理的。

當一個服務器在數據中心被“喚醒”（連接并配置好一個新的機架），它會每隔幾分鐘運行一個本地代理。此代理會執行以下步驟：

• 收集關于它自身的數據。（我在哪里？我有什么硬件？我正在運行什么版本的軟件？）
• 根據問題對主機進行分類。（是否是在active的集群中被喚醒的？磁盤運轉是否正常？閃存卡是否正常？）
• 確保服務器已注冊，核心庫系統中所包含的元數據保持最新。
• 在首次運行中，如果沒有服務器的當前記錄就將服務器上的實例置為初始的“reimage”狀態。這便是新服務器在MPS中生命的開端。
• 所以每隔幾分鐘，每臺正常的服務器都會到核心庫“報道”并更新其狀態，同時同步數據使用和系統健康度之類的事項。

目前MPS管理的最小單元就是一個實例。每個實例可以處于不同的狀態。這些重要狀態如下所列：

• 生產狀態：實例正在服務于生產環境的流量。
• 空閑狀態：實例準備被復制或被分配一些其他工作。
• 空閑分配狀態：實例已被選中作為復制的對象，并且復制正在進行中。
• 空閑解除分配狀態：.臨時分流狀態。實例已經改從生產環境移除并等待分流和清理。不會有實例在此狀態停留很久。
• 排出狀態：實例未被使用，而是預留給測試，數據中心維護等。需要有人工干預使得主機脫離此狀態。
• 重塑（reimage）狀態: 此狀態下，擁有所有實例的服務器正處在重塑或修復過程中。此狀態下的服務器會被移交并由一個稱為Windex的協同系統加以管理。

由于MPS執行操作或是人工干預，一個實例可能會在不同狀態間轉換。以下狀態表顯示了幾個主要狀態以及可能讓一個實例在不同狀態間轉換的操作。

上圖只展示了MPS中一個實例很小一部分的可能采取的路徑。這里所描述的狀態改變是簡單復制和維護操作的結果。還有很多其他原因可以讓實例改變狀態，并且將所有操作和檢查都進行硬編碼會讓軟件維護起來變得困難復雜。滿足“問題”是MPS中另一個基本概念。

“問題”是附屬于實例的一個屬性。如果一臺主機上所有的實例都有此問題，那么我們就會認為它是附屬于服務器本身的。另外一種考慮問題的方式類似于標簽。MPS會通過一個決策矩陣來協助有某個特定問題的實例做出決策。它基本上是一個個元組之間的映射（狀態，問題）——（行動，狀態）。

通過具體例子理解起來會更容易一些：

• （生產，低空閑）——（替換，空閑解除分配）：用有限空間在生產中替代一個實例，同時將其遷移至一臺不同的服務器。
• （空閑解除分配，舊內核）——（遷移，重塑）：如果一個實例在此狀態發生遷移，它就不會有生產數據，那么為什么不對它進行重塑呢？
• （生產，主實例位于撤退位置）——（升級，生產）：我們應該把主實例升級至正確的位置，并將此實例置于生產狀態。

MPS中不同的狀態和“問題”使得我們可以創建一個靈活、可維護的基礎設施，用來管理服務器的整個生命周期。

MPS所解決的常見問題

在一個大型數據中心中，每天都會有幾十個甚至上百個的服務器故障發生。下面介紹一些不需要人工干預，MPS就能自行處理的日常故障：

• 檢測到損壞的從實例并將其禁用，直到它們在后臺被替換。
• 損壞的主實例降級，這樣正常運行的副本便會取代它們并在后臺進行替換。
• 服務器上由于增長而耗盡空間的實例會被遷移至未充分使用的服務器。

當數據中心中存在成千上萬臺服務器的時候，升級新內核、改變分區大小或是升級控制器固件的維護工作會變得非常復雜。而對于像是遷移某些框架或是為工程團隊分配測試服務器這些本地化操作也面臨同樣的問題。以下是一個運維人員可以通過單一命令讓MPS執行的常見維護操作：

• 將任意數量的數據庫服務器下架并移出生產環境。大多數這樣的操作可以在24小時內完成。
• 在特定并發下重塑上萬臺機器（例如執行內核升級）。MPS會替代每臺機器然后發送給Windex。
• 為一個新項目或測試分配任意數量的空閑空間。例如想要200臺服務器來運行測試？完全沒問題。
• 在一個新數據中心的特定并發下，為整個Facebook數據集創建副本。

用MPS將基礎任務自動化，這樣可以對我們所管理的服務器進行更好的規劃，而且還能解放MySQL數據庫團隊來讓他們從事更具挑戰的工作。

關于作者：Shlomo Priymak是Facebook MySQL運營團隊的DBA。