ディスク障害からの復旧 | KandaSearch Community Support Forum

ディスク障害からの復旧

トピック作成者:ks-solruserml-bot (2025/08/21 11:49 投稿)
5
OpenOpen

(The bot translated the original post https://lists.apache.org/thread/cm8o2phhgwoqz21hwbm511gc5zbnr4qh into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)

こんにちは。
私は SolrCloud を GKE(Google Kubernetes Engine)上で動かしており、Pod を新しいディスクタイプに移行しようとしています。その際、ディスクは完全に新しいものになります。
しかし、現在リーダーからデータが同期されない状態になっており、そこからの復旧方法がわからず困っています。

状況を具体的に説明します。以下の2つのノードがあるとします:

  • solr-0
  • solr-1

この2つはどちらもアクティブで、完全にレプリケーションされています。
私は solr-1 を停止し、それを新しい(空の)ディスクに接続し、再び起動しました。
サーバーは正常に起動し、UI から solr-1 にアクセスすることはできますが、復旧はされず、「Cloud → Graph」UI 上では solr-1 上の shard がダウンしている状態になっています。

「Cloud → Nodes」GUI 上ではノード自体は起動状態(up)として表示されていますが、そのコレクションの状態がおかしいです。例えば:
postcodes-006_s1r9_(down): undefined と表示されており、対照的に solr-0 では postcodes-006_s1r11: 847.3Mb と正しく表示されています。

私は、ノードが起動してディスクが空であることを検知すれば、自動的にリーダーからデータを再同期するものだと期待していました。
しかし実際には、何も起こらず、ノードはただ「座っている」状態です…。

今回、新しいディスクに移行したという点は本質的な問題ではなく、もっと広い意味で、「もしノードのデータが何らかの理由で失われた場合、自動的には復旧しない」ということが分かりました。
私はずっと(盲目的に)Solr は自動で復旧してくれると考えていました。というのも、新しい名前のノードを立ち上げたときには自動で復旧していたからです。

何が間違っていたのか、また、ノードにデータを完全に再送信させるためには、どうすればよいのかをご存じの方がいれば教えていただけませんか?

以下は API が返している内容です:

"shard1": {
  "range": "80000000-7fffffff",
  "replicas": {
    "core_node10": {
      "core": "postcodes-006_shard1_replica_n9",
      "node_name": "solr-1.search-solr-next.svc.cluster.local:80_solr",
      "type": "NRT",
      "state": "down",
      "force_set_state": "false",
      "base_url": "http://solr-1.search-solr-next.svc.cluster.local:80/solr"
    },
    "core_node12": {
      "core": "postcodes-006_shard1_replica_n11",
      "node_name": "solr-0.search-solr-next.svc.cluster.local:80_solr",
      "type": "NRT",
      "state": "active",
      "leader": "true",
      "force_set_state": "false",
      "base_url": "http://solr-0.search-solr-next.svc.cluster.local:80/solr",
      "property.preferredleader": "true"
    }
  },
  "state": "active",
  "health": "ORANGE"
}
返信投稿者:ks-solruserml-bot (2025/08/21 11:49 投稿)

こんにちは、

私も同じ現象を見たことがありますし、たしかに少し予想外の挙動だと思います。この挙動には何か理由があるのだとは思いますが、今のところ思い当たりません。

現時点であなたのケースで機能するであろう方法としては、まず ZooKeeper 上の死んでいるレプリカを削除することです(DELETEREPLICA を試してください)。その後、新しい空のノードに対して ADDREPLICA を実行すれば、新しいコアが作成され、同期が始まるはずです。

その状態でレプリカの削除ができるかは分かりませんが、試してみてください。

つまり、「空のディスクで起動したが、ZooKeeper には collection-A-shard-1-replica-2 があることになっている」という状況に対して、異なるデフォルト動作を実装することを我々が決定するまでは、ディスクをアップグレードするノードからすべてのレプリカを事前に移動させておいて、その後に再び戻すというのが最善の方法になります。

Jan

返信投稿者:ks-solruserml-bot (2025/08/21 11:49 投稿)

ああ、大丈夫です。返信ありがとうございます。
すでに StatefulSet を監視して管理系の処理を行うカスタムオペレーターを使っているので、ひとまずそこに復旧ロジックを組み込もうと思います。

返信投稿者:ks-solruserml-bot (2025/08/21 11:50 投稿)
solr delete -c YOUR\_DUPLICATA

を試してみましたか?
私は初心者なので、ただ聞いているだけです。

返信投稿者:ks-solruserml-bot (2025/08/21 11:50 投稿)

こんにちは、Karl。

ディスクを接続した際に、古いレプリカと core.properties ファイルの参照(これはコアの検出の一部です)が削除されてしまい、そのためコアをロードできなくなりました。ZK(ZooKeeper)内の「ダウンしたレプリカ」は、そのレプリカへの参照として残っています。上で述べられているように、DELETEREPLICA を実行してから ADDREPLICA を行うことで解決できるはずです。

新しいディスクを作成する際には、スナップショットを使用してからそれを復元する方法も検討してみてください。

ありがとう。

Patryk

返信投稿者:ks-solruserml-bot (2025/08/21 11:50 投稿)

こんにちは Patryk、ありがとう。

残念ながら、今回はスナップショットの利用は選択肢にありませんでした。というのも、私たちは Kubernetes 上で StatefulSet を使って Solr を運用しており、ディスクタイプを pd-ssd から hyper disk に変更する際(新しいノードタイプへの移行のため)、ノードが立ち上がるとすぐに StatefulSetvolumeClassTemplate に従って新しく空のディスクが作成・マウントされるためです。このプロセスにスナップショットを組み込む「Kubernetesネイティブな」方法は、私の見る限り存在しません。

個人的には、Solr が ZooKeeper 上に存在するレプリカが実ディスク上から消えていることを認識し、他ノードから自動で再同期/復旧するような仕組みがあるといいなと思っています。実際には、他に N 個のノードが正常に稼働しているのに、対象レプリカが「down」状態のまま放置されるのは不自然に感じます。私は「クラスターは可能な限り自律的に自己修復すべき」という理想主義的な見方を持っているのかもしれません。

ちなみに、REMOVE+ADD を自動化するために、私は Kubernetes Operator を作成しました。この Operator は StatefulSet 内の Pod を監視しています。Pod には ReadinessGate が設定されており、Operator はその Pod の readiness probe が通って「Ready」イベントが発生したタイミングで、Solr が起動したと判断します。その後、その Pod が持つレプリカの状態を確認し、いずれかが「down」であれば API コールでレプリカの削除と追加を行います。そしてすべてのレプリカが復旧した時点で ReadinessGate に対するステータス条件を追加し、その Pod がロードバランサに再び組み込まれるようにしています。

トピックへ返信するには、ログインが必要です。

KandaSearch

Copyright © 2006-2025 RONDHUIT Co, Ltd. All Rights Reserved.

投稿の削除

この投稿を削除します。よろしいですか?