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