重要
MongoDB 8.3 は最新のマイナー リリースです。MongoDB 8.2 以降では、特定のユースケースに合わせてオンプレミス配置(Community と EA)でマイナー リリースを利用できます。詳細については、 MongoDB のバージョン管理 を参照してください。
オンプレミスでサポートされている最新のMongoDBバージョンをインストールするには、インストール手順を参照してください。
ダウングレードを試みる前に、このページの内容を理解してください。
ダウングレード パス
重要
シャーディングされたクラスターをアップグレードまたはダウングレードする前に、すべてのシャーディングされたクラスターのメンバーが実行されていることを確認してください。 そうしないと、すべてのメンバーが起動されるまでアップグレードまたはダウングレードは完了しません。
8.3からダウングレードする必要がある場合は、 8.0の最新パッチ リリースにダウングレードします。
MongoDB は、連番での単一バージョンのダウングレードのみをサポートします。現在のリリースより数バージョン前のリリースにダウングレードすることはできません。
メジャーでもマイナーでも、どのバージョンでも、隣接するバージョンにアップグレードまたはダウングレードできます。例、8.3 から 8.2 にダウングレードしたり、7.0 から 8.0 にアップグレードしたりできます。
メジャーでもマイナーでも、すべてのバージョンで、前のメジャー バージョンにダウングレードできます。例は、8.3 から 8.0 までです。
どのマイナー バージョンでも、すぐに次のバージョンにアップグレードできます。例は、8.2 から 8.3 までです。
前提条件
ダウングレード手順を開始する前に、次の前提条件手順を完了する必要があります。
バックアップの作成
任意ですが推奨します。 データベースのバックアップを作成します。
バックアップの作成方法については、「自己管理型配置のバックアップ メソッド 」を参照してください。
下位互換性のない機能を削除する
8.3から8.0 8.3にダウングレードするには、8.0 と互換性のない 機能を削除する必要があります。互換性のない機能のリストと削除方法については、「 ダウングレードの考慮事項 」を参照してください。
リシャーディング操作が進行中でないことを確認する
リシャーディング操作が正常に完了したことを確認します。 プライマリ フェイルオーバーが原因で最近のリシャーディング操作が失敗した場合は、シャーディングされたクラスターのfeatureCompatibilityVersionをダウングレードする前に、まず cleanupReshardCollectionコマンドを実行する必要があります。
シャーディングされたクラスターのfeatureCompatibilityVersionをダウングレードするときにリシャーディング操作がまだ実行中の場合、リシャーディング操作は完了しません。
ダウングレード機能の互換性バージョン(FCV)
シャーディングされたクラスターの FCV をダウングレードするには:
最初の同期が進行中でないことを確認します。 最初の同期の進行中に
setFeatureCompatibilityVersionコマンドを実行すると、最初の同期がリスタートされます。レプリカセット構成に
newlyAddedフィールドがないノードがないことを確認します。 これを確認するには、レプリカセット内の各ノードで次のコマンドを実行します。use local db.system.replset.find( { "members.newlyAdded" : { $exists : true } } ); newlyAddedフィールドは、最初の同期の実行中とその直後にのみ、ノードのレプリカセット構成ドキュメントにのみ表示されます。レプリカセット ノードが
ROLLBACKまたはRECOVERING状態になっていないことを確認します。featureCompatibilityVersionを"8.0"にダウングレードします。db.adminCommand( { setFeatureCompatibilityVersion: "8.0", confirm: true } ) setFeatureCompatibilityVersionコマンドは内部システム コレクションへの書込みを実行し、冪等です。 コマンドが正常に完了しない場合は、mongosインスタンスでコマンドを再試行してください。注意
トラブルシューティング
setFeatureCompatibilityVersionがシャーディングされたクラスターで実行されている場合、チャンクの移行、分割、マージはConflictingOperationInProgressで失敗する可能性があります。setFeatureCompatibilityVersionがManualInterventionRequiredエラーで失敗し、クラスターが最近 再シャーディング操作 を実行していて、選挙が原因で失敗した場合は、setFeatureCompatibilityVersionを再度実行する前にcleanupReshardCollectionコマンドを実行する必要があります。
レプリカセットのすべてのノードに更新された
featureCompatibilityVersionが適用されていることを確認するには、各レプリカセット ノードに接続し、featureCompatibilityVersionを確認します。Tip
アクセス制御
アクセス制御が有効になっているシャーディングされたクラスターの場合、シャード レプリカセット メンバーで
adminCommandを実行するには、シャード ローカル ユーザーとしてメンバーに接続する必要があります。db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) "featureCompatibilityVersion" : { "version" : "8.0" } いずれかのノードが
"8.3"のfeatureCompatibilityVersionを返す場合は、続行する前にノードがバージョン"8.0"を返すまで待機します。
返されたfeatureCompatibilityVersion値の詳細については、 「 FeatureCompatibilityVersion の取得 」を参照してください。
ダウングレード手順
警告
ダウングレード手順に入る前に、遅延レプリカセット ノードを含むすべてのシャーディングされたクラスター ノードに前提条件が変更されていることを確認してください。 そのためには、ダウングレードする前に、 featureCompatibilityVersionと を確認して、各ノードの互換性のない機能を削除します。
バランサーを無効にする
バランサーを無効にするには、 mongoshをシャーディングされたクラスター内のmongosインスタンスに接続し、次のコマンドを実行します。
sh.stopBalancer()
注意
移行が進行中の場合、MongoDB はバランサーを停止する前に、進行中の移行を完了します。 バランサーの現在の状態を確認するには、 sh.isBalancerRunning()を実行します。
バランサーが無効になっていることを確認するには、次のコマンドを実行します。
sh.getBalancerState()
バランサーが無効になっている場合、sh.getBalancerState() は を返します。false
バランサーを無効にする方法の詳細については、「 バランサーを無効にする 」を参照してください。
各シャードを一度に 1 つずつダウングレード
シャードのセカンダリ ノードを一度に 1 つずつダウングレードします。
ノードをシャットダウンします。
mongodプロセスをシャットダウンするには、mongoshを使用して配置に接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) ノードを再起動します。
mongodプロセスを開始するには、次のコマンドを実行します。mongod --dbpath </path-to-data-folder> ノードが
SECONDARY状態になるまで待ちます。次のセカンダリをダウングレードする前に、ノードが
SECONDARY状態に回復するまで待ちます。 メンバーの状態を確認するには、rs.status()mongoshで メソッドを使用します。前の手順を繰り返して、各セカンダリ ノードをダウングレードします。
シャード アービタ(存在する場合)をダウングレードします。
レプリカセットにアービタが含まれていない場合は、この手順をスキップします。
シャーディングされたクラスターのアービタノードをダウングレードします。
ノードをシャットダウンします。
アービタをシャットダウンするには、
mongoshを使用してアービタに接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) アービタ データ ディレクトリの内容を削除します。
アービタ
mongodのデータディレクトリを見つけるには、storage.dbPath構成設定または--dbpathコマンドライン オプションのいずれかを確認します。次のコマンドを実行します:
rm -rf /path/to/mongodb/datafiles/* アービタを再起動します。
mongodプロセスを開始するには、次のコマンドを実行します。mongod --dbpath </path-to-mongodb-datafiles> ノードが
ARBITER状態になるまで待ちます。プライマリをダウングレードする前に、ノードが
ARBITER状態に回復するまで待ちます。 メンバーの状態を確認するには、rs.status()mongoshで メソッドを使用します。
シャードプライマリをダウングレードします。
プライマリを降格します。
mongoshでは、rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選挙を開始します。rs.stepDown() プライマリが降格したことを確認します。
次のコマンドを実行します:
rs.status() プライマリが降格し、別のノードが
PRIMARY状態になったことを確認します。以前のプライマリ ノードをシャットダウンします。
以前のプライマリをシャットダウンするには、
mongoshを使用して配置に接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) 8.0バイナリを使用して
mongodを再起動します。mongodプロセスを開始するには、次のコマンドを実行します。mongod --dbpath </path-to-mongodb-datafiles> 残りのシャードに対して を繰り返します。
コンフィギュレーションサーバー をダウングレード
コンフィギュレーションサーバー レプリカセット(CSRS)のシャードのセカンダリ ノードを一度に 1 つずつダウングレードします。
セカンダリをシャットダウンします。
セカンダリに接続し、次のコマンドを実行します。
db.adminCommand( { shutdown: 1 } ) ノードを再起動します。
mongodプロセスを開始するには、次のコマンドを実行します。mongod --dbpath </path-to-data-folder> ノードが
SECONDARY状態になるまで待ちます。次のセカンダリをダウングレードする前に、ノードが
SECONDARY状態に回復するまで待ちます。 メンバーの状態を確認するには、rs.status()mongoshで メソッドを使用します。前の手順を繰り返して、各セカンダリ ノードをダウングレードします。
コンフィギュレーションサーバーのプライマリをダウングレードします。
プライマリを降格します。
mongoshで、rs.stepDown()を実行してプライマリを降格し、新しいプライマリの選挙を開始します。rs.stepDown() プライマリが降格したことを確認します。
次のコマンドを実行します:
rs.status() プライマリが降格し、別のノードが
PRIMARY状態になったことを確認します。以前のプライマリ ノードをシャットダウンします。
以前のプライマリをシャットダウンするには、
mongoshを使用して配置に接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) 8.0バイナリを使用して
mongodを再起動します。mongodプロセスを開始するには、次のコマンドを実行します。mongod --dbpath </path-to-mongodb-datafiles>
バランサーを再度有効にする
シャーディングされたクラスターのすべてのコンポーネントをダウングレードした後、 mongosに接続し、次のコマンドを実行してバランサーを再度有効にします。
sh.startBalancer()
sh.startBalancer()メソッド も、シャーディングされたクラスターの自動分割を有効にします。