すべてのプロダクト
Search
ドキュメントセンター

Elasticsearch:クラスター再起動または更新エラー

最終更新日:Aug 08, 2026

Elasticsearch クラスターの再起動または更新が、次のエラーで失敗する場合があります。

クラスターの状態が正常でない、またはクローズ状態のインデックスが含まれているため、この操作は実行できません。クラスターの状態が正常になるか、インデックスが有効になった後に再度操作を実行することを推奨します。

このエラーは、クラスターが以下のいずれか、または複数の条件を満たしている場合に発生します。

  • クラスターに クローズ 状態のインデックスが含まれている。

  • クラスターのヘルスステータスが red または yellow である。

  • クラスターは正常だが、負荷が高すぎる。

以下のセクションでは、各条件の診断および解決方法について説明します。

クローズされたインデックス

クローズ状態のインデックスは、クラスターの再起動および更新をブロックします。次のコマンドを実行して、インデックスの状態を確認します。

GET /_cat/indices?v

出力例:

health status index       uuid                   pri rep docs.count docs.deleted store.size pri.store.size dataset.size
green  open   my-index-01 30h1EiMvS5uAFr2t5CEVoQ   5   1      820            0       14mb           7mb         7mb
       close  my-index-02 BJxfAErbTtu5HBjIXJV_7A   1   1
green  open   my-index-03 _8C6MIXOSxCqVYicH3jsEA   1   1        7            0     24.3kb        12.1kb       12.1kb

この例では、my-index-02 がクローズ状態です。次のコマンドで開いてください。

POST /my-index-02/_open

my-index-02 は、クローズされたインデックスの名前に置き換えてください。複数のインデックスがクローズされている場合は、再起動または更新を再試行する前に、それぞれ個別に開いてください。

red または yellow のクラスターステータス

red ステータスは、1 つ以上のプライマリシャードが未割り当てであることを意味し、影響を受けるインデックスに対する検索やインデックス作成が失敗する可能性があります。yellow ステータスは、すべてのプライマリシャードが割り当てられているものの、1 つ以上のレプリカシャードが未割り当てであることを意味し、データ損失のリスクが高まります。

問題の診断

クラスターのヘルスステータスを確認します。

GET /_cat/health?v

ステータスが red または yellow の場合、未割り当てのシャードを特定します。

GET /_cat/shards?v&h=index,shard,prirep,state,node,unassigned.reason&s=state

特定のシャードが割り当てられない理由を確認するには、次のコマンドを実行します。

GET _cluster/allocation/explain
クラスター内に未割り当てのシャードがない場合、このコマンドはエラーを返します。これは想定される動作です。

出力例:

{
  "index": "my-index-02",
  "shard": 0,
  "primary": true,
  "current_state": "unassigned",
  "can_allocate": "no",
  "allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes"
}

allocate_explanation フィールドを使用して根本原因を特定してください。一般的な原因と解決策を以下に示します。

シャード割り当てリトライ回数の上限超過

シャードは最大 5 回のリトライで自動的に割り当てられます。すべてのリトライが完了した場合は、手動でシャードを再割り当ててください。

POST /_cluster/reroute?retry_failed=true

同一ノード上のプライマリシャードとレプリカシャード

割り当て説明に「the shard cannot be allocated to the same node on which a copy of the shard already exists」と表示される場合、インデックスのプライマリシャードとレプリカシャードが同一ノード上に存在しています。これを解決するには、次の手順を実行します。

  1. レプリカシャード数を 0 に設定します。

       PUT /my-index/_settings
       {
         "index": {
           "number_of_replicas": 0
         }
       }
  2. クラスターステータスが green に戻ったら、レプリカ数を再度 1 に設定します。

       PUT /my-index/_settings
       {
         "index": {
           "number_of_replicas": 1
         }
       }

同時シャード割り当て数の上限到達

クラスターがシャード割り当ての上限に達している場合は、現在の割り当てが完了するまで待ちます。数分経過してもシャードが未割り当てのままの場合は、割り当て説明を確認してください。

GET _cluster/allocation/explain

切断されたノード

1 つ以上のノードがクラスターから切断されている可能性があります。ノードのステータスを確認します。

GET _cat/nodes?v

出力に表示されないノードがある場合は、Elasticsearch コンソールからそれらのノードを再起動してください。

ディスク使用率の高さ

Elasticsearch は、ディスク領域の 85% を超えて使用しているノードに対してシャードを割り当てません。影響を受けるノードのディスク使用率が 85% を下回った後、ノードを再起動して通常のシャード割り当てを復元してください。

ノードごとのディスク使用率を確認するには、次のコマンドを実行します。

GET _cat/allocation?v

ディスク使用率を下げるには、次のいずれかの操作を行います。

  • 不要になった履歴インデックスを削除します。

  • ノードのディスク容量を拡張します。

  • レプリカシャード数を一時的に 0 に設定します。

ヒープメモリ使用率の高さ

ヒープメモリ使用率が高いと、クラスターの操作が一時停止する可能性があります。メモリを解放するには、次のいずれかの操作を行います。

  • 速度制限を適用して、流入トラフィックを減らします。

  • 履歴インデックスをクローズしてメモリ消費量を削減します。

その他の原因

上記のいずれにも該当しない場合は、Elasticsearch コンソールで CPU 使用率とヒープメモリ使用率を確認してください。未割り当てのシャードについては、次のコマンドを実行して詳細な説明を取得します。

GET _cluster/allocation/explain

クラスターの高負荷

クラスターが正常(green ステータス)であっても、負荷が高すぎると再起動または更新が失敗する可能性があります。負荷関連の問題を特定して解決するために、次のメトリックを確認してください。

ディスク使用率が 85% に到達

診断:

  • Elasticsearch コンソールでディスク使用率のモニタリングデータを確認します。

  • GET _cat/allocation を実行して、ノードごとのディスク割り当てを確認します。

  • GET _cluster/allocation/explain を実行して、割り当てに関する問題を確認します。

  • クラスターログでディスク関連の警告を確認します。

影響: ディスク使用率が 85% に達すると、Elasticsearch は対象ノードへの新しいシャードの割り当てを停止します。

ソリューション:

  • 不要になった履歴インデックスを削除します。

  • ディスク容量を拡張します。

  • レプリカシャード数を一時的に 0 に設定します。

対応後、モニタリングデータでディスク使用率が 85% を下回っていることを確認してください。

CPU 使用率が 85% に到達

診断方法:

  • Elasticsearch コンソールで CPU 使用率のモニタリングデータを確認します。

  • ホットスレッド情報を確認して、CPU を多く使用している操作を特定します。

影響: CPU 使用率が高いと、クラスターの安定性が低下します。

ソリューション:

  • モニタリングデータで読み取り QPS および書き込み QPS を確認し、可能であればトラフィックを削減します。

  • データノードを追加してクラスターをスケールアウトします。

  • より大きなインスタンスタイプを使用するようにクラスター構成をアップグレードします。

ヒープメモリ使用率が 75% 以上

診断方法:

  • Elasticsearch コンソールでヒープメモリ使用率のモニタリングデータを確認します。

  • GC(ガベージコレクション)に関する警告がクラスターログに記録されていないか確認します。

  • old gc collection count および old gc collecting.ms メトリックを確認して、長時間の GC ポーズがないかチェックします。

影響: ヒープメモリ使用率が高いと、クラスターの安定性が低下し、操作が一部サービス停止状態になる可能性があります。

ソリューション:

  • 読み取りおよび書き込みトラフィックを削減します。

  • クラスター構成をアップグレードします。

  • 履歴インデックスをクローズしてヒープメモリを解放します。

ノード負荷が vCPU 数を超える

診断方法:

  • Elasticsearch コンソールで NodeLoad_1m(value) メトリックを確認します。

  • ノードの vCPU 数を超える値は、負荷が重いことを示します。

影響: 負荷が高すぎるノードは応答不能になり、クラスター操作に影響を与える可能性があります。

ソリューション:

  • モニタリングデータで読み取り QPS、書き込み QPS、ディスクスループットを確認します。

  • 読み取りまたは書き込みトラフィックを削減します。

  • データノードを追加してクラスターをスケールアウトします。

  • クラスター構成をアップグレードします。

ホット・ウォームアーキテクチャにおける box_type の誤設定

診断方法:

  • ホット・ウォームアーキテクチャでは、インデックスが box_type 設定を使用して、そのシャードをホットノードまたはウォームノードに割り当てるかどうかを指定します。box_type の値が不正確だと、シャードの割り当てが妨げられ、再起動または更新が遅延します。

  • GET /{index_name}/_settings を実行して、インデックス設定内の box_type 設定を確認します。

影響: box_type が実際のノードタイプと一致しない場合、シャードが割り当てられず、再起動または更新が遅延します。

ソリューション:

  • box_type の値が対象ノードタイプと一致していることを確認してください。ホットノードには hot、ウォームノードには warm を使用します。

ルーティングが _id フィールドを指定している

診断:

  • インデックスの routing 設定が _id フィールドを指定している場合、シャードが期待通りに割り当てられず、再起動または更新が遅延します。

  • GET /{index_name}/_settings を実行して、index.routing 設定を確認します。

影響: シャードが正常に割り当てられません。

ソリューション:

  • routing が _id フィールドを指定している場合は、null に設定して、通常のシャード割り当てを復元してください。

参照