MongoDB は定期的に新しいバージョンをリリースします。これらのバージョンをどのように受け取るか、およびタイミングをどの程度制御できるかは、 MongoDB の実行方法によって異なります。配置タイプに応じて、新しいバージョンの実行中を異なる方法で準備する必要があります。
このページでは、 MongoDBのバージョン番号の平均、リリースの種類、およびアップグレードの一般的な仕組みについて説明します。配置に固有の手順とポリシーについては、全体のリンクを参照してください。
MongoDB のバージョンへの番号付け方法
MongoDB のバージョン番号は X.Y.Z の形式をとります。
X はメジャー バージョンです。ここでの変更は、下位互換性のない変更や、以前のバージョンでは読み取れない形式でデータを保持する新機能を含むリリースを示します。
Y はマイナー バージョンです。マイナー リリースはメジャー リリース間で機能を段階的に提供します。可用性は配置タイプによって異なります。
Z は、パッチのバージョンです。パッチ リリースには修正が含まれており、リリース シリーズ内で下位互換性があります。
ドライバー、 MongoDB Shell、およびMongoDB Database Tools のバージョンは、データベースサーバーとは独立しています。ドライバーのバージョン番号は、サーバーのバージョン番号には対応しません。どのドライバー バージョンがどのサーバーバージョンで動作するかを確認するには、ドライバーの互換性ページを参照してください。
リリース タイプ
メジャー リリース
メジャー リリースでは新機能が導入され、下位互換性のない変更が含まれる場合があります。 MongoDB は、Atlas と自己管理型配置の両方のメジャー リリースをサポートしています。
マイナー リリース
マイナー リリースは、メジャー リリース間でより高速なケイデンスで機能を提供します。
MongoDB8.2 以降、マイナー リリースは、Atlas Core Autoアップグレード、Enterprise Advanced、Community の自己管理型配置で利用できます。
MongoDB9.0 以降、マイナー リリースは Atlas Core の自動アップグレードでのみ利用可能で、Atlas Core の手動アップグレードと自己管理型配置では使用できません。インクリメンタル機能リリースについては、「 機能更新リリース 」を参照してください。
注意
マイナー リリースでは、Atlasライブ移行と mongosync など、すべての機能がサポートされていない場合があります。
機能更新リリース
MongoDB9.0 x.5以降、機能更新リリースは、Atlas および自己管理型型配置で利用可能な 番号の年ごとのマイナー リリースです。機能更新リリースにより、Atlas Core 手動アップグレードと自己管理型型配置に、次のメジャー バージョンを待たずに機能を段階的に取得できるようになります。サポート終了のタイムラインと延長ライフサイクルのサポート資格は、拡張するメジャー バージョンと同じです。
重要
MongoDB9.0 以降のすべてのマイナー リリースを受け取るには、Atlas クラスターを Latest Version With Auto Upgradesに構成します。その他のすべての配置は、機能更新リリースの対象となるだけで、他のマイナー リリースでは対象外です。
パッチ リリース
パッチ リリースには修正が含まれており、メジャー リリースおよびマイナー リリース シリーズ内でのみ下位互換性があります。メジャー バージョンとマイナー バージョンの最新のパッチ リリースを常に実行する必要があります。
リリース候補
リリース候補は、新機能を評価することを目的としたリリース前ビルドです。これらは本番環境の配置には適していません。
MongoDB がリリースを番号付けする方法とスケジュールする方法の詳細については、 「 MongoDB のバージョン管理 」を参照してください。
リリースが配置にどのように影響するか
MongoDB のリリースは、自己管理型配置で使用可能になる前に Atlas に到達します。
重要
最新バージョンを受け取るように構成された Atlas Core Autoアップグレード クラスターは、そのリリースが自分自身にダウンロードしてインストールできるようになる前に、リリースを実行する場合があります。
これが実際に何を意味するかは、 MongoDB の実行方法によって異なります。
Atlas Core の手動アップグレード クラスターは、ユーザーが管理するメジャー バージョンのケイデンスに維持されます。
Atlas Core Autoアップグレード クラスターは、Atlas が新しいバージョンをロールアウトすると自動的に新しいバージョンを受け取ります。
自己管理型（Enterprise Advanced または Community）の配置では、各リリースをダウンロードしてインストールするタイミングを選択できます。実行するまで何も変わりません。
機能の互換性バージョン
MongoDBバイナリのアップグレードと新しいバージョンの機能の有効化は 2 つの別々の手順です。
機能の互換性バージョン（FCV） は、以前のバージョンが読み取りできない形式でデータを書込む機能を有効にするかどうかを制御します。バイナリをアップグレードした後も、引き上げるまで配置は以前の FCV で実行され続けます。これは意図的なもので、FCV は以前のバージョンのままである間は、ダウングレードの能力を保持します。
注意
Atlas Core 自動アップグレードでは、 MongoDBバイナリのロールアウト シグナルを自動的に検討した後、Atlas は FCV を新しいMongoDB の各バージョンに一致するように自動的にアップグレードします。 FCV を制御 しない 場合。
FCV を引き上げても、戻りがない点です。新しい形式でデータを保持する機能が有効になると、Atlas ではダウングレードはできなくなります。
コマンド参照については、 MongoDBマニュアルの setFeatureCompatibilityVersion を参照してください。アップグレード前に FCV を固定するなど、Atlas で FCV がどのように機能するかについては、「 クラスターのメジャーMongoDBバージョンをアップグレードする 」を参照してください。
ライフサイクルとサポート終了をサポートする
各MongoDBメジャー バージョンは 5 年間サポートされ、オプションとして 2 年間の 延長ライフサイクル サポート（ELS） 期間が Enterprise Advanced カスタマーに利用可能です。あるバージョンのサポートが終了すると、セキュリティ上の修正を含む修正は行われなくなり、 MongoDB はドキュメントを維持できなくなります。
処理は配置タイプによって異なります。
Atlas では、 MongoDB はバージョンのサポートが終了する前に、バージョンの期限を通知します。その日付の後、Atlas ではクラスターがMongoDBの現在のデフォルトのターゲット バージョンにアップグレードされます。
重要
MongoDBの現在のデフォルトのターゲット バージョンは、必ずしも直後のメジャー バージョンではありません。
自己管理型配置では、サポートが終了する前にアップグレードする必要があります。
現在、どのプラットフォームでどのバージョンがサポートされているかを確認するには、 「 MongoDB Enterpriseでサポートされているプラットフォーム 」または「 MongoDB Community でサポートされているプラットフォーム 」を参照してください。
アップグレード パスの選択
を実行する場合 | バージョン ケイデンス | ここを開始します。 |
|---|---|---|
Atlas Core 手動アップグレード | 次のメジャー バージョンに移行するタイミングを選択します。 | |
Atlas Core の自動アップグレード | Atlas によって自動的にアップグレードされます。メンテナンスウィンドを使用して環境全体の順序を制御します。 | |
Enterprise Advanced | を選択します。 | |
Community | を選択します。 |
自己管理型アップグレードに関する考慮事項
自己管理型配置の場合、アップグレード手順はトポロジーによって異なります。各リリースのアップグレード ページは、スタンドアロン、レプリカセット、およびシャーディングされたクラスター の手順にリンクします。
9.0 より前のバージョンのMongoDBでは、自己管理型型配置をアップグレードするときにマイナー リリースをスキップできません。マイナー リリース間を移動するには、順番にそれぞれをアップグレードする必要があります。
MongoDB 9.0 以降、Enterprise Advanced 配置では、メジャー リリースに加えて、年次の 機能更新 リリースのみが提供されます。リリース サイクル内でスキップするマイナーのシーケンスはなくなりました。
アップグレードする前に
配置のタイプにかかわらず、メジャー バージョン アップグレードの前に次の 3 つの操作を行う必要があります。
アプリケーションが本番環境に達する前に、新しいバージョンに対してテストしてください。
これをどのように実現するかは、配置によって異なります。
自己管理型: 最初に非本番環境の配置をアップグレードします。
Atlas Core の手動アップグレード: ターゲット バージョンを実行中ステージング クラスターを作成し、それに対してテストします。 「 クラスターのメジャーMongoDBバージョンをアップグレードする 」を参照してください。
Atlas Core の自動アップグレード: メンテナンス 頻度を使用してステージングと本番環境のシーケンス処理は可能ですが、ロールアウトが停止しない可能性があり、アップグレードタイミングを完全に制御できないためです。
重要
リリースの検証にさらに時間が必要な場合は、代わりにメジャー バージョンのケイデンスを使用してください。メンテナンス 頻度の詳細については、「 クラスター メンテナンスの管理 」を参照してください。
ダウングレード
ダウングレードは制約されており、制約は配置タイプによって異なります。配置タイプを選択すると、適用される制約を確認できます。
ダウングレードするには、最初のアップグレード前に FCV が発生しないか、固定されていた必要があります。
クラスターは、直前のリリース（前のメジャー バージョンまたはそのメジャー バージョンの機能更新リリースのいずれか）にのみダウングレードでき、ダウングレードは複数のバージョンにまたがって連鎖することはできません。
機能更新リリース上のクラスターは、独自のメジャー バージョンにダウングレードできます。
ほとんどの例外を除き、ダウングレードは対象バージョンの最新パッチ リリースに適用されます。
ダウングレード後は、新しいバージョンで導入された機能は使用できなくなり、 MongoDB は新しい下位位置からの 2 つ目のダウングレードをサポートしていません。
クラスターをダウングレードすることはできません。
注意
ダウングレードの対象となるメジャーバージョンのケイデンスに移行するには、メジャーバージョンのリリース後（
x.0.0）、そのサイクルの最初のマイナーリリースの前に（ ）、セルフサービスアクションとしてx.1.0を切り替えます。詳細については、「 自動アップグレードを使用した最新バージョン 」を参照してください。
- ダウングレードは連続するバージョン間でのみサポートされ、クラスター構成に固有の手順が必要です。
ダウングレードするには、最初のアップグレード前に FCV が発生しないか、固定されていた必要があります。
クラスターは、直前のリリース（前のメジャー バージョンまたはそのメジャー バージョンの機能更新リリースのいずれか）にのみダウングレードでき、ダウングレードは複数のバージョンにまたがって連鎖することはできません。
機能更新リリース上のクラスターは、独自のメジャー バージョンにダウングレードできます。
ほとんどの例外を除き、ダウングレードは対象バージョンの最新パッチ リリースに適用されます。
ダウングレード後は、新しいバージョンで導入された機能は使用できなくなり、 MongoDB は新しい下位位置からの 2 つ目のダウングレードをサポートしていません。
詳細
Atlas のリリース ケイデンス オプションを確認するには、Atlas のMongoDB のバージョン
Atlasデータベースエディションの詳細については、 「 MongoDB Atlas Core: 概要 」および「 MongoDB Atlas Infinite: 概要 」を参照してください。