Elasticsearchの版を上げる作業でつまずくのは、ノードを一台ずつ入れ替える手順そのものではありません。上げ始めてから「この索引は9系では開けない」と分かる、上げたあとに「前の版へ戻せない」と気づく。止まるのは前提の確認漏れです。9.5系（2026年8月時点）の公式記述を実測し、経路の制約、索引の作成版の数え方、作り直しの分岐、退避計画までを実装の解像度で並べました。
まとめ：着手前に確定させる5つの値と結論
計画を書き始める前に、次の5点を数値で押さえてください。ここが空欄のまま日程を引くと、当日になって経路が塞がっていると判明します。
- 現在の稼働版：全ノードが同じ版か、混在していないか
- 索引の作成版：7系以前の索引が何本・何GB残っているか
- 目標版：9.0系で止めるのか、9.5系まで上げるのか
- 停止できる時間：無停止が要件か、数十分は止められるか
- 直近のスナップショット：いつ取り、復元を通したことがあるか
結論から言えば、8系から9系へ上げる経路は「8.19.xを踏んでから9系へ」が基本線です。8.18.xから9.0.xへ直接上げる例外はありますが、9.1.0以降を狙うなら8.19.xを経由します。そして7系以前で作られた索引が1本でも残っていると、ノードは起動しません。この仕分けを先に済ませておくのが、当日の停止時間を短くする最大の効きどころです。製品そのものの前提はElasticsearchとは？転置インデックスとシャード設計で扱っているため、本記事は稼働中のクラスタを新しい版へ引き上げる工程だけを持ちます。
現状把握｜稼働中のノード版と索引が作られた版を分けて数える手順
更新計画で最初に分けるべきなのは、「いまノードで動いている版」と「索引が作られたときの版」です。この二つは一致しません。8.15系のクラスタの中に、6系で作られたまま引き継がれた索引が残っている状態はふつうに起こります。更新を止めるのは、たいてい後者のほうです。
稼働版の確認｜ノード一覧とクラスタ情報のどちらを見て判断するか
クラスタ全体の代表値は、ルートへのGETリクエストが返す情報で分かります。ただし受け付けたノードが自分の版を返すだけなので、更新の途中では実態とずれます。全ノードを一台ずつ確かめるなら _cat/nodes にversionの列を出すほうが確実です。
ここで見たいのは代表値ではなく、ばらつきの有無になります。全ノードが同じ版で揃っているなら、そこが出発点です。二つの版が混じっているなら、前回の更新が途中で止まっている可能性を疑ってください。
作成版の確認｜索引の設定に残る生成時の値を見て対象を仕分ける
索引がどの版で作られたかは、索引の設定に index.version.created として残っています。索引を作った瞬間に刻まれる値で、その後クラスタをいくら上げても書き換わりません。中身を新しい索引へ入れ直したときに、はじめて新しい値が付きます。
仕分けの基準は明快です。9系へ上げるなら、7系以前で作られた索引は事前に処理しておく必要があります。作り直すか、削除するか、読み取り専用として保管するか。公式の記述は「互換性のない索引が残っているとノードは起動しない」と踏み込んでいて、警告ではなく起動失敗として現れます。
数え方としては、本数だけでなく合計サイズも取っておいてください。作り直しに要する時間は、おおむねデータ量に比例します。ログ系の索引で保持期間の設計が入っているなら、古い世代は期限切れで自然に消えるため、対象から外せる場合もあるでしょう。保持期間の設計はElasticsearchのログ収集とインデックス分割の設計で扱っています。古い世代を自動で落とすフェーズの組み方はElasticsearchのILMとフェーズ設計に整理しました。
非推奨情報の収集｜アップグレードアシスタントが出す指摘の読み方
非推奨の設定や、更新を妨げる要因の洗い出しには、アップグレードアシスタントが使えます。非推奨情報APIの結果を土台に、どの索引に作業が要るか、どの設定が消えるかを一覧にしてくれる仕組みです。
読み方の要点は、指摘の重さで扱いを変えないことです。公式は「アシスタントが報告した重大な問題はすべて解消しておく」と書いています。重大とされたものを残したまま進めれば、起動しないノードが出るでしょう。非推奨止まりの指摘は当日の障害になりませんが、次のメジャー版で消える予告でもあるため、この機会に片付けておくほうが手間は減ります。アシスタントの画面と権限まわりはElasticsearchとKibanaの連携と権限分離の内容が前提になります。
版の経路｜9.1以降へ上げるには8.19系を必ず踏む必要がある
メジャー版をまたぐ更新には、通ってよい経路が決まっています。任意の8系から任意の9系へ飛べるわけではありません。誤解したまま計画を書くと、当日に「このノードは起動を拒否した」という形で跳ね返ります。
8.18から9.0への例外｜どの組み合わせなら直接上げられるか
公式の記述は二段構えです。基本線は「8.xから9.xへのメジャー更新は、まず8.19.xへ上げる必要がある」。そのうえで例外として「8.18.xから9.0.xへの更新は対応する」と続きます。つまり9.1.0以降を目標にするなら、経路上に8.19.xが必ず入ります。
実務でこれが効くのは、目標版の決め方です。いま8.18系で動いていて9.0系で止めてよいなら一段で済みますが、9.5系まで上げたいなら8.18系から直接は行けません。8.19.xへ一度上げ、そこから9系へ入る二段構えになります。目標版をどこに据えるかで更新の回数が変わるため、保守期限の残りと必要な機能がどの版で入ったかを見比べて決めてください。
混在バージョンの許容範囲｜ローリング更新の最中だけという前提
ローリング更新の最中は、新旧の版が同じクラスタに同居します。これは想定された状態ですが、あくまで更新中に限った話です。公式は「混在バージョンのクラスタはローリング更新中だけ有効」と明記していて、恒常的に版を混ぜて運用する構成は対象外になります。
保守期限から逆算する着手時期｜8系の維持期限と9系の位置づけ
いつ着手するかは、保守期限から逆算するのが扱いやすくなります。公表されている期日では、8.x系の保守終了が2027年1月15日、サポート終了が2027年7月15日。9.x系は保守終了が2027年10月15日で、サポート終了は次のメジャー版の一般提供から18ヶ月後と定められています。
マイナー版の単位でも線が引かれていて、8.17は8.19のリリース日まで、8.18は9.2のリリース日まで維持されるという個別の扱いがあります。全体の方針は「一般提供から30ヶ月」と「次のメジャー版の一般提供から18ヶ月」の長いほうです。8系で動いているなら、2027年1月を境に修正の提供が止まる前提で日程を引き、索引の仕分けと予行に数ヶ月を見て着手時期を置いてください。
7系以前に作られた索引｜作り直す・読み取り専用にする・捨てるの三択
作成時の版が効く理由｜索引の形式の後方互換が1世代分しかない
なぜ作られた版が問題になるのか。Elasticsearchが内部で使う索引の形式は、一つ前のメジャー版までしか読めない設計になっているためです。9系は8系で作られた索引を読めますが、7系のものはそのままでは扱えません。データが壊れているわけではなく、読み出す側の形式対応が切られているという話です。長く使い続けているクラスタほど、この制約は重く効きます。
作り直しの二方式｜同一クラスタ内での入れ直しと別クラスタからの引き込み
書き込みを続ける索引は、作り直しが基本です。方式は、同一クラスタの中で新しい索引へ入れ直すやり方と、別に立てたクラスタから引き込むやり方の二つになります。
同一クラスタ内で完結するなら、追加の設定は要りません。新しい名前で索引を作り、中身を移し、別名を張り替える流れになります。一方、別クラスタからの引き込みでは、受け側のノード設定 reindex.remote.whitelist で相手先を明示的に許可しておく必要があります。ノード側に書く設定のため、受け側の再起動が要る点に注意してください。
そして所要時間の見積もりで効いてくる制約が一つあります。別クラスタからの引き込みは、手動・自動どちらの分割並列にも対応していません。同一クラスタ内なら処理を分割して並列に走らせられますが、リモート越しではそれができないため、大きな索引ほど時間が読みにくくなります。数百GB級を引き込む計画なら、実データの一部で速度を測ってから全体の日程を引いてください。
読み取り専用で残す選択｜アーカイブと検索可能スナップショット
参照しかしない古いデータなら、読み取り専用として保管する道があります。公式は9.xについて「アーカイブされた7.xの索引をスナップショット経由で読めるため、古いクラスタを再度立てる必要はない」と説明しています。書き込みを諦める代わりに、作り直しの時間を省ける選択です。
スナップショット側の互換もあわせて確認しておいてください。復元できる組み合わせは版の対応表で決まり、たとえば6.8で作られた索引は9.0.0〜9.5.2のクラスタへ復元できる一方、7.0〜7.1のクラスタへは復元できません。7.0〜7.17で作られた索引については、検索可能スナップショットとして扱う道も用意されています。
ただし、これを更新そのものの代わりにはできません。公式は「古いスナップショットを9.xへ直接復元することは、通常の更新経路の近道にはならない」と釘を刺しています。古い版から取ったスナップショットを新しい版へ流し込めば経路の制約を回避できる、という発想は通りません。更新後のクラスタで古いデータを参照し続けるための手段だと捉えてください。
ローリング更新の手順｜シャード割り当ての抑止とノードを上げる順序
止めずに上げる方式は、ノードを一台ずつ落として入れ替え、戻して次へ進む繰り返しです。順序と待ち方を外すと、無駄な再配置でクラスタを痛めます。
シャード割り当ての抑止と復帰｜再配置を止めてからノードを停止する
ノードを一台落とすと、クラスタはそこにあったシャードを他のノードへ配り直そうとします。数分後には戻るノードのために、大量のデータを移動させるわけです。これを避けるため、停止の前に cluster.routing.allocation.enable を primaries にして、レプリカの再配置を抑えます。
戻すときは null に設定して既定へ返します。all と書くと明示指定として残り続け、次の運用で意図しない挙動の原因になります。
ノードを上げる順序｜データ層から先に上げて管理役を最後に回す
ノードの役割ごとに上げる順序が決まっています。公式が示す並びは三段階です。
| 段 | 対象 | 並び |
|---|---|---|
| 1 | データノード | フローズン→コールド→ウォーム→ホット→コンテンツ |
| 2 | マスター・データ以外 | 機械学習・取り込み・調整など（順不同） |
| 3 | マスター適格ノード | master と voting_only |
各ノードでの作業は、割り当ての抑止と投入の一時停止、単一ノードの停止、版の入れ替え、設定の引き継ぎ、プラグインの更新、起動、割り当ての復帰、緑になるまで待機、の順です。
設定の引き継ぎで一点だけ注意があります。cluster.initial_master_nodes は書かないでください。新規クラスタの初回起動でだけ使う設定で、更新時に残っていると意図しないクラスタ形成を招きます。JVMやログの設定は新しい版の書式へ合わせ、プラグインもノードと同じ版に揃えます。
全ノードを止めて一括で上げる場面｜短時間で終わる代わりの制約
もう一つの方式が、全ノードを止めて一斉に上げるやり方です。無停止という利点は捨てることになりますが、混在期間が生じないぶん手順は単純で、待ち時間の総和も短くなります。
選び分けの目安は、止められる時間があるかどうかに尽きます。夜間に1時間止められる社内向けの検索基盤なら、一括のほうが速く終わるでしょう。24時間動く顧客向けなら、ローリング一択です。台数が多いほどローリングの総所要は伸びるため、10台超で数時間の停止が許されるなら一括を検討する価値があります。
非互換の洗い出し｜9系で消えた設定とAPIを先に突き合わせる
削除された設定と機能｜起動が止まる組み合わせを先に潰しておく
9.0で消えた設定のうち、実務で当たりやすいものを挙げます。単一データノード向けのディスク水位設定 cluster.routing.allocation.disk.watermark.enable_for_single_data_node、古い client.type、検索可能スナップショットの割り当て設定、非推奨だった tracing.apm.* の一式です。ログのキーワードも deprecation.elasticsearch から elasticsearch.deprecation へ変わり、ログ基盤側で拾っている場合は取りこぼしが出ます。
APIでは、エイリアスの local 属性、フローズン索引の読み取りと解除用エンドポイント、技術プレビューだった _knn_search、user_agentプロセッサの ecs オプション、GeoIPプロセッサの fallback オプションが削除されました。bulk APIのアクション解析は厳格になり、これまで通っていた緩い記述が弾かれる場合があります。挙動の変化としては、range クエリの旧パラメータ削除と、random_score の既定フィールドが _seq_no になった点があります。
起動そのものを止める変更もあります。LDAPやActive Directoryのバインド用DNをパスワードなしで設定している場合、9系ではノードが起動しません。認証連携を入れているなら必ず事前に確認してください。通信面では既定のプロトコルから TLSv1.1 が外れ、JDK 24 環境では TLS_RSA 系の暗号スイートも外れており、古いクライアントが接続できなくなる可能性があります。
プラグインとクライアント｜接続層で書き換えが出る箇所を確認する
プラグイン側では、discovery-ec2 と repository-s3 がAWS SDK v2前提へ移りました。IMDSv2への対応とリージョン指定まわりで設定の見直しが要ります。S3をスナップショット置き場にしているなら、更新後に退避が動かなくなる事態を避けるため、予行環境で取得と復元まで通してください。
クライアント側は、アプリケーションが使っているライブラリの版を確認します。ES|QLでは索引パターンの記法が厳格化され、括弧を含む記述や引用の混在が弾かれるようになりました。クエリを文字列で組み立てている箇所があるなら、そこも点検の対象です。組み立て方の基本形はElasticsearchのクエリDSLと結果集合の制御で扱っています。なお、接続先の製品そのものを乗り換える判断はElasticsearchとOpenSearchの違いと移行先の決め方の領分で、版を上げるのか系列を変えるのかは別の意思決定として分けて考えてください。
戻せない前提での退避計画｜スナップショットと本番前の予行の段取り
更新作業で最も重い制約が、降格ができないことです。ここを外すと、退避計画が形だけのものになります。
降格ができないという制約｜途中で止めたときに残る選択肢は一つ
公式の表現は明確で、クラスタの更新を始めたあとは、どのノードも降格できないと書かれています。少なくとも1台が新しい版で動き出した時点で、巻き戻せない更新が内部で始まる場合があります。「様子を見て、まずければ戻す」という進め方は成立しません。
途中で止めた場合に残る選択肢は一つです。空のクラスタを新しく作り、更新前に取ったスナップショットから復元する。これが唯一の復路になります。つまり退避計画の実体は、スナップショットが取れていることと、そこから復元できると確かめてあることの二点に集約されます。
復旧手順を先に通す｜別クラスタへ復元して切り替えるまでの段取り
スナップショットは、取れていることと復元できることが別の話です。取得の設定だけ入れて、復元を一度も通していない現場は珍しくありません。更新の前に別のクラスタで実際に復元すれば、所要時間が測れ、置き場の権限設定の不備も露見します。
段取りとしては、更新直前にスナップショットを取り、その内容と時刻を記録し、切り戻しの判断期限を決めておきます。判断期限とは「この時刻までに緑へ戻らなければ復元へ切り替える」という線です。作業中に判断すると、もう少し待てば直るかもという気持ちが働き、決断が遅れます。
予行環境の作り方｜本番と同じ版の並びと索引だけを小さく再現する
予行は、本番と同じ版から同じ版へ、同じ経路で一度通すことに意味があります。台数やデータ量は縮めてかまいませんが、出発点の版と索引の作成版だけは揃えてください。ここが揃っていないと、起動失敗という最も重い事象を再現できません。
手軽に作るなら、コンテナで小さなクラスタを立てて、本番からスナップショットを復元する方法が使えます。構築の実際はElasticsearchのDocker構築とcompose定義で扱っていて、そこで示した3ノード構成をそのまま予行の土台にできます。予行で測るのは、索引の作り直しの時間、1ノードあたりの入れ替えと緑復帰までの時間、復元の所要時間の三つです。ここが分かれば、本番の作業計画は実測値で書けます。
自前で上げてよい条件と、委託やマネージドへ切り替える判断の線引き
最後に、この作業を自前で進めてよいのかという判断です。手順は公開されており、成否を分けるのは手順の理解より体制のほうになります。
自前で進めてよい条件｜次の三つが揃っているかどうかで判断する
次の三つが揃っているなら、自前で進めて問題ありません。一つ目、索引の作成版を数えた結果、7系以前のものが無いか、あっても読み取り専用への切り替えで済む見込みが立っていること。二つ目、スナップショットからの復元を予行で通してあること。三つ目、当日に切り戻しの判断ができる担当者が確保できていること。
一つでも欠けたまま当日を迎えると、想定外が起きたときに動けません。特に三つ目は見落とされがちで、手順を実行する人と止めるかどうかを決める人は別の役割だと考えてください。上げたあとに性能が落ちた場合の調整はElasticsearchのチューニングと遅いクエリの特定手順の範囲になります。
見送る場面｜停止時間と人手が確保できないときの二つの代替経路
見送りを検討すべきなのは、次のような状況です。無停止が要件だが台数が少なくレプリカに余裕がない、7系以前の索引が数百GB規模で残っていて作り直しの時間が読めない、運用担当が兼務で当日の張り付きが難しい。いずれも自前の更新は途中で止まりやすくなります。
代替経路は二つあります。一つは、マネージドサービスへ寄せて版の管理を外へ出すこと。運用の分担がどう変わるかはAmazon OpenSearch Serviceの構築と運用で整理しています。もう一つは、移行そのものを外部に任せることです。稼働中の検索基盤を新しい版へ引き上げる作業、旧版で作られた索引の作り直し、停止時間を切り詰めた切り替え計画は、システムマイグレーション・リプレイスでそのまま引き受けています。保守期限が迫っていて日程に余裕がないなら、早めに相談したほうが選べる手が多く残ります。
よくある質問
8.15系から9.5系へ一度に上げられますか？
できません。8系から9系へのメジャー更新では、まず8.19.xへ上げる必要があります。8.18.xから9.0.xへの例外はありますが、9.1.0以降を狙うなら8.19.xの経由が入るため、8.15系からは二段の計画になるでしょう。
更新したあとで前の版へ戻せますか？
戻せません。クラスタの更新を始めたあとは、どのノードも降格できないと明記されています。前の状態に戻す唯一の方法は、空のクラスタを作り、更新前のスナップショットから復元することです。だからこそ、着手前に復元まで通しておく必要があります。
7系で作られた索引を残したまま9系へ上げるとどうなりますか？
ノードが起動しません。互換性のない索引が残っているとノードは起動しない、というのが公式の記述です。事前に作り直すか、読み取り専用として保管するか、削除するかを選んでおいてください。参照しかしないなら、アーカイブが有利です。
ローリング更新の途中で一度中断してもよいですか？
おすすめしません。混在バージョンのクラスタが有効なのはローリング更新の最中だけで、同時に動く版も2つまでという線が引かれています。中断すると混在期間が延び、途中で止めた場合は前の版へ戻せません。着手したら最後まで通す前提で日程を組んでください。
別クラスタから引き込む作り直しは、どれくらい時間がかかりますか？
データ量と回線に依存しますが、同一クラスタ内より遅くなると見てください。別クラスタからの引き込みは手動・自動いずれの分割並列にも対応しておらず、処理を分けて並列に走らせる手が使えません。実データの一部で速度を測ってから全体を見積もる進め方が確実です。
関連記事
- Elasticsearchの仕組みとシャード設計・採用可否：製品そのものの前提です
- ElasticsearchとOpenSearchの違いと移行先の決め方：系列を変える判断はこちらです
- ElasticsearchのDocker構築とcompose定義：予行環境の構成例です
- Elasticsearchのチューニングと遅いクエリの特定：更新後の測り直しです
- Elasticsearchのログ収集と保持期間の設計：古い索引を減らす設計です
