このドキュメントの内容をよく読み、前提条件を十分に確認してから、 MongoDB 9.0 にアップグレードしてください。
次の手順では、シャード メンバーであるmongodをバージョン8.0から9.0にアップグレードする手順について説明します。
9.0へのアップグレードに関するガイダンスが必要な場合は、 MongoDB プロフェッショナル サービスがメジャー バージョン アップグレード サポートを提供して、MongoDB アプリケーションを中断することなくスムーズに移行できるようにします。
アップグレードの推奨事項とチェックリスト
アップグレードの際には、次の点を考慮してください。
アップグレード バージョン パス
既存のMongoDBデプロイを9.0 にアップグレードするには、8.0 または 8.3 リリースを実行中いる必要があります。
8.0シリーズより前のバージョンの場合、最終的に8.0シリーズになるまで、メジャー リリースを順次アップグレードする必要があります。 たとえば、7.0 シリーズを実行している場合、 にアップグレードする8.0 前に 、 まず にアップグレード9 する必要があります。0 。
ドライバーの互換性を確認
MongoDBをアップグレードする前に、 MongoDB9.0 との互換性があるドライバーを使用していることを確認してください。 MongoDB. との互換性を確認するには、特定の ドライバー9 の ドライバー0 のドキュメントを参照してください。
互換性のないドライバーでアップグレードを実行した場合、予期しないまたは未定義の動作が発生する可能性があります。
事前対策
アップグレードを開始する前に、ドキュメント「 MongoDB 9.0での互換性の変更 」で、ご利用のアプリケーションとデプロイが MongoDB 9.0と互換性があることを確認してください。 アップグレードを開始する前に、お使いの環境の互換性の問題を解決してください。
MongoDB をアップグレードする際は、アップグレードを本番環境にデプロイする前に、必ずアプリケーションをステージング環境でテストします。
ダウングレードの検討事項
MongoDB 8.3 以降では、 MongoDBのバージョンをその前のマイナーまたはメジャー バージョンにダウングレードできます。
MongoDB は 1 つのバージョンのダウングレードのみをサポートします。現在のリリースより数バージョン前のリリースにダウングレードすることはできません。
例、9.0 シリーズの配置を 8.0 シリーズにダウングレードできます。ただし、8.0 シリーズの配置から 7.0 シリーズの配置へのさらなるダウングレードはサポートされていません。
前提条件
全ノードのバージョン
シャーディングされたクラスターを9.0 8.08.38.0にアップグレードするには、クラスターのすべてのノードがバージョン または を実行している必要があります。アップグレード プロセスでは、クラスターのすべてのコンポーネントがチェックされ、いずれかのコンポーネントが8.3 8390より前のバージョンを実行中いる場合は警告が発せられます。シャーディングされたクラスターを からアップグレードするには、「. から.7 0シャードクラスタへのアップグレード 」を参照してください。シャーディングされたクラスターを.8 0シリーズ以前からアップグレードするには、まずシャーディングされたクラスターのすべてのノードを最新の. シリーズのリリースにアップグレードしてから、次にMongoDB8 09からアップグレードする手順に従います。. から.0 へ
機能の互換性バージョン
8.0 のシャーディングされたクラスターでは、featureCompatibilityVersion を 8.0 に設定する必要があります。
シャーディングされたクラスターのすべてのノードで、 が に設定されていることを確認するには、各シャードレプリカセットノードと各コンフィギュレーションサーバーレプリカセットノードに接続します。次に、featureCompatibilityVersion 8.0featureCompatibilityVersionを確認します。
Tip
アクセス制御が有効になっているシャーディングされたクラスターの場合、シャード レプリカセット ノードに対して次のコマンドを実行するには、シャード ローカル ユーザー としてノードに接続する必要があります。
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
"featureCompatibilityVersion" : { "version" : "8.0" }
featureCompatibilityVersionを設定または更新するには、 mongosで次のコマンドを実行します。
db.adminCommand( { setFeatureCompatibilityVersion: "8.0", confirm: true } )
レプリカセット ノードの状態
シャードとコンフィギュレーションサーバーでは、レプリカセット ノードがROLLBACKまたはRECOVERING状態になっていないことを確認します。
db.adminCommand( { replSetGetStatus: 1 } )
configデータベースのバックアップ
任意ですが推奨します。注意事項として、シャーディングされたクラスターをアップグレードする前に、configデータベースのバックアップを作成してください。
ダウンロード9.0 バイナリ
パッケージ マネージャーの使用
MongoDB を MongoDB apt 、 yum 、 dnf 、またはzypperリポジトリからインストールした場合、パッケージ マネージャーを使用して9.0にアップグレードする必要があります。
Linuxシステムの場合は、9.0 のインストール手順を参照してください。新しいリリース用にリポジトリを追加して、実際にアップグレードする必要があります。
ダウンロード9.0 手動でバイナリ化
パッケージ マネージャーを使用して MongoDB をインストールしていない場合は、 MongoDB ダウンロード センターから MongoDB バイナリを手動でダウンロードできます。
詳しくは、 9.0インストール手順を参照してください。
アップグレード手順
バランサーを無効にする
mongoshmongosシャーディングされたクラスター内のsh.stopBalancer() インスタンスに を接続し、 を実行してバランサー を無効にします。
sh.stopBalancer()
注意
移行が進行中の場合、システムは進行中の移行を完了してから、バランサー を停止します。sh.isBalancerRunning() を実行して、バランサーの現在の状態を確認できます。
バランサーが無効になっていることを確認するには、sh.getBalancerState() を実行します。バランサーが無効になっている場合は false が返されます。
sh.getBalancerState()
バランサーを無効にする方法の詳細については、「 バランサーを無効にする 」を参照してください。
コンフィギュレーションサーバー をアップグレードする
レプリカセットのセカンダリノードを一度に 1 つずつアップグレードします。
セカンダリ インスタンスをシャットダウンします。
mongodプロセスをシャットダウンするには、 を使用してクラスターmongoshノードに接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) 8.0バイナリを9.0バイナリに置き換えます。
9.0バイナリを起動します。
--configsvr、--replSet、--portを使用して9.0バイナリを起動します。 配置で使用されるその他のオプションを含めます。mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> 構成ファイルを使用している場合は、ファイルを更新して
sharding.clusterRole: configsvr、replication.replSetName、net.port、net.bindIpを指定し、9 を起動します。0binary:sharding: clusterRole: configsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> 配置に適したその他の設定を含めます。
次のセカンダリ ノードをアップグレードする前に、ノードが
SECONDARY状態に回復するまで待機します。メンバーの状態を確認するには、
rs.status()でmongoshを発行します。セカンダリ ノードごとに繰り返します。
レプリカセットのプライマリを降格します。
mongoshをプライマリに接続し、rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選挙を強制します。rs.stepDown() 降格したプライマリをシャットダウンします。
rs.status()でプライマリが降格し、別のノードがPRIMARY状態になったことが示されたら、降格したプライマリをシャットダウンします。降格したプライマリをシャットダウンするには、
mongoshを使用してプライマリに接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) mongodバイナリを9.0バイナリに置き換えます。9.0バイナリを起動します。
--configsvr、--replSet、--port、--bind_ipオプションを使用して9.0を起動します。 以前の配置で使用された任意の コマンドライン オプションを含めます。mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> 構成ファイルを使用している場合は、ファイルを更新して
sharding.clusterRole: configsvr、replication.replSetName、net.port、net.bindIpを指定してから、 9を起動します。 0 バイナリ:sharding: clusterRole: configsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> 配置に適したその他の構成を含めます。
シャードのアップグレード
シャードを一度に 1 つずつアップグレードします。
各シャード レプリカセット:
レプリカセットのセカンダリノードを一度に 1 つずつアップグレードします。
セカンダリ インスタンスをシャットダウンします。
mongodプロセスをシャットダウンするには、 を使用してクラスターmongoshノードに接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) 8.0バイナリを9.0バイナリに置き換えます。
--shardsvr、--replSet、--port、--bind_ipオプションを使用して9.0バイナリを起動します。 配置に適した追加のコマンドライン オプションを含めます。mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> 構成ファイルを使用している場合は、ファイルを更新して
sharding.clusterRole: shardsvr、replication.replSetName、net.port、net.bindIpを含めてから、 9を起動します。 0 バイナリ:sharding: clusterRole: shardsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> 配置に適したその他の構成を含めます。
次のセカンダリ ノードをアップグレードする前に、ノードが
SECONDARY状態に回復するまで待機します。ノードの状態を確認するには、.
rs.status()でmongoshを発行します。セカンダリ ノードごとに繰り返します。
レプリカセットのプライマリを降格します。
mongoshをプライマリに接続し、rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選挙を強制します。rs.stepDown() 降格したプライマリをアップグレードします。
rs.status()でプライマリが降格し、別のノードがPRIMARY状態になったことが示されたら、降格したプライマリをアップグレードします。降格したプライマリをシャットダウンします。
ステップダウンされたプライマリをシャットダウンするには、
mongoshを使用してレプリカセットに接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) mongodバイナリを9.0バイナリに置き換えます。9.0バイナリを起動します。
--shardsvr、--replSet、--port、--bind_ipオプションを使用して9.0バイナリを起動します。 配置に適した追加のコマンドライン オプションを含めます。mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> 構成ファイルを使用している場合は、ファイルを更新して
sharding.clusterRole: shardsvr、replication.replSetName、net.port、net.bindIpを指定してから、 9を起動します。 0 バイナリ:sharding: clusterRole: shardsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> 配置に適したその他の構成を含めます。
mongos インスタンスのアップグレード
重要
最初にすべてのコンフィギュレーションサーバーレプリカセット(CSRS)インスタンスをアップグレードし、次にすべてのシャードノードをアップグレードし、最後に mongos インスタンスをアップグレードします。これらのアップグレードを完了する前に mongos をアップグレードすると、互換性の問題が発生する可能性があります。
各mongosインスタンスを9.0バイナリで置き換え、再起動します。 配置に適したその他の構成を含めます。
注意
シャーディングされたクラスター メンバーが異なるホスト上で実行されている場合、またはリモート クライアントがシャーディングされたクラスターに接続する場合は、 --bind_ipオプションを指定する必要があります。
mongos --configdb csReplSet/<rsconfigsver1:port1>,<rsconfigsver2:port2>,<rsconfigsver3:port3> --bind_ip localhost,<ip address>
バランサーを再度有効にする
mongosh を使用して、クラスター内の mongos に接続し、バランサーを再有効にするため、sh.startBalancer() を実行します。
sh.startBalancer()
バランサーを再度有効にする方法の詳細については、「 バランサーを有効にする 」を参照してください。
下位互換性のない 9.0 機能を有効にする
この時点で、 8.0と互換性のない9.0機能を使わずに9.0バイナリを実行できます。
これらの 9.0 機能を有効にするには、機能の互換性バージョン(FCV)を 9.0 に設定します。また、confirm を true に設定する必要があります。
Tip
下位互換性のないこうした機能を有効にすると、ダウングレード前に保持されていた下位互換性のない機能をすべて削除する必要があるため、ダウングレード プロセスが複雑になる場合があります。
ダウングレードの可能性を最小限に抑えるには、アップグレード後、バーンイン期間中にこれらの機能を有効にせずにデプロイを運用することをお勧めします。ダウングレードの可能性を最小限に抑えられたと確信できたら、これらの機能を有効にします。
mongosインスタンスで、 adminデータベースでsetFeatureCompatibilityVersionコマンドを実行します。
db.adminCommand( { setFeatureCompatibilityVersion: "9.0", confirm: true } )
featureCompatibilityVersion (FCV) : "9.0 " に設定しますreplSetReconfig暗黙的に各シャードで を実行し、シャードレプリカ構成ドキュメントにterm フィールドを追加します。
コマンドは、新しい構成がレプリカセット ノードの大部分に伝播するまで完了しません。
このコマンドは、内部 システムコレクションへの書込みを実行する必要があります。コマンドが完了しない場合は、mongosで操作が冪等であるため、安全にコマンドを再試行できます。
注意
FCV を9.0 にアップグレードすると、 MongoDB はメタデータをコンフィギュレーションサーバーからシャードに移行します。この 1 回限りの移行、多くのデータベース、コレクション、またはチャンクを持つクラスターではアップグレードに時間がかかる可能性があります。
データベースまたは追跡されているコレクションのメタデータがクローンされている間、そのデータベースまたはコレクションを変更、名前変更、再シャーディング、または削除する操作は、クローンが完了するまで待機する必要があります。
注意
FCV を9.0 にアップグレードすると、 MongoDB はメタデータをコンフィギュレーションサーバーからシャードに移動します。この移行中、FCV アップグレードは次のようなチャンク操作をドレイニングし、ブロックします。
移行、手動、バランサー発行
FCV のアップグレードが完了すると、チャンク操作が再開されます。
注意
FCV を9.0 にアップグレードすると、 MongoDB はコレクションメタデータをコンフィギュレーションサーバーからシャードに移動します。 FCV のアップグレードはこのメタデータを複製しますが、movePrimary はブロックし、ConflictingOperationInProgress で失敗します。
movePrimaryFCV のアップグレードが完了した後に を再試行します。
トラブルシューティング
アップグレード後にスタートアップの問題が発生した場合は、 MongoDBサポート にお問い合わせください。
追加のアップグレード手順
スタンドアロンをアップグレードするには、 8.0 スタンドアロンの 9.0 へのアップグレード を参照してください。
レプリカセットをアップグレードするには、「 8.0 レプリカセットを 9.0 にアップグレードする 」を参照してください。