SolrCloudのリーダー選出の仕組み

はじめに

SolrCloudではコレクションを複数のシャードに分け、各シャードを複数のレプリカによる冗長構成にできます。レプリカの中から1台リーダーが選出されてインデックス更新更新の責任を持ちます。
旧来のマスタースレーブの構成では、マスターがダウンしたときには復旧するまでは更新処理が停止してしまいますが、SolrCloudではリーダーがダウンした場合には自動的に別のレプリカがリーダーに選出されてなるべく更新処理が停止しないように工夫されています。
この記事では、リーダー選出の仕組みを解説します。

リーダー選出の仕組み

リファレンスでは以下のように説明されています。

SolrCloud にはマスターもスレーブもありません。その代わりに各シャードは最低1台の物理的レプリカから構成され、その中の1台がリーダーとなります。
リーダーは自動的に選出されます。最初は先着順で、以後は
http://zookeeper.apache.org/doc/r3.5.5/recipes.html#sc_leaderElection
に記述されている ZooKeeper を使った手順に基づきます。

リーダー選出の手続きは org.apache.solr.cloud.LeaderElector クラスで実装されています。このクラスのコメントでもリーダー選出の仕組みについて触れられています。

これらのドキュメントとコードを参考に、リーダー選出の仕組みをまとめました

• 冗長構成においては各レプリカが同じ状態を持つことが重要だが、リーダーを選ぶためには何らかの「違い」を作り出す必要がある
• 違いを作り出すために ZooKeeper の Ephemeral & Sequential ノードを使う
  • ZooKeeper のクライアント(Solrのノード)は ZooKeeper 上の木構造にノードを作れる
  • ZooKeeper の Ephemeral ノードは、そのノードを作ったクライアントがダウンしたときに自動的にそのノードが無くなるので、クライアントのダウンを検知できる
  • ノードに Sequential プロパティを付与すると、兄弟ノード間で作られた順に一意のシーケンシャルな番号が振られる
  • 一番若い番号を持つノードのクライアントをリーダーとする
• リーダーがダウンしたとき
  • ZooKeeper のクライアントは ZooKeeper 上のノードを監視することができる
  • 各レプリカは自分より1個若い番号のノードを監視しておく
  • リーダーがダウンしたらそのノードを監視していたレプリカが新しいリーダーになる
• 全体のコーディネートは SolrCloud の Overseer が担当する
  • Overseer は SolrCloud のクラスタを構成する各 Solr ノードから選ばれるリーダー
  • Overseer 選出の手続きはシャードを構成するレプリカからリーダーを選出する手続きとほぼ同じ