SOLRをECS(Amazon Elastic Container Service)で使用している際に、write lockファイルに関する問題が発生する

トピック作成者:ks-solruserml-bot (2024/09/22 21:25 投稿)
4
OpenOpen

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

こんにちは、皆さん!

AWS ECSのSolrインスタンスで、データがEFS(Elastic File System)に保存されている場合に、write.lockファイルに関する問題を経験した方はいらっしゃいますか?ECSタスクが再起動すると、Solrがwrite.lockファイルを他のプロセスが使用していると認識し、更新作業をブロックしてしまうようです。

しかし実際には、停止したECSタスクが新しいタスクが自動的に立ち上がる前にまだ完全に終了していないだけなのです。

私たちのSolr ECSタスクは、それぞれ個別のSolrデータディレクトリをEFS上で使用しており、データを共有していないため、この問題がさらに困惑を引き起こしています。

これまでに、solrconfig.xmlの変更、具体的にはlockTypeunlockOnStartupwriteLockTimeoutなどのディレクティブを見てきましたが、私たちのシナリオではこれが役立つかどうかはわかりません。

さらに残念なことに、私たちはSolr 4.10.2を使わざるを得ません。というのも、Solr 5以降ではデータインポートハンドラーが変更されるため、それに対応するコードの変更が必要になるからです。

この問題がECSの問題である可能性も考えています。特に、ECSで実行するSolrイメージをビルドするために使用しているDockerエンジンのバージョン(20.10.13)が、ECSでのタスク再起動時にうまく動作していないのかもしれません。現時点では、特定のECSクラスターでECSライフサイクルの動作を変更できるかどうかは不明です。

どんな提案やヒントでも大変ありがたいです!

よろしくお願いします、
Daz

返信投稿者:ks-solruserml-bot (2024/09/22 21:25 投稿)

こんにちは、Darren

私もEKS Kubernetesクラスター上でSolrを実行しているときに、非常に似た問題に直面しました。私が見つけた解決策は、Kubernetesのデプロイメントにpre_stopのシャットダウンフックを追加することでした。このフックでは、ポッドが終了される前に/opt/solr/bin/solr stop -k solrrocks -p 8983というコマンドを実行して、Solrを優雅に停止します。また、termination_grace_period_secondsを使って180秒の猶予期間を追加しました。そのため、ポッドをシャットダウンするのに少なくとも3分かかるようになりました。

この方法により、Solrが再起動される前にロックファイルがクリアされます。ただし、同じアプローチがECSで使用できるかどうかはわかりません。

-ufuk yilmaz

返信投稿者:ks-solruserml-bot (2024/09/22 21:26 投稿)

追加するのを忘れていましたが、デプロイメント戦略もデフォルトの「RollingUpdate」ではなく、「Recreate」に変更しました。これにより、Kubernetesクラスターが新しいポッドを作成する前に古いポッドをシャットダウンし、ロックファイルの問題を回避します。ただし、非常に高い可用性が必要な場合には、この方法は適さないかもしれません。

-ufuk yilmaz

返信投稿者:ks-solruserml-bot (2024/09/22 21:26 投稿)

bin/solrスクリプトには、強制的にプロセスを終了する前に180秒の猶予期間が既に設定されています。ただし、終了が早く行われる場合は、3分間フルに待つことはなく、通常はすぐに終了します。

ロックファイル自体が存在しても、「ネイティブ」ロックタイプでは問題を引き起こすべきではありません。しかし、すでにそれをロックしているプロセスが動作している場合は、問題が発生します。

元の投稿に戻りますが、solrconfig.xmlでロックタイプを変更する必要はないはずです。ファイルシステムがNFSやSMBのようなネットワーク経由でない限り、ローカルにマウントされたファイルシステムと同じロック機能がない場合に限ります。デフォルトの「ネイティブ」が最適なオプションであることが多いです。

ありがとう、
Shawn

返信投稿者:ks-solruserml-bot (2024/09/22 21:26 投稿)

EFSはNFSです。もしNFSv4としてマウントすれば、ロックなどの機能がしっかりサポートされるはずですが、設定オプションがある場合は試してみるべきです。

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

KandaSearch

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

投稿の削除

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