6.0 のシャーディングされたクラスターを 5.0 にダウングレードする
ダウングレードを試みる前に、このページの内容を理解してください。
ダウングレード パス
重要
シャーディングされたクラスターをアップグレードまたはダウングレードする前に、すべてのシャーディングされたクラスターのメンバーが実行されていることを確認してください。 そうしないと、すべてのメンバーが起動されるまでアップグレードまたはダウングレードは完了しません。
6.0 からダウングレードする必要がある場合は、5.0 の最新パッチ リリースにダウングレードします。
MongoDB は 1 つのバージョンのダウングレードのみをサポートします。現在のリリースより数バージョン前のリリースにダウングレードすることはできません。
たとえば、6.0 シリーズの配置を 5.0 シリーズにダウングレードできます。ただし、5.0 シリーズの配置から 4.4 シリーズの配置へのさらなるダウングレードはサポートされていません。
前提条件
ダウングレード手順を開始する前に、次の前提条件手順を完了する必要があります。
バックアップの作成
任意ですが推奨します。 データベースのバックアップを作成します。
バックアップの作成方法については、「 自己管理型配置のバックアップ メソッド 」を参照してください。
下位互換性のない機能を削除する
6.0 から 5.0 にダウングレードするには、5.0 と 互換性のない 6.0 の機能を削除する必要があります。 互換性のない機能のリストと削除方法については、「ダウングレードの考慮事項 」を参照してください。
リシャーディング操作が進行中でないことを確認する
リシャーディング操作が正常に完了したことを確認します。 プライマリ フェイルオーバーが原因で最近のリシャーディング操作が失敗した場合は、シャーディングされたクラスターのfeatureCompatibilityVersion
をダウングレードする前に、まず cleanupReshardCollection
コマンドを実行する必要があります。
シャーディングされたクラスターのfeatureCompatibilityVersion
をダウングレードするときにリシャーディング操作がまだ実行中の場合、リシャーディング操作は完了しません。
機能の互換性バージョン(fCV)のダウングレード
シャーディングされたクラスターの fCVをダウングレードするには:
最初の同期が進行中でないことを確認します。 最初の同期の進行中に
setFeatureCompatibilityVersion
コマンドを実行すると、最初の同期がリスタートされます。レプリカセット構成に
newlyAdded
フィールドがないノードがないことを確認します。 これを確認するには、レプリカセット内の各ノードで次のコマンドを実行します。use local db.system.replset.find( { "members.newlyAdded" : { $exists : true } } ); newlyAdded
フィールドは、最初の同期の実行中とその直後にのみ、ノードのレプリカセット構成ドキュメントにのみ表示されます。レプリカセット ノードが
ROLLBACK
またはRECOVERING
状態になっていないことを確認します。featureCompatibilityVersion
を"5.0"
にダウングレードします。db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } ) setFeatureCompatibilityVersion
コマンドは内部システム コレクションへの書込みを実行し、冪等です。 コマンドが正常に完了しない場合は、mongos
インスタンスでコマンドを再試行してください。注意
トラブルシューティング
setFeatureCompatibilityVersion
がシャーディングされたクラスターで実行されている場合、チャンクの移行、分割、マージはConflictingOperationInProgress
で失敗する可能性があります。setFeatureCompatibilityVersion
がManualInterventionRequired
エラーで失敗し、クラスターが最近 再シャーディング操作 を実行していて、選挙が原因で失敗した場合は、setFeatureCompatibilityVersion
を再度実行する前にcleanupReshardCollection
コマンドを実行する必要があります。
レプリカセットのすべてのノードに更新された
featureCompatibilityVersion
が適用されていることを確認するには、各レプリカセット ノードに接続し、featureCompatibilityVersion
を確認します。db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) Tip
アクセス制御
アクセス制御が有効になっているシャーディングされたクラスターの場合、シャード レプリカセット メンバーで
adminCommand
を実行するには、シャード ローカル ユーザーとしてメンバーに接続する必要があります。すべてのノードは次の内容を含む結果を返す必要があります。
"featureCompatibilityVersion" : { "version" : "5.0" } いずれかのノードが
"6.0"
のfeatureCompatibilityVersion
を返す場合は、続行する前にノードがバージョン"5.0"
を返すまで待機します。
返されたfeatureCompatibilityVersion
値の詳細については、 「 FeatureCompatibilityVersion の取得 」を参照してください。
ダウングレード手順
警告
ダウングレード手順に入る前に、遅延レプリカセット ノードを含むすべてのシャーディングされたクラスター ノードに前提条件が変更されていることを確認してください。 そのためには、ダウングレードする前に、 featureCompatibilityVersion
と を確認して、各ノードの互換性のない機能を削除します。
最新の 5.0 バイナリをダウンロードします。
パッケージ マネージャーまたは手動ダウンロードのいずれかを使用して、5.0 シリーズの最新リリースを取得します。 パッケージ マネージャーを使用する場合は、5.0 バイナリの新しいリポジトリを追加してから、実際のダウングレード プロセスを実行します。
重要
レプリカセットをアップグレードまたはダウングレードする前に、すべてのレプリカセット ノードが実行されていることを確認してください。そうしないと、すべてのノードが起動されるまでアップグレードまたはダウングレードは完了しません。
6.0 からダウングレードする必要がある場合は、5.0 の最新パッチ リリースにダウングレードします。
バランサーを無効にします。
バランサーを無効にするには、 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 } ) 5.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 } ) 5.0バイナリを使用して
mongod
を再起動します。mongod
プロセスを開始するには、次のコマンドを実行します。mongod --dbpath </path-to-mongodb-datafiles>
バランサーを再度有効にします。
シャーディングされたクラスターのすべてのコンポーネントをダウングレードした後、 mongos
に接続し、次のコマンドを実行してバランサーを再度有効にします。
sh.startBalancer()
sh.startBalancer()
メソッド も、シャーディングされたクラスターの自動分割を有効にします。