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

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

最終更新日:Mar 01, 2026

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

クラスターが不健全であるか、インデックスがクローズ状態であるため、操作を実行できません。クラスターが健全になるか、インデックスが有効になった後に、操作を再度実行することをお勧めします。

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

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

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

  • クラスターは健全だが、高負荷 である。

次のセクションでは、各条件を診断して解決する方法について説明します。

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

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

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 をクローズされたインデックスの名前に置き換えます。複数のインデックスがクローズされている場合は、再起動または更新をリトライする前に、それぞれを個別に開きます。

赤色または黄色のクラスター状態

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

問題の診断

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

GET /_cat/health?v

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

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

プライマリシャードとレプリカシャードが同じノード上にある

割り当ての説明に「シャードのコピーが既に存在する同じノードにシャードを割り当てることができません」というメッセージが含まれている場合、インデックスのプライマリシャードとレプリカシャードは同じノードに割り当てられています。これを解決するには:

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

       PUT /my-index/_settings
       {
         "index": {
           "number_of_replicas": 0
         }
       }
  2. クラスターのステータスが緑色に戻ったら、レプリカ数を 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

クラスターの高負荷

クラスターが健全 (緑色のステータス) であっても、クラスターが高負荷である場合、再起動または更新が失敗する可能性があります。負荷の問題を特定して解決するには、次のメトリックを確認します。

ディスク使用率が 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、およびディスクスループットを確認します。

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

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

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

参照