Facebookでの、MySQL運用の話ですね。
https://www.facebook.com/notes/facebook-engineering/under-the-hood-mysql-pool-scanner-mps/10151750529723920
以下翻訳
Facebookは数多くのMysql database clustersを運用しているプロジェクトの一つだ。
このサーバ群は、2つの大陸にある様々なデータセンターの数千のサーバで構成されている。
小さなチームでこのサイズのclusterを運用することは、DBAがそうするようにclusterが自分自身で走るよう、ほぼすべてを自動化することによって達成される。
その自動化のための1つの仕組みに、私たちがMPS(MySQL Pool Scanner)と呼ぶものがある。
MPSは多くがPythonで書かれたstate machineだ。それはDBAのルーチンワークに変わる物で、人間の介入をなくしてくれる。
クラスターはシングルデータベースノードをみる
数千のサーバの一つ一つはいくつかのMysql Instanceを格納できる。
Instanceは分割されたProcesである。それぞれのデータセットをもち、別のポートで動く。シンプルにするために１つのサーバに２つインスタンスがあると仮定する。
データセットは数千のシャードに分割されている。それぞれのインスタンスはいくつかのシャードを保持している。
Facebookユーザのプロファイルは作成時にいずれかのシャードに割り当てられる。それぞれのシャードは数千のユーザのプロファイルを持つ。
簡単に図を用いて説明する。
すべてのインスタンスは、他のサーバ（通常の場合、他のデータセンター）で持っているデータのコピーをいくつか持っている。
これは２つの目標を達せうするために行われる。
- 高可用性 サーバがダウンした場合。我々はどこかに提供可能なデータを持っている。
- パフォーマンス 地理的に異なる読み込みが近くで行われるように、独自のレプリカを持っている。
これを実現させるための方法は、単純なMySQLのマスター/スレーブだ。すべてのインスタンスはレプリカセットの一部である。レプリカセットは１つのマスタと複数のスレーブを持つ。レプリカセットへのすべての書き込みは、マスターで発生している必要がある。
スレイブは、書き込みイベントがきてすぐにそれらを書き込みストリームに予約する。
マスターとスレーブはほぼ同じデータを持っているので、読み込みはレプリカセットのいずれかに行われる。
次の図は、それぞれが１つのインスタンスをホストし、他のインスタンスは空である。（我々はこれをスペアと呼ぶ。）
サーバーはインスタンスのコンテナであり、実際にはもっと複雑だ。
例えば、マスターインスタンスをホストしているサーバーは、他のマスターのスレイブインスタンスをホストしていることがあります。
次の図は、それぞれが１つのインスタンスをホストし、他のインスタンスは空である。（我々はこれをスペアと呼ぶ。）
例えば、マスターインスタンスをホストしているサーバーは、他のマスターのスレイブインスタンスをホストしていることがあります。
2つの重要な「ビルドブロック」操作にMPSは依存している。
1. サーバ配置、コピー
１つ目の「ビルドブロック」操作は、他のホストにコピーを作成する。我々はもっともパフォーマンスよくコピーをするために、Xtrabackupの改良版を使用している。付け替えは、コピーが完了した後、削除を行うのと同じ作業である。
最初にシステムは、操作のために新しい予備のインスタンスを割り当てます。スレーブまたはマスターを一つ選択し、割り当てられた新しい予備のインスタンスに、データをコピーします。下の図は付け替え作業を示しています。コピーが完了したあと、インスタンスが削除されます。
２つ目のビルディングブロックは、レプリカセット内のインスタンスをマスターに昇格させるアクションである。
昇格の間、昇格させるターゲットをきめて、レプリカセットへの書き込みを止める。新しいマスターからレプリケーションするようにスレイブを変更する。そして書き込みを始める。下記の図では、プロモーション完了後、古いマスターが削除される操作をしめす。単純にするために、レプリカセットは３つのインスタンスのみを含む物とする。
これらの２つの操作は完全に自動化されている。人間の介入無しに、日に100回、1000回実行することができる。
ホストマネジメントと状態
基礎的なところを理解したところで、ビルディングブロックの抽象的概念をみてみよう。
事実、MPS自体はステートレスである。ホスト独自のプールで実行され、状態管理されているリポジトリーを使用して動く。状態は別々に、並列に処理される。
