MongoDB のバージョン番号は X.Y.Z の形式で、Z はパッチのリリース番号です。パッチ リリースは、セキュリティ パッチ、バグ修正、新機能、変更された機能のいずれかを提供するためのもので、通常下位互換性を損なう変更は含まれません。常にリリース シリーズの最新のパッチ リリースにアップグレードしてください。
Atlas のメジャー アップグレードやマイナー アップグレードを含むバージョン管理について詳しくは、「 MongoDB のバージョン管理 」を参照してください。
このタスクについて
このページでは、MongoDB 8.0リリース シリーズのアップグレード手順について説明します。異なるリリース シリーズをアップグレードするには、対応するバージョンのマニュアルを参照してください。
始める前に
アップグレードに向けてご利用の環境の準備が整っているか確認するには、以下のセクションをご覧ください。
バックアップ
データセットのバックアップが最新の状態であることを確認してください。 「自己管理型配置のバックアップ メソッド 」を参照してください。
互換性に関する考慮事項
MongoDB リリース特有の重要な注意点や互換性の問題については、次のドキュメントを参照してください。
メンテナンスウィンドウ
インストールににレプリカセットが含まれている場合は、事前定義されたメンテナンスウィンドウ中にアップグレードが実行されるように設定します。
ステージング環境のチェック
このドキュメントの手順に沿って、本番環境をアップグレードする前に、本番環境と同様のステージング環境をアップグレードしてください。アップグレードする前に、本番環境の構成がすべての変更に対応していることを確認してください。
手順
mongod バイナリと mongos バイナリを、それぞれ個別にアップグレードします。次の手順に沿ってアップグレードを行います。
認証を使用する配置の場合は、まずすべての MongoDB ドライバーをアップグレードします。アップグレードするには、「ドライバーのドキュメント」を参照してください。
すべてのスタンドアロン インスタンスをアップグレードします。 「 MongoDB インスタンスのアップグレード 」を参照してください。
「レプリカセットのアップグレード」の説明に従って、シャーディングされたクラスターの一部ではないレプリカセットをアップグレードします。
「 シャーディングされたクラスターのアップグレード 」の説明に従って、シャーディングされたクラスターをアップグレードします。
機能の互換性バージョン（FCV）を確認
バイナリをアップグレードする前に、配置の関連するすべてのコンポーネントで featureCompatibilityVersion が完全にアップグレードされていることを確認してください。以前の FCV のアップグレードが正常に完了しなかった場合、より高いバージョンでバイナリを再起動すると、ノードがクラッシュする可能性があります。
FCV を確認するには、レプリカセットの各ノードに接続し、次のコマンドを実行します。
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
すべてのノードは、次の内容を含む結果を返す必要があります。
"featureCompatibilityVersion" : { "version" : "8.0" }
すべてのコンフィギュレーションサーバーとシャードに対して同じチェックを実行します。
レプリカセットであるシャードの場合は、レプリカセットの各ノードの FCV を確認します。
スタンドアロンのシャード インスタンスの場合は、インスタンスで コマンドを直接実行します。
バイナリのアップグレードを続行する前に、すべてのメンバーが必要な FCV を報告するまで待ってください。
MongoDB インスタンスのアップグレード
8.0 の mongod または mongos インスタンスをアップグレードするには、次のいずれかの方法で行います。
オペレーティング システムのパッケージ管理ツールと公式のMongoDBパッケージを使用して、インスタンスをアップグレードする方法がおすすめです。8.2 アップグレード手順 を参照してください。
既存のバイナリを新しいバイナリに置き換えて、 インスタンスをアップグレードします。 「既存のバイナリの置き換え 」を参照してください。
既存のバイナリの置き換え
このセクションでは、既存のバイナリの置き換えによってMongoDBをアップグレードする方法について説明します。オペレーティング システムのパッケージ管理ツールと公式のMongoDBパッケージを使用して、インスタンスをアップグレードする方法がおすすめです。詳しくは、「 アップグレード手順8.2 」を参照してください。
以下は、既存のバイナリを置き換えて、mongod インスタンスまたは mongos インスタンスをアップグレードする方法です。
MongoDB ダウンロード ページ から最新の MongoDB パッチ リリースのバイナリをダウンロードし、一時的な場所に保存します。バイナリは圧縮ファイルとしてダウンロードされ、MongoDB インストールで使用されるディレクトリ構造に解凍されます。
インスタンスをシャットダウンします。
既存の MongoDB バイナリをダウンロードしたバイナリに置き換えます。
必要に応じて、構成ファイルを変更します。
インスタンスを再起動します。
レプリカセットのアップグレード
8.0 レプリカセットをアップグレードするには、セカンダリからプライマリまで、各メンバーを個別にアップグレードします。事前に決定されたメンテナンスウィンドウ中にアップグレードが実行されるように計画します。
重要
レプリカセットをアップグレードまたはダウングレードする前に、すべてのレプリカセット ノードが実行されていることを確認してください。そうしないと、すべてのノードが起動されるまでアップグレードまたはダウングレードは完了しません。
セカンダリのアップグレード
各セカンダリを以下のように個別にアップグレードします。
mongodMongoDB インスタンスのアップグレード の手順に従って、セカンダリの バイナリをアップグレードします。セカンダリをアップグレードした後、次のインスタンスをアップグレードする前に、セカンダリが
SECONDARY状態に回復するまで待機します。メンバーの状態を確認するには、mongoshでrs.status()を発行します。セカンダリは一時的に
STARTUP2またはRECOVERINGになる場合がありますが、これは正常です。セカンダリが完全にSECONDARYに回復してから、アップグレードを続行します。
プライマリのアップグレード
プライマリを降格して、通常のフェイルオーバー手順を開始します。次のいずれかを使用します。
mongoshのrs.stepDown()ヘルパーreplSetStepDownデータベース コマンド
セットは、フェイルオーバー中は書き込みを受け付けません。通常、これには 10 秒から 20 秒かかります。事前定義されたメンテナンスウィンドウ中にアップグレードが実行されるように計画します。
注意
プライマリを直接シャットダウンするより、プライマリを降格することをおすすめします。降格により、フェイルオーバー プロセスが迅速化します。
プライマリが退場したら、別のメンバーが
PRIMARY状態になったことを確認するまで、mongoshからrs.status()メソッドを呼び出します。元のプライマリをシャットダウンし、「MongoDB インスタンスのアップグレード」の手順に従ってインスタンスをアップグレードします。
シャーディングされたクラスターのアップグレード
8.0のシャーディングされたクラスターをアップグレードするには、以下を実行します。
「バランサーの無効化」の説明に沿って、クラスターのバランサーを無効にします。
コンフィギュレーションサーバーをアップグレードします。
コンフィギュレーションサーバーのレプリカセットをアップグレードするには、「レプリカセットのアップグレード 」の手順に従います。
各シャードをアップグレードします。
シャードがレプリカセットである場合は、「レプリカセットのアップグレード」という手順を使用してシャードをアップグレードします。
シャードがスタンドアロン インスタンスの場合は、「 MongoDB インスタンスのアップグレード 」という手順を使用してシャードをアップグレードします。
構成サーバーおよびシャードがアップグレードされたら、「MongoDB インスタンスのアップグレード」の手順に従って、各
mongosインスタンスをアップグレードします。mongosインスタンスは任意の順序でアップグレードできます。「バランサーの有効化」の説明に沿って、バランサーを再度有効にします。