SolrCloudのリーダー再選出の動作を確認する

はじめに

前回の記事ではシャードを構成する複数のレプリカの中からリーダーが選出される仕組みを解説しました。この記事では、実際に動いているSolrCloudを使って、特定のノードがダウンしたときにリーダーが切り替わる動作を確認してみます。

SolrCloudの構成

• サーバ3台、サーバ毎に Solr 1プロセス
• コレクション名 test のコレクションを作成
• test コレクションは shard1 と shard2 の2つのシャードを含む
• 各シャードはそれぞれ3つのレプリカ(それぞれ別のSolrノードで動く)を含む

コア名	ノード	シリアル番号	備考
core_node3	172.19.0.7:8985	12	リーダー
core_node5	172.19.0.6:8983	14
core_node7	172.19.0.5:8984	13

コア名	ノード	シリアル番号	備考
core_node9	172.19.0.7:8985	12	リーダー
core_node11	172.19.0.6:8983	14
core_node12	172.19.0.5:8984	13

リーダーがダウンしたとき

ノード 172.19.0.7:8985 (core_node3, core_node9)を落としてみます。

それまでのリーダー(シリアル番号12)の次に若い番号(13)を持つcore_node7およびcore_node12が新しいリーダーに選ばれています。

コア名	ノード	シリアル番号	備考
core_node3	172.19.0.7:8985	12	ダウン
core_node5	172.19.0.6:8983	14
core_node7	172.19.0.5:8984	13	リーダー

コア名	ノード	シリアル番号	備考
core_node9	172.19.0.7:8985	12	ダウン
core_node11	172.19.0.6:8983	14
core_node12	172.19.0.5:8984	13	リーダー

ダウンしたノードが復帰したとき

ダウンさせていた 172.19.0.7:8985 (core_node3, core_node9)を復帰させます。

リーダーに変更は無く、core_node3とcore_node9は新しい番号15をそれぞれ割り当てられます。

コア名	ノード	シリアル番号	備考
core_node3	172.19.0.7:8985	15	復帰
core_node5	172.19.0.6:8983	14
core_node7	172.19.0.5:8984	13	リーダー

コア名	ノード	シリアル番号	備考
core_node9	172.19.0.7:8985	15	復帰
core_node11	172.19.0.6:8983	14
core_node12	172.19.0.5:8984	13	リーダー

リーダーを意図的に変更する

まずcore_node3をpreferredLeaderに指定します。

curl 'http://172.19.0.6:8983/solr/admin/collections?action=ADDREPLICAPROP&shard=shard1&collection=test&replica=core_node3&>



REBALANCELEADERSを実行。



curl 'http://172.19.0.6:8983/solr/admin/collections?action=REBALANCELEADERS&collection=test'
{
  "responseHeader":{
    "status":0,
    "QTime":3053},
  "Summary":{
    "Success":"All active replicas with the preferredLeader property set are leaders"},
  "successes":{
    "shard1":{
      "status":"success",
      "msg":"Successfully changed leader of slice shard1 to core_node3"}}}




shard1のリーダーがcore_node3に変更されました。











FORCELEADER



FORCELEADERは障害等何らかの理由でリーダー不在の状態ができてしまった場合に強制的にリーダーを割り当てるためのコマンドです。リーダーが居ない状態を意図的に作るのは難しいので、正常な状態のシャードに対して FORCELEADER を実行するとどうなるか試してみました。



curl 'http://172.19.0.6:8983/solr/admin/collections?action=FORCELEADER&collection=test&shard=shard2'
{
  "responseHeader":{
    "status":500,
    "QTime":35},
  "error":{
    "metadata":[
      "error-class","org.apache.solr.common.SolrException",
      "root-error-class","org.apache.solr.common.SolrException"],
    "msg":"The shard already has an active leader. Force leader is not applicable. State: shard2:{
(略)
    "code":500}}




指定されたシャードにはリーダーが居るのでFORCELEADERの実行はできませんと怒られてしまいました。



おわりに



SolrCloudのクラスタはZooKeeperと連携していて、リーダーがダウンしたら自動的に新しいリーダーが選ばれてなるべくダウンタイムが小さくなるように工夫されている、という漠然とした理解から一歩進むために、具体的なリーダー選出のロジックを調べました。ZooKeeperの分散アプリケーションのコーディネート機能を使って案外シンプルなロジックで実装されていることが分かりました。この理解を持った上でリーダー調整用のAPIを上手に使えば、稀に発生するクラスタ異常にもうまく対処することができそうです。