Elastic Certified Engineer Exam対策 – Cluster Health & Recovery

このブログの目的

本記事では、Elastic Certified Engineer試験範囲の以下を対象に、Cluster Healthの確認方法、Unassigned Shardの調査方法、およびCluster Recoveryの基本を学習します。

Cluster Management – Diagnose shard issues and repair a cluster’s health

Cluster Health APIやCAT API、Allocation Explain APIなど、試験で利用する代表的なAPIの用途と使い方を解説するとともに、Shard Allocationに問題が発生した際の調査手順や代表的な復旧方法について学びます。

本記事を通して、Cluster Healthの確認から原因調査、復旧までの基本的な流れを理解し、試験で必要となる知識を効率よく習得することを目的としています。

試験情報は以下サイトで確認可能です。
https://www.elastic.co/training/elastic-certified-engineer-exam

Cluster Health & Recoveryとは

この章では、Cluster Healthの基本を学習します。Cluster Healthは、クラスター全体の正常性を表す指標であり、障害発生時の調査や復旧では最初に確認する重要な情報です。

まずはCluster Healthの概要を理解し、続いてGreen・Yellow・Redそれぞれの状態について学習します。

Cluster Healthとは

Cluster Healthは、クラスター全体の正常性を示すステータスです。クラスター内のPrimary ShardおよびReplica Shardが正常に割り当てられているかを確認し、その結果をGreen・Yellow・Redの3段階で表します。

Cluster Healthは、次のAPIで確認できます。

GET _cluster/health

実行結果の例を示します。

特に確認しておきたい項目は次のとおりです。

“GET _cluster/health” コマンド は、クラスター全体のHealth状態を確認するAPIです。複数Nodeで構成されたクラスターでも、各Nodeの情報を個別に返すのではなく、クラスター全体を集計した結果を返します。そのため、どのNodeやShardに問題があるかまでは分かりません。

Cluster Healthは、クラスター全体だけでなく、特定のインデックスを対象に確認することもできます。特定のインデックスを確認する場合は、_cluster/healthの後ろにインデックス名を指定します。

GET _cluster/health/kibana_sample_data_ecommerce

インデックスごとの状態をまとめて確認する場合は、level=indicesを指定します。

GET _cluster/health?level=indices

例えば、上記のblogs_dynamic_strictインデックスは、筆者の検証環境ではNodeが1台しかないため、Replica Shardを配置できません。Primary ShardとReplica Shardは同じNodeに配置できないため、Cluster Healthはyellowになります。つまり、Nodeが1台のみのクラスターでは、Replicaを設定したインデックスはgreenになりません。

Green / Yellow / Red

Cluster Healthには、Green・Yellow・Redの3つの状態があります。

Green

Greenは最も正常な状態です。

• すべてのPrimary Shardが割り当てられている
• すべてのReplica Shardも割り当てられている
• クラスターは正常に稼働している

障害耐性が確保されており、特別な対応は不要です。

Yellow

Yellowは、Primary Shardは正常ですが、一部またはすべてのReplica Shardが割り当てられていない状態です。

• Primary Shardはすべて割り当てられている
• Replica ShardがUnassignedになっている
• 検索・更新は可能

代表的な例として、Single Node構成でReplicaを1以上に設定した場合があります。Replicaを配置できるNodeが存在しないため、Cluster HealthはYellowになります。

Red

Redは、1つ以上のPrimary Shardが割り当てられていない状態です。

• Primary ShardがUnassignedになっている
• 一部のデータへアクセスできない可能性がある
• 検索や更新に失敗する場合がある

Redは早急な対応が必要な状態です。まずはUnassigned Shardの原因を調査し、必要に応じてShardの再割り当てや復旧作業を実施します。

Cluster Healthの確認

Cluster Health API

Cluster Health APIは、クラスター全体または特定のインデックスの正常性を確認するためのAPIです。Cluster Healthがgreen、yellow、redのいずれの状態であるかや、Primary Shard・Replica Shardの割り当て状況などを確認できます。

クラスター全体の状態を確認するには、次のコマンドを実行します。

GET _cluster/health

特定のインデックスのみ確認する場合は、インデックス名を指定します。

GET _cluster/health/kibana_sample_data_ecommerce

2.2 CAT Health API

CAT Health APIは、クラスター全体のHealth情報を一覧形式で確認するためのAPIです。_cluster/healthよりも簡潔に表示されるため、運用時に現在の状態を素早く確認したい場合によく利用されます。

次のコマンドを実行します。

GET _cat/health?format=json

実行結果

GET _cluster/health
GET _cat/health

上記コマンドは、どちらもCluster HealthやShard数、Unassigned Shard数など、似たような情報を取得できます。Health状態を確認する目的であれば大きな違いはありませんが、GET _cluster/healthは詳細な情報や追加のパラメータを利用できます。

CAT Shards API

CAT Shards APIは、Shardごとの状態を一覧形式で確認するためのAPIです。各ShardがどのNodeに配置されているかや、Primary・Replicaの別、Shardの状態などを確認できます。障害発生時には、Unassigned Shardの有無や配置状況を確認する際によく利用されます。

次のコマンドを実行します。

GET _cat/shards?v

GET _cat/shards?v&format=json

実行結果の例を示します。

特に確認しておきたい項目は次のとおりです。

• “index”：インデックス名
• “prirep”：”p”はPrimary、”r”はReplica
• “state”：Shardの状態（”STARTED”、”INITIALIZING”、”RELOCATING”、”UNASSIGNED”）
• “node”：Shardが配置されているNode

各state値の説明

上記の例では、Primary ShardはSTARTEDですが、Replica ShardはUNASSIGNEDとなっています。このように、どのShardで問題が発生しているかを確認できるのがCAT Shards APIの特徴です。次節で説明するCAT Allocation APIと組み合わせることで、より詳細な原因調査を行えます。

CAT Allocation API

CAT Allocation APIは、NodeごとのShard数やディスク使用量を一覧形式で確認するためのAPIです。Shardの配置状況に加え、各Nodeのディスク使用状況も確認できるため、Shardが割り当てられない原因の調査に役立ちます。

次のコマンドを実行します。

GET _cat/allocation?v

GET _cat/allocation?v&format=json

GET _cat/allocation?v&format=json の実行結果

Node: es01

shards : 221
shards.undesired : 0
write_load.forecast : 3.342212489689048E-4
disk.indices.forecast : 2.8gb
disk.indices : 1.6gb
disk.used : 67.6gb
disk.avail : 939.1gb
disk.total : 1006.8gb
disk.percent : 6

host : 10.4.2.96
ip : 10.4.2.96
node.role : cdfhilmrstw

UNASSIGNED

shards : 127

特に確認しておきたい項目は次のとおりです。

disk.percentが高くなると、Disk Watermarkの設定によりShardを新たに割り当てられなくなる場合があります。Cluster Healthがyellowやredの場合は、CAT Shards APIとあわせて確認すると、原因を特定しやすくなります。

node.role : cdfhilmrstw について

cdfhilmrstw は、Nodeが複数の役割（Role）を持っていることを1文字ずつ表したものです。_cat/nodes APIでは、各Roleが省略表記で表示されます。

文字	Role	説明
c	data_cold	Cold Tierのデータを保持する。
d	data	汎用Data Node。検索・更新・集計を実行する。
f	data_frozen	Frozen Tierのデータを保持する。
h	data_hot	Hot Tierのデータを保持する。書き込みが多いデータ向け。
i	ingest	Ingest Pipelineを実行する。
l	ml	Machine Learning機能を実行する。
m	master	Master Nodeとしてクラスター管理を行う。
r	remote_cluster_client	CCS・CCRなどのRemote Clusterへ接続する。
s	data_content	通常のコンテンツデータを保持する。
t	transform	Transformジョブを実行する。
w	data_warm	Warm Tierのデータを保持する。

Elastic Docs > Deploy and manage > Distributed architecture
https://www.elastic.co/docs/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles

Recovery API

Recovery APIは、Shardのリカバリー状況を確認するためのAPIです。Node障害からの復旧や、Shardの再配置、Snapshotからのリストアなどが実行されると、リカバリー処理の進行状況を確認できます。

次のコマンドを実行します。

GET _recovery

特定のインデックスのみ確認する場合は、インデックス名を指定します。

GET kibana_sample_data_ecommerce/_recovery

実行結果の例を示します。

特に確認しておきたい項目は次のとおりです。

typeの種類

GET <index>/_recoveryは、Recoveryの進行状況や実行結果を確認するためのAPIです。Recoveryは、NodeやElasticsearchの再起動、Shardの再配置、Replica Shardの作成、Snapshotからのリストアなど、Shardを復旧・同期する必要があるタイミングで実行されます。

Recovery実行中は現在の進行状況を、完了後は最後に実行されたRecoveryの情報を確認できます。例えば、typeがEXISTING_STOREであれば、最後のRecoveryではNode上に保存されていた既存のShardデータを利用したことを示します。

stageの種類

stageには、現在のリカバリー状況が表示されます。

Recovery APIは、Shardが正常に復旧しているかや、現在どの段階まで処理が進んでいるかを確認する際に利用します。Cluster Healthがyellowやredの場合や、Shardの再配置・Snapshotからのリストア後の確認に役立ちます。

Unassigned Shardの調査

この章では、Unassigned Shardの調査方法を学習します。

Cluster Healthがyellowまたはredの場合は、CAT Shards APIで対象のShardを特定し、Allocation Explain APIで割り当てられない原因を確認します。CAT Allocation APIと組み合わせることで、問題の原因を効率よく調査できます。

Unassigned Shardとは

Unassigned Shardは、どのNodeにも割り当てられていないShardです。Replica ShardがUnassignedの場合、Cluster Healthはyellowになります。検索や更新は可能ですが、障害発生時にデータを保護できない状態です。

Primary ShardがUnassignedの場合、Cluster Healthはredになります。Primary Shardへアクセスできないため、一部の検索や更新が失敗する可能性があります。

Unassigned Shardは、CAT Shards APIで確認できます。

GET _cat/shards?v
GET _cat/shards?h=index,shard,prirep,state

実行結果を示します。

特に確認しておきたい項目は次のとおりです。

stateがUNASSIGNEDとなっているShardは、現在どのNodeにも割り当てられていません。

ただし、このAPIでは「なぜUnassignedになっているか」は分かりません。原因を調査するには、次節で説明するAllocation Explain APIを利用します。

Allocation Explain API

Allocation Explain APIは、Unassigned ShardがNodeへ割り当てられない原因を調査するためのAPIです。

CAT Shards APIでは、どのShardがUNASSIGNEDになっているかは確認できますが、その原因までは分かりません。原因を調査する場合は、Allocation Explain APIを利用します。

次のコマンドを実行します。

GET _cluster/allocation/explain

Unassigned Shardが複数ある場合は、そのうち1つについて結果が返されます。

上図の内容は以下です。

特定のShardを調査する場合は、インデックス名、Shard番号、PrimaryかReplicaかを指定します。

GET _cluster/allocation/explain
{
  "index": "blogs_dynamic_strict",
  "shard": 0,
  "primary": false
}

実行結果の例を示します。

{
  "index": "blogs_dynamic_strict",
  "shard": 0,
  "primary": false,
  "current_state": "unassigned",
  "unassigned_info": {
    "reason": "CLUSTER_RECOVERED",
    "at": "2026-07-14T06:03:42.719Z",
    "last_allocation_status": "no_attempt"
  },
  "can_allocate": "no",
  "allocate_explanation": "Elasticsearch isn't allowed to allocate this shard to any of the nodes in the cluster. Choose a node to which you expect this shard to be allocated, find this node in the node-by-node explanation, and address the reasons which prevent Elasticsearch from allocating this shard there.",
  "node_allocation_decisions": [
    {
      "node_id": "Zt5YAm63QQqDupFLLjpnZg",
      "node_name": "es01",
      "transport_address": "10.4.2.90:9300",
      "node_attributes": {
        "xpack.installed": "true",
        "transform.config_version": "10.0.0",
        "ml.machine_memory": "16484327424",
        "ml.allocated_processors": "14",
        "ml.allocated_processors_double": "14.0",
        "ml.max_jvm_size": "1073741824",
        "ml.config_version": "12.0.0"
      },
      "roles": [
        "data",
        "data_cold",
        "data_content",
        "data_frozen",
        "data_hot",
        "data_warm",
        "ingest",
        "master",
        "ml",
        "remote_cluster_client",
        "transform"
      ],
      "node_decision": "no",
      "deciders": [
        {
          "decider": "same_shard",
          "decision": "NO",
          "explanation": "a copy of this shard is already allocated to this node [[blogs_dynamic_strict][0], node[Zt5YAm63QQqDupFLLjpnZg], [P], s[STARTED], a[id=DKmvwLTVRgyET7ik9CjBYg], failed_attempts[0]]"
        }
      ]
    }
  ]
}

特に確認しておきたい項目は次のとおりです。

allocate_explanation 訳

Elasticsearch isn’t allowed to allocate this shard to any of the nodes in the cluster. Choose a node to which you expect this shard to be allocated, find this node in the node-by-node explanation, and address the reasons which prevent Elasticsearch from allocating this shard there.

Elasticsearchは、このShardをクラスター内のどのNodeにも割り当てることができません。Shardを配置したいNodeを選択し、node_allocation_decisionsの判定内容を確認してください。そのNodeへの割り当てを妨げている原因を特定し、問題を解消する必要があります。

deciders.explanation 訳

a copy of this shard is already allocated to this node [[blogs_dynamic_strict][0], node[Zt5YAm63QQqDupFLLjpnZg], [P], s[STARTED], a[id=DKmvwLTVRgyET7ik9CjBYg], failed_attempts[0]]

このShardのコピーは、すでにこのNodeへ配置されています。
（blogs_dynamic_strictのShard 0のPrimary Shardは、現在このNodeでSTARTED状態です。）
———-
つまり、このsame_shard Deciderは、
” 同じShardのPrimary ShardがすでにこのNodeに存在するため、Replica Shardを同じNodeへ配置することはできない “
と判断しています。

can_allocateは、Shardを現在割り当てられるかを示します。

主な値は次のとおりです。

原因を調査する際は、まずallocate_explanationで概要を確認し、その後decidersを確認します。

例えば、deciderがsame_shardの場合は、Primary ShardとReplica Shardを同じNodeへ配置できないことが原因です。Single Node構成でReplica数が1以上に設定されている場合によく発生します。

Elastic API Docs > Cluster > Explain the shard allocations
https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-allocation-explain

Allocation Explain APIの代表的な判定結果

Allocation Explain APIでは、Shardを割り当てられない理由がcan_allocateやdecidersに表示されます。

ここでは、公式ドキュメントで紹介されている代表的な判定結果を紹介します。これらを理解しておくと、Unassigned Shardの原因を素早く特定できます。

各判定結果は、allocate_explanationで概要を確認し、node_allocation_decisions内のdecidersで詳細な理由を確認できます。

実際の運用では、same_shardはSingle Node構成、filterやenableはShard Allocationの設定、no_valid_shard_copyはNode障害後の復旧作業などでよく確認されます。Allocation Explain APIを利用する際は、can_allocateだけで判断するのではなく、decidersの内容まで確認することが重要です。

Elastic Docs > Troubleshoot > Elasticsearch > Clusters > Unassigned shards
https://www.elastic.co/docs/troubleshoot/elasticsearch/diagnose-unassigned-shards

Elastic Docs > Troubleshoot > Elasticsearch > Clusters > Cluster allocation API examples
https://www.elastic.co/docs/troubleshoot/elasticsearch/cluster-allocation-api-examples

Unassigned Shardの調査手順

Unassigned Shardは、次の順序で調査します。

1. Cluster Healthを確認する。

GET _cluster/health

2. Unassigned Shardを特定する。

GET _cat/shards?v

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

3. Allocation Explain APIで原因を確認する。

GET _cluster/allocation/explain
{
  "index": "blogs_dynamic_strict",
  "shard": 0,
  "primary": false
}

4. 必要に応じてNode、ディスク、インデックス設定、クラスター設定を確認する。

GET _cat/allocation?v

GET blogs_dynamic_strict/_settings

GET blogs_dynamic_strict/_settings?flat_settings=true

GET _cluster/settings?include_defaults=true&flat_settings=true

5. 原因を特定した後、Replica数の変更、Nodeの追加、ディスク容量の確保、Allocation設定の修正、Shardの再割り当てなどを実施する。

Unassigned Shardが発生した場合は、すぐに強制割り当てを実行するのではなく、Allocation Explain APIで原因を特定することが重要です。原因によって必要な対応が異なるため、まずShardとNodeの状態を確認し、その結果に応じて復旧方法を選択します。

Cluster Recovery

Replica数の変更

Replica数は、インデックス作成後でも動的に変更できます。Replica数を変更すると、Elasticsearchは新しい設定に合わせてShard Allocationを実行し、必要に応じてReplica Shardの作成や削除を行います。

Replica数は、次のAPIで変更します。

PUT kibana_sample_data_ecommerce/_settings
{
  "index": {
    "number_of_replicas": 0
  }
}

Replica数を1へ変更する場合は、次のように指定します。

PUT kibana_sample_data_ecommerce/_settings
{
  "index": {
    "number_of_replicas": 1
  }
}

変更後は、Cluster HealthやShardの状態を確認して、Replica Shardが期待どおりに割り当てられているかを確認します。

GET _cluster/health/kibana_sample_data_ecommerce

GET _cat/shards?v

Single Node構成では、Primary ShardとReplica Shardを同じNodeへ配置できません。そのため、Replica数を1以上に設定すると、Replica ShardはUNASSIGNEDとなり、Cluster Healthはyellowになります。一方、Replica数を0へ変更すると、未割り当てのReplica Shardがなくなるため、すべてのPrimary Shardが正常であればCluster Healthはgreenになります。

本記事の検証環境はSingle Node構成のため、number_of_replicasを0に変更すると、未割り当てのReplica Shardがなくなり、Cluster Healthはgreenになります。

ただし、これは検証環境特有の結果です。本番環境では通常、障害耐性を確保するために複数Nodeでクラスターを構成し、Replicaを1以上に設定して運用します。Replicaを0にすると、Node障害が発生した際にデータの冗長性が失われるため、本番環境では特別な理由がない限り推奨されません。

Retry Failed Allocation

Shard Allocationは、何らかの原因で失敗すると、自動的に再試行されます。しかし、一定回数失敗すると、それ以上は自動で再試行されなくなります。

原因を解消した後は、Cluster Reroute APIのretry_failedオプションを利用して、失敗したShard Allocationを再試行できます。

POST _cluster/reroute?retry_failed=true

例えば、ディスク容量不足やShard Allocationの設定が原因でAllocationに失敗した場合は、先に原因を解消してから、このAPIを実行します。

実行後は、失敗していたShard Allocationが再試行されます。

acknowledgedがtrueの場合は、リクエストが正常に受け付けられたことを示します。

ただし、このAPIは原因を解消するものではありません。原因が残っている場合は、Allocationは再び失敗します。そのため、実行前にAllocation Explain APIで原因を確認し、必要な設定変更や環境修正を行うことが重要です。

変更後は、Cluster HealthやShardの状態を確認して、Shardが正常に割り当てられたことを確認します。

Cluster Reroute API

Cluster Reroute APIは、Shardの割り当てや移動を手動で実行するためのAPIです。

通常、Shard AllocationはElasticsearchが自動的に判断して実行します。しかし、障害対応や運用上の理由により、管理者がShardの配置を手動で変更したい場合があります。そのような場合にCluster Reroute APIを利用します。

例えば、次のような操作を実行できます。

• Replica Shardを手動で割り当てる
• Shardを別のNodeへ移動する
• 割り当て済みのShardを別のNodeへ再配置する
• retry_failedにより、失敗したShard Allocationを再試行する

commands > allocate_replica

Cluster Reroute APIは、commandsに実行したい操作を指定します。例えば、Replica Shardをes02へ割り当てる場合は、次のように実行します。

POST _cluster/reroute
{
  "commands": [
    {
      "allocate_replica": {
        "index": "blogs",
        "shard": 0,
        "node": "es02"
      }
    }
  ]
}

allocate_replicaは、指定したShard番号のReplica Shardを、指定したNodeへ手動で割り当てるコマンドです。

上記の例では、blogsインデックスのShard番号0を対象として、そのReplica Shardをes02へ割り当てています。Shard番号はPrimary ShardとReplica Shardで共通であり、shard: 0は「Shard番号0」を表します。

実行後のShardの配置イメージは次のとおりです。

blogs
├─ Shard 0
│   ├─ Primary → es01
│   └─ Replica → es02 ← 手動で割り当て
└─ Shard 1
    ├─ Primary → es02
    └─ Replica → es01

このように、Shard番号0のPrimary Shardはes01に配置されたまま、対応するReplica Shardのみがes02へ割り当てられます。Primary ShardとReplica Shardは同じNodeには配置できないため、通常は別々のNodeへ配置されます。

commands > move

Shardをes01からes02へ移動する場合は、moveコマンドを利用します。

POST _cluster/reroute
{
  "commands": [
    {
      "move": {
        "index": "blogs",
        "shard": 0,
        "from_node": "es01",
        "to_node": "es02"
      }
    }
  ]
}

moveは、指定したShardを現在配置されているNodeから別のNodeへ移動するコマンドです。allocate_replicaとは異なり、Primary ShardとReplica Shardのどちらも対象になります。

この例では、blogsインデックスのShard番号0を対象として、es01からes02へ移動しています。from_nodeには現在Shardが配置されているNode、to_nodeには移動先のNodeを指定します。どちらのShardが移動するかは、from_nodeに配置されているShardによって決まります。

実行前のShardの配置イメージは次のとおりです。

blogs
├─ Shard 0
│   ├─ Primary → es01 ← 移動元
│   └─ Replica → es03
└─ Shard 1
    ├─ Primary → es02
    └─ Replica → es01

この例では、es01にShard番号0のPrimary Shardが配置されているため、実行後はPrimary Shardがes02へ移動します。

blogs
├─ Shard 0
│   ├─ Primary → es02 ← 移動先
│   └─ Replica → es03
└─ Shard 1
    ├─ Primary → es02
    └─ Replica → es01

一方、from_nodeにShard番号0のReplica Shardが配置されている場合は、Replica Shardが移動対象となります。このように、moveは既に配置されているShardを別のNodeへ再配置するためのコマンドであり、Nodeのメンテナンスや負荷分散などのためにShardの配置を変更したい場合に利用します。

実行後は、CAT Shards APIでShardが期待したNodeへ配置されたことを確認します。

GET _cat/shards?v

なお、Cluster Reroute APIはShardの配置を直接変更するAPIですが、Shardを配置できない根本原因を解決するものではありません。例えば、ディスク容量不足やAllocation Filteringなどの制約が残っている場合は、手動で配置を試みても失敗します。

そのため、まずAllocation Explain APIで原因を調査し、必要に応じて設定や環境を修正した上でCluster Reroute APIを利用することが重要です。

Stale Primary / Empty Primary

通常は、Primary Shardが失われた場合でも、Replica Shardが存在すれば、そのReplica Shardが新しいPrimary Shardへ昇格し、データを保持したままクラスターを復旧できます。

しかし、Primary ShardとReplica Shardの両方が利用できなくなった場合は、有効なShardコピーが存在しないため、ElasticsearchはPrimary Shardを自動的に割り当てることができません。このような場合、Allocation Explain APIでは can_allocate に no_valid_shard_copy が表示されることがあります。

このような状況で最後の手段として利用されるのが、Cluster Reroute APIの allocate_stale_primary と allocate_empty_primary です。

allocate_stale_primary

allocate_stale_primary は、最新ではない可能性があるShardコピー（Stale Copy）をPrimary Shardとして強制的に割り当てます。

POST _cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "blogs",
        "shard": 0,
        "node": "es01",
        "accept_data_loss": true
      }
    }
  ]
}

この例では、blogsインデックスのShard番号0について、es01に残っている古いShardコピーをPrimary Shardとして強制的に利用します。

この操作では、最新の更新内容が失われる可能性があるため、accept_data_loss: true の指定が必須です。

stale には “古い” という意味があります。

allocate_empty_primary

allocate_empty_primary は、既存データを一切利用せず、空のPrimary Shardを新規作成します。

POST _cluster/reroute
{
  "commands": [
    {
      "allocate_empty_primary": {
        "index": "blogs",
        "shard": 0,
        "node": "es01",
        "accept_data_loss": true
      }
    }
  ]
}

この例では、blogsインデックスのShard番号0について、es01に空のPrimary Shardを作成します。既存データは復元されず、そのShardに保存されていたデータは失われます。そのため、この操作も accept_data_loss: true の指定が必須です。

Stale PrimaryとEmpty Primaryの違い

どちらも通常運用で利用するAPIではありません。Snapshotからのリストアや、有効なShardコピーからの復旧ができない場合にのみ利用する最終手段です。試験では、それぞれの違いと、どちらも accept_data_loss: true が必須であることを理解しておけば十分です。

実践問題

本章では、Cluster HealthやUnassigned Shardの調査、Cluster Recoveryに関する実践問題を6問用意しています。ただし、これらは実際の試験の出題形式や出題内容を再現したものではありません。

各APIやコマンドの使い方を理解し、調査・復旧の流れを身に付けるための学習教材として活用してください。

Cluster HealthやShard診断はElastic Certified Engineer試験の公式試験範囲に含まれていますが、筆者が確認した公開されている受験記や体験談では、この分野が実際に出題されたという報告はほとんど見当たりませんでした。もちろん試験範囲である以上、出題される可能性はありますが、現時点では頻度は高くないと考えられます。

事前準備

blogs index 作成コマンド

PUT blogs
{
  "mappings": {
    "properties": {
      "authors": { "properties": { "first_name": { "type": "keyword" }, "last_name": { "type": "keyword" }, "uid": { "type": "keyword" } } },
      "authors_nested": { "type": "nested", "properties": { "first_name": { "type": "keyword" }, "last_name": { "type": "keyword" }, "uid": { "type": "keyword" } } },
      "category": { "type": "keyword" },
      "content": { "type": "text" },
      "is_trending": { "type": "boolean" },
      "location": { "type": "geo_point" },
      "location_shape": { "type": "geo_shape" },
      "popularity": { "type": "long" },
      "publish_date": { "type": "date" },
      "relations": { "type": "join", "eager_global_ordinals": true, "relations": { "blog": "comment" } },
      "title": { "type": "text" }
    }
  }
}

blogs index bulk コマンド

POST _bulk
{"index":{"_index":"blogs","_id":"1"}}
{"title":"Getting Started with Elasticsearch","content":"This article introduces the basics of Elasticsearch.","category":"search","popularity":120,"is_trending":true,"publish_date":"2026-07-01","location":{"lat":35.6895,"lon":139.6917},"location_shape":{"type":"point","coordinates":[139.6917,35.6895]},"authors":[{"first_name":"John","last_name":"Smith","uid":"u001"}],"authors_nested":[{"first_name":"John","last_name":"Smith","uid":"u001"}],"relations":"blog"}
{"index":{"_index":"blogs","_id":"2"}}
{"title":"Understanding Shard Allocation","content":"Learn how Elasticsearch allocates shards across nodes.","category":"cluster","popularity":250,"is_trending":true,"publish_date":"2026-07-03","location":{"lat":34.6937,"lon":135.5023},"location_shape":{"type":"point","coordinates":[135.5023,34.6937]},"authors":[{"first_name":"Alice","last_name":"Brown","uid":"u002"},{"first_name":"Bob","last_name":"Wilson","uid":"u003"}],"authors_nested":[{"first_name":"Alice","last_name":"Brown","uid":"u002"},{"first_name":"Bob","last_name":"Wilson","uid":"u003"}],"relations":"blog"}
{"index":{"_index":"blogs","_id":"3"}}
{"title":"Cluster Recovery Guide","content":"Recover your Elasticsearch cluster after node failures.","category":"recovery","popularity":180,"is_trending":false,"publish_date":"2026-07-05","location":{"lat":43.0642,"lon":141.3469},"location_shape":{"type":"point","coordinates":[141.3469,43.0642]},"authors":[{"first_name":"David","last_name":"Taylor","uid":"u004"}],"authors_nested":[{"first_name":"David","last_name":"Taylor","uid":"u004"}],"relations":"blog"}
{"index":{"_index":"blogs","_id":"4"}}
{"title":"Snapshot and Restore","content":"Back up and restore your Elasticsearch data using snapshots.","category":"backup","popularity":95,"is_trending":false,"publish_date":"2026-07-08","location":{"lat":35.0116,"lon":135.7681},"location_shape":{"type":"point","coordinates":[135.7681,35.0116]},"authors":[{"first_name":"Emma","last_name":"Johnson","uid":"u005"}],"authors_nested":[{"first_name":"Emma","last_name":"Johnson","uid":"u005"}],"relations":"blog"}
{"index":{"_index":"blogs","_id":"5"}}
{"title":"Troubleshooting Unassigned Shards","content":"Common causes of unassigned shards and how to resolve them.","category":"troubleshooting","popularity":310,"is_trending":true,"publish_date":"2026-07-10","location":{"lat":33.5902,"lon":130.4017},"location_shape":{"type":"point","coordinates":[130.4017,33.5902]},"authors":[{"first_name":"Chris","last_name":"Miller","uid":"u006"},{"first_name":"Sophia","last_name":"Davis","uid":"u007"}],"authors_nested":[{"first_name":"Chris","last_name":"Miller","uid":"u006"},{"first_name":"Sophia","last_name":"Davis","uid":"u007"}],"relations":"blog"}

Practice Question 1

Your Elasticsearch cluster is reporting an unhealthy status. Write the API command to check the cluster health.

回答

GET _cluster/health

解説

Cluster Healthを確認し、green、yellow、redのいずれであるかや、unassigned_shardsなどを確認する。障害発生時は、最初に実行するAPIである。

Practice Question 2

The Cluster Health API indicates that one or more shards are unassigned.

Write the API command to identify which shards are unassigned.

回答

GET _cat/shards?v

解説

CAT Shards APIを利用すると、

• 対象Index
• Shard番号
• Primary / Replica
• Shardの状態
• 配置されているNode

を確認できる。

Practice Question 3

The GET _cat/shards?v command returned the following result.

index   shard   prirep   state         node
blogs   0       p         STARTED       es01
blogs   0       r         UNASSIGNED

Write the API command to determine why the Replica shard cannot be allocated.

回答

GET _cluster/allocation/explain
{
  "index": "blogs",
  "shard": 0,
  "primary": false
}

解説

CAT Shards APIから対象Shardを特定し、Allocation Explain APIで割り当てられない原因を調査する。

Practice Question 4

The Allocation Explain API indicates that the shard cannot be allocated.

Write the API command to check whether disk usage on each node may be preventing shard allocation.

回答

GET _cat/allocation?v

解説

CAT Allocation APIでは、

• NodeごとのShard数
• ディスク使用量
• 空き容量
• Disk使用率

などを確認できる。

Disk Watermarkが原因でShard Allocationが拒否されていないかを調査する際にも利用する。

Practice Question 5

The Allocation Explain API indicates that shard allocation previously failed, and the root cause has already been resolved.

Write the API command to retry the failed shard allocation.

回答

POST _cluster/reroute?retry_failed=true

解説

retry_failedは、失敗したShard Allocationを再試行する。

このAPIは原因を解消するものではないため、Allocation Explain APIなどで原因を解消した後に実行する。

Practice Question 6

The failed shard allocation has been retried.

Write the API command to verify that the shard has been successfully allocated.

回答

GET _cat/shards?v

解説

Shardの状態がSTARTEDになっていること、および期待したNodeへ配置されていることを確認する。

Question 1～6は、次の流れに沿って構成しています。

Elastic社が提供する無料Hands-on Trainingで理解を深めよう

Elastic社では、Elastic Cloudを利用した無料のHands-on Trainingを提供しています。Cluster Healthの確認やShard Allocation、Snapshot、CCRなど、試験範囲に関連する機能を実際に操作しながら学習できます。

記事で学んだ内容を実践し、各APIの動作やレスポンスを確認することで、理解をさらに深められます。Elastic Certified Engineer試験の対策としても、Hands-on Trainingを一度体験しておくことをおすすめします。

Elastic Cloud アカウント作成
https://cloud.elastic.co/registration

Elastic Training
https://www.elastic.co/training

Elastic Learning Portal
https://learn.elastic.co/pages/58/home-page

試験ポイント

繰り返しになりますが、クラスター診断は試験範囲に含まれますが、出題頻度はそれほど高くはないと考えられます。代表的なAPIと診断手順を理解しておけば問題ないでしょう。

• status “green”、”yellow”、”red” の違いを理解しておく
• クラスター診断の流れで使用する代表的なコマンドを把握しておく