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 のみを受け入れます)。 このような場合、クライアントはアップグレードが完了するのを待ってから、変更ストリームを再開する必要があります。
セカンダリのアップグレード
各セカンダリを以下のように個別にアップグレードします。
mongod
MongoDB インスタンスのアップグレード の手順に従って、セカンダリの バイナリをアップグレードします。セカンダリをアップグレードした後、次のインスタンスをアップグレードする前に、セカンダリが
SECONDARY
状態に回復するまで待機します。メンバーの状態を確認するには、mongosh
でrs.status()
を発行します。セカンダリは一時的に
STARTUP2
またはRECOVERING
になる場合がありますが、これは正常です。セカンダリが完全にSECONDARY
に回復してから、アップグレードを続行します。
プライマリのアップグレード
プライマリを降格して、通常のフェイルオーバー手順を開始します。次のいずれかを使用します。
mongosh
のrs.stepDown()
ヘルパーreplSetStepDown
データベース コマンド
セットは、フェイルオーバー中は書き込みを受け付けません。通常、これには 10 秒から 20 秒かかります。事前定義されたメンテナンスウィンドウ中にアップグレードが実行されるように計画します。
注意
プライマリを直接シャットダウンするより、プライマリを降格することをおすすめします。降格により、フェイルオーバー プロセスが迅速化します。
プライマリが退場したら、別のメンバーが
PRIMARY
状態になったことを確認するまで、mongosh
からrs.status()
メソッドを呼び出します。元のプライマリをシャットダウンし、「MongoDB インスタンスのアップグレード」の手順に従ってインスタンスをアップグレードします。
シャーディングされたクラスターのアップグレード
バージョン3.4での変更: この手順は5.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
でストリームを再開するために使用することはできません。
5.0のシャーディングされたクラスターをアップグレードするには、以下を実行します。
「バランサーの無効化」の説明に沿って、クラスターのバランサーを無効にします。
コンフィギュレーションサーバーをアップグレードします。
コンフィギュレーションサーバーのレプリカセットをアップグレードするには、「レプリカセットのアップグレード 」の手順に従います。
各シャードをアップグレードします。
シャードがレプリカセットである場合は、「レプリカセットのアップグレード」という手順を使用してシャードをアップグレードします。
シャードがスタンドアロン インスタンスの場合は、「 MongoDB インスタンスのアップグレード 」という手順を使用してシャードをアップグレードします。
構成サーバーおよびシャードがアップグレードされたら、「MongoDB インスタンスのアップグレード」の手順に従って、各
mongos
インスタンスをアップグレードします。mongos
インスタンスは任意の順序でアップグレードできます。「バランサーの有効化」の説明に沿って、バランサーを再度有効にします。