Facebook擁有世界上最大的MySQL數(shù)據(jù)庫集群，其中包含了成千上萬臺服務器，這些服務器分布在跨越兩個大洲的多個數(shù)據(jù)中心里。
通過幾乎將所有的任務全部自動化，這個集群只有一只非常小的MySQL DBA團隊來進行管理，集群甚至可以自己運行。而實現(xiàn)這種自動化的核心組件之一就是所謂的MPS系統(tǒng)，即“MySQL Pool Scanner”。
MPS是一個大部分用Python寫的復雜狀態(tài)機。它能夠代替DBA執(zhí)行很多例行任務，并且可以讓我們以很少或是不施加人為干預就能執(zhí)行批量維護工作。
單一數(shù)據(jù)庫結點
在Facebook數(shù)以千計的數(shù)據(jù)庫服務器中，每一個都能存儲一定數(shù)量的MySQL實例。一個實例是一個單獨的MySQL進程，以其自身的數(shù)據(jù)集監(jiān)聽著一個單獨的端口。簡單來說，我們假設在圖表和示例中每個服務器正好有兩個實例。
整個數(shù)據(jù)集分割為無數(shù)的shard，并且每個實例都擁有一組這樣的shard，每個都在其自身的數(shù)據(jù)庫Schema里。一個Facebook用戶的信息在其創(chuàng)建的時候會分配給一個shard，這樣每個shard就會包含有成千上萬用戶的相關數(shù)據(jù)。
用一個單一數(shù)據(jù)庫服務器的圖表可以更容易解釋這一點：

每個實例在駐留于不同服務器上的其他實例上都有幾個副本，而這些服務器通常是在不同數(shù)據(jù)中心里的。這樣做主要是為了實現(xiàn)兩個目的：
高可用性：如果一臺服務器宕機了，我們在其他地方還有可用數(shù)據(jù)來提供服務。
性能：不同的地理位置擁有它們自己的副本，這樣便可以使讀取服務本地化。
這里是一個簡單的replica set示意，它的每個服務器都只有一個實例，并且其他實例為空（我們稱這些是spares）：
一個服務器本質上是實例容器，所以現(xiàn)實中的情況可以會變得更為復雜。
例如，一個單一服務器擁有一個主實例也可能擁有一個不同主實例的從實例，像下面這樣：

這里MPS依賴于兩個重要的“building block”操作：
1. 創(chuàng)建一個副本/放置服務器
第一個building block操作是在一臺不同的主機上創(chuàng)建一個實例的副本。我們使用Xtrabackup的修改版本來執(zhí)行大多數(shù)復制操作。如果我們在復制成功完成后移除實例，替代過程也是同樣的操作。
首先，系統(tǒng)為此操作分配一個空閑實例。我們選擇其中一個從實例或主實例并復制其數(shù)據(jù)到新分配的空閑實例。下表顯示了這一替代操作，它在復制完成后將實例移除：
2. 升級主實例
第二個building block操作是將一個不同的實例升級為一個replica set的主實例。
在升級過程中，我們首先選擇一個目標，停止寫入到replica set，將從實例改為從新的主實例進行復制，并恢復寫入。在下圖中演示了一個刪除操作，即在升級成功完成之后舊實例會被丟棄。為簡單起見，下面的replica set只包含三個實例：

這兩個操作對于大多數(shù)使用MySQL的公司來說通常是很復雜的過程，而在Facebook，它不需要人為干預的情況下就已經(jīng)可以由MPS快速而安全的全自動化運行。
主機管理和狀態(tài)
通過上文我們已經(jīng)解決了基本問題，現(xiàn)在可以利用這些building block來探索更為抽象的概念。
MPS會連接到一個存有當前所有數(shù)據(jù)庫主機狀態(tài)和元數(shù)據(jù)的庫，這個庫還包含了當前和過期MPS的復制操作。注冊表是由數(shù)據(jù)庫服務器自身進行管理，因此數(shù)據(jù)庫集群和MPS可與不需要安裝一個復雜的應用服務器。MPS本身實際上是無狀態(tài)的，它在自己的主機池上運行并依賴于上述的庫來進行狀態(tài)管理。而狀態(tài)是分別并行處理的。
當一個服務器在數(shù)據(jù)中心被“喚醒”（連接并配置好一個新的機架），它會每隔幾分鐘運行一個本地代理。此代理會執(zhí)行以下步驟：
收集關于它自身的數(shù)據(jù)。（我在哪里？我有什么硬件？我正在運行什么版本的軟件？）
根據(jù)問題對主機進行分類。（是否是在active的集群中被喚醒的？磁盤運轉是否正常？閃存卡是否正常？）
確保服務器已注冊，核心庫系統(tǒng)中所包含的元數(shù)據(jù)保持最新。
在首次運行中，如果沒有服務器的當前記錄就將服務器上的實例置為初始的“reimage”狀態(tài)。這便是新服務器在MPS中生命的開端。
所以每隔幾分鐘，每臺正常的服務器都會到核心庫“報道”并更新其狀態(tài)，同時同步數(shù)據(jù)使用和系統(tǒng)健康度之類的事項。
目前MPS管理的最小單元就是一個實例。每個實例可以處于不同的狀態(tài)。這些重要狀態(tài)如下所列：
生產(chǎn)狀態(tài)：實例正在服務于生產(chǎn)環(huán)境的流量。
空閑狀態(tài)：實例準備被復制或被分配一些其他工作。
空閑分配狀態(tài)：實例已被選中作為復制的對象，并且復制正在進行中。
空閑解除分配狀態(tài)：.臨時分流狀態(tài)。實例已經(jīng)改從生產(chǎn)環(huán)境移除并等待分流和清理。不會有實例在此狀態(tài)停留很久。
排出狀態(tài)：實例未被使用，而是預留給測試，數(shù)據(jù)中心維護等。需要有人工干預使得主機脫離此狀態(tài)。
重塑（reimage）狀態(tài): 此狀態(tài)下，擁有所有實例的服務器正處在重塑或修復過程中。此狀態(tài)下的服務器會被移交并由一個稱為Windex的協(xié)同系統(tǒng)加以管理。
由于MPS執(zhí)行操作或是人工干預，一個實例可能會在不同狀態(tài)間轉換。以下狀態(tài)表顯示了幾個主要狀態(tài)以及可能讓一個實例在不同狀態(tài)間轉換的操作。

上圖只展示了MPS中一個實例很小一部分的可能采取的路徑。這里所描述的狀態(tài)改變是簡單復制和維護操作的結果。還有很多其他原因可以讓實例改變狀態(tài)，并且將所有操作和檢查都進行硬編碼會讓軟件維護起來變得困難復雜。滿足“問題”是MPS中另一個基本概念。
“問題”是附屬于實例的一個屬性。如果一臺主機上所有的實例都有此問題，那么我們就會認為它是附屬于服務器本身的。另外一種考慮問題的方式類似于標簽。MPS會通過一個決策矩陣來協(xié)助有某個特定問題的實例做出決策。它基本上是一個個元組之間的映射（狀態(tài)，問題）——（行動，狀態(tài)）。
通過具體例子理解起來會更容易一些：
（生產(chǎn)，低空閑）——（替換，空閑解除分配）：用有限空間在生產(chǎn)中替代一個實例，同時將其遷移至一臺不同的服務器。
（空閑解除分配，舊內核）——（遷移，重塑）：如果一個實例在此狀態(tài)發(fā)生遷移，它就不會有生產(chǎn)數(shù)據(jù)，那么為什么不對它進行重塑呢？
（生產(chǎn)，主實例位于撤退位置）——（升級，生產(chǎn)）：我們應該把主實例升級至正確的位置，并將此實例置于生產(chǎn)狀態(tài)。
MPS中不同的狀態(tài)和“問題”使得我們可以創(chuàng)建一個靈活、可維護的基礎設施，用來管理服務器的整個生命周期。
MPS所解決的常見問題
在一個大型數(shù)據(jù)中心中，每天都會有幾十個甚至上百個的服務器故障發(fā)生。下面介紹一些不需要人工干預，MPS就能自行處理的日常故障：
檢測到損壞的從實例并將其禁用，直到它們在后臺被替換。
損壞的主實例降級，這樣正常運行的副本便會取代它們并在后臺進行替換。
服務器上由于增長而耗盡空間的實例會被遷移至未充分使用的服務器。
當數(shù)據(jù)中心中存在成千上萬臺服務器的時候，升級新內核、改變分區(qū)大小或是升級控制器固件的維護工作會變得非常復雜。而對于像是遷移某些框架或是為工程團隊分配測試服務器這些本地化操作也面臨同樣的問題。以下是一個運維人員可以通過單一命令讓MPS執(zhí)行的常見維護操作：
將任意數(shù)量的數(shù)據(jù)庫服務器下架并移出生產(chǎn)環(huán)境。大多數(shù)這樣的操作可以在24小時內完成。
在特定并發(fā)下重塑上萬臺機器（例如執(zhí)行內核升級）。MPS會替代每臺機器然后發(fā)送給Windex。
為一個新項目或測試分配任意數(shù)量的空閑空間。例如想要200臺服務器來運行測試？完全沒問題。
在一個新數(shù)據(jù)中心的特定并發(fā)下，為整個Facebook數(shù)據(jù)集創(chuàng)建副本。
用MPS將基礎任務自動化，這樣可以對我們所管理的服務器進行更好的規(guī)劃，而且還能解放MySQL數(shù)據(jù)庫團隊來讓他們從事更具挑戰(zhàn)的工作。