すべてのプロダクト
Search

このプロダクト

    Elasticsearch:高ディスク使用率と読み取り専用インデックス

    ドキュメントセンター

    Elasticsearch:高ディスク使用率と読み取り専用インデックス

    最終更新日:Aug 20, 2026

    Alibaba Cloud Elasticsearch クラスターのディスク使用率が 85% を超えると、Elasticsearch はデータ整合性を保護するために、新しいシャードの割り当てを停止します。ディスク使用率がさらに上昇すると、書き込みアクセスがブロックされる可能性があります。このトピックでは、根本原因、書き込みアクセスを迅速に回復する方法、および再発を防ぐ方法について説明します。

    重要

    免責事項：このトピックには、サードパーティ製品に関する情報が含まれている場合があります。このような情報は参考用です。Alibaba Cloud は、サードパーティ製品のパフォーマンスと信頼性、および製品に対する操作の潜在的な影響について、明示的または黙示的を問わず、いかなる保証も行いません。

    症状

    • 書き込みリクエストは FORBIDDEN/12/index read-only / allow delete (api) というエラーで失敗します。

    • クラスターのヘルスステータスが赤です。GET /_cat/nodes?v を実行して、ノードがクラスターに再参加したかどうかを確認します。GET /_cat/allocation?v を実行して、シャードの割り当てを確認します。

      説明

      クラスターのヘルスステータスが赤色の場合、プライマリシャードが利用できないことを意味します。データがリスクにさらされている可能性があります。

    • インジェストパイプラインの作成または Beats の登録を行うと、Kibana から internal server error が返される

    • クラスターまたは Kibana のモニタリングで、ディスク使用率が 100% に近づいていることが表示されます。

    根本原因

    ディスク使用率の閾値

    Elasticsearch はディスク使用率を継続的に監視し、3 つのウォーターマーク閾値を適用します。

    • 85% — 低ウォーターマーク：Elasticsearch は、このノードへの新しいシャードの割り当てを停止します。

    • 90% — 高ウォーターマーク：Elasticsearch は、既存のシャードをディスク空き容量が多いノードに再配置しようとします。

    • 95% — フラッドステージ：Elasticsearch は、すべてのインデックスに read_only_allow_delete 属性を設定し、すべての書き込み操作をブロックします。ディスク使用量のウォーターマーク

    ディスクウォーターマーク閾値に加えて、以下の状況も書き込み失敗またはアラートを引き起こす可能性があります。これらの原因も併せて調査してください。

    シャード数の上限超過

    デフォルトでは、Elasticsearch クラスターの各データノードは最大 1,000 個のシャードをサポートします。 GET /_cluster/settings?include_defaults=true&flat_settings=true を実行し、cluster.max_shards_per_node パラメーターを確認することで、現在の上限を確認できます。 シャード数が上限を超えると、Logstash はログを書き込むことができず、新しいインデックスを作成できなくなります。

    一時的な回避策として、次のコマンドを実行してシャード数の上限を増やします。

    PUT /_cluster/settings
{
  "transient": {
    "cluster": {
      "max_shards_per_node": 2000
    }
  }
}
    説明

    コマンドの PUT の後にスペースを追加してください。

    恒久的な解決策としては、期限切れまたは未使用のインデックスをクリーンアップするか、クラスターにデータノードを追加します。

    システムインデックスのライフサイクルポリシー

    ディスク使用量が頻繁に変動するものの、カスタムのインデックスライフサイクル管理 (ILM) ポリシーが設定されていない場合、その変動は .monitoring-es-* や .monitoring-kibana-* などのシステムインデックスのデフォルトのライフサイクルポリシーが原因である可能性があります。これらのインデックスは毎日自動的に作成され、古いインデックスは自動的に削除されます。これは正常な動作です。

    関連リソースの影響

    高ディスク使用率には、高 JVM メモリ使用率 (例：90% に到達) やノードの異常が伴う場合があり、Kibana の接続が妨げられる可能性があります。この場合、ディスク容量とメモリリソースの両方をスケールアップします。クラスターが正常でない場合は、設定のアップグレード中に強制変更を有効にします。ノードの再起動によるサービス中断を回避するため、業務のオフピーク時間帯に操作を実行してください。

    迅速な修正 (10～15 分)

    1. 古いまたは未使用のインデックスを削除して、ディスク領域を解放します。

      警告

      削除されたデータは復元できません。データを保持する場合は、代わりに ストレージ容量を増やす ことを検討してください。

      curl -u <username>:<password> -XDELETE http://<host>:<port>/<index-name>

      • <host>は、クラスターの内部またはパブリックエンドポイントです。このコマンドを実行する前に、アクセス許可リストを設定してください。

      • クラスターが応答しない場合は、強制再起動を行い、再起動中にこのコマンドを実行します。

    2. 読み取り専用ロックを解除します。ディスク領域を解放しても、書き込みブロックは自動的に解除されません。index.blocks.read_only_allow_deleteをnullに設定してクリアします。

      PUT /_all/_settings
{
   "index.blocks.read_only_allow_delete": null
}

    3. クラスターのヘルス状態を確認します。ステータスがまだ赤色の場合は、GET /_cat/allocation?v を実行して未割り当てのシャードを確認します。

    4. 未割り当てのシャードが残っている場合は、GET /_cluster/allocation/explain を実行して原因を特定します。出力に、割り当てのリトライ回数が上限に達したこと (以下に示すように) が表示された場合は、POST /_cluster/reroute?retry_failed=true を実行します。

      "deciders": [
  {
    "decider": "max_retry",
    "decision": "NO",
    "explanation": "shard has exceeded the maximum number of retries [5] on failed allocation attempts - manually call [/_cluster/reroute?retry_failed=true] to retry, [unassigned_info[[reason=ALLOCATION_FAILED], at[2020-02-14T00:22:25.939Z], failed_attempts[5], delayed=false, details[failed shard on node [xxx]: shard failure, reason [lucene commit failed], failure IOException[No space left on device], allocation_status[deciders_no]]]]"
  }
]

      ディスクを拡張したり、データをクリーンアップしたりした後も、エラーが解決しない場合があります。ディスク使用率が 100 % に達すると、シャードの割り当てが失敗し、再試行の上限に達します。ディスクを拡張したりデータを削除したりした後でも、一部のシャードが未割り当てのままになることがあり、クエリは引き続き失敗し、503 search_phase_execution_exception などのエラーが発生します。

      この場合、POST /_cluster/reroute?retry_failed=true を手動で実行し、失敗したシャードの割り当てを再試行します。コマンドが返された後、シャードのリカバリが完了するまで待機します。リカバリが完了すると、クラスターは通常のサービスに復帰します。

    5. すべての回復手順の後もクラスターのヘルスステータスが赤色のままの場合は、Alibaba Cloud テクニカルサポートにお問い合わせください。

    よくある質問

    Elasticsearch コンソールでクラスターステータスが正常と表示されているのに、ディスク使用率アラートを受信するのはなぜですか。

    コンソール上のクラスターステータスが正常であることは、クラスターが現在利用可能であることを示すだけです。ただし、ディスク使用率はすでにアラート閾値 (例：91%) に達している可能性があります。高ディスク使用率がすぐに読み取り専用モードをトリガーしていなくても、重要なウォーターマークに近づいています。95% に達すると、強制的に読み取り専用モードがトリガーされ、書き込み操作がいつでもブロックされる可能性があります。

    [クラスターモニタリング] ページで実際のディスク使用率をすぐに確認し、リスクを排除するために次のいずれかの対策を講じることを推奨します。

    • ディスク容量をスケールアップします。

    • 未使用または期限切れのインデックスをクリーンアップします。

    クラスターのヘルスステータスを回復させるため、ディスクウォーターマークを一時的に調整するにはどうすればよいですか。

    低ウォーターマークの一時的な引き上げは、ディスクウォーターマーク制限によりクラスターステータスが正常でなく、シャードが未割り当てで、すぐにスケールアップできない場合の緊急措置としてのみ行ってください。Kibana の 開発ツール で、クラスター設定 API を呼び出して低ウォーターマークを引き上げます (例：88% に)。これにより、ウォーターマークによってブロックされていたシャードを再度割り当てることができます。

    PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.disk.watermark.low": "88%"
  },
  "persistent": {
    "cluster.routing.allocation.disk.watermark.low": "88%"
  }
}

    この設定は、デフォルトの低ウォーターマークである 85% を 88% に上書きしますが、90% (高ウォーターマーク) と 95% (フラッドステージ) のしきい値は変更されません。

    これは一時的な回避策です。クラスターステータスが緑色に戻った後、コンソールでインプレースローリング変更を通じて設定をアップグレードするか、できるだけ早くデータをクリーンアップしてください。引き上げられたウォーターマークに長期的に依存しないでください。

    インデックスを削除した後、ディスク領域が解放されるまでどのくらいかかりますか。

    「迅速な修正 (10～15 分)」の最初のステップで説明されているようにインデックスを削除すると、通常、数分から 30 分以内にディスク領域の解放が始まり、その後すぐにモニタリングメトリクスに変化が反映されます。

    長時間経過してもディスク領域が解放されない場合は、残っているインデックス、スナップショット、ログなど、他のデータがディスクを消費していないか、またはモニタリングメトリクスの更新が遅延していないかを確認してください。

    予防策

    ディスク使用率のモニタリングを有効にし、使用率が 80% を超えたときに発動するアラートを設定します。アラートを運用チームに送信して、フラッドステージに到達する前に対処できるようにします。設定手順については、モニタリングとアラートの設定 をご参照ください。