5.0 のシャーディングされたクラスターから 4.4 にダウングレード
ダウングレードを試みる前に、このドキュメントの内容を理解してください。
ダウングレード パス
重要
レプリカセットをアップグレードまたはダウングレードする前に、すべてのレプリカセット ノードが実行されていることを確認してください。そうしないと、すべてのノードが起動されるまでアップグレードまたはダウングレードは完了しません。
5.0 からダウングレードする必要がある場合は、4.4 の最新パッチ リリースにダウングレードします。
MongoDB は 1 つのバージョンのダウングレードのみをサポートします。現在のリリースより数バージョン前のリリースにダウングレードすることはできません。
たとえば、5.0 シリーズの配置を 4.4 シリーズにダウングレードできます。ただし、4.4 シリーズの配置から 4.2 シリーズへのさらなるダウングレードはサポートされていません。
バックアップの作成
任意ですが推奨します。 データベースのバックアップを作成します。
前提条件
5.0 から 4.4 にダウングレードするには、永続化されている互換性のない機能を削除するか、互換性のない構成設定を更新する必要があります。 これには以下が含まれます。
1. クラスターのデフォルトの読み取り保証および書込み保証
MongoDB 5.0 では、クラスター全体の読み取りと書込み保証 (write concern) のデフォルト値が変更されました。MongoDB 4.4 にダウングレードすると、これらのデフォルトが変更される可能性があります。 ダウングレードする前に、クラスターのデフォルトの読み取りおよび書込み保証 (write concern) を手動で設定することを検討してください。
クラスターの読み取りまたは書込み保証 (write concern) のデフォルト値を手動で設定するには、
setDefaultRWConcern
コマンドを使用します。クラスターにアービタが含まれており、特定の状況でキャッシュの負荷を防ぐために以前に
"Majority"
の読み取り保証を無効にしていた場合は、ダウングレードが完了したら、--enableMajorityReadConcern false
またはreplication.enableMajorityReadConcern: false
を構成することをお勧めします。
2 。または.
$
文字を含むドキュメント フィールド
MongoDB 5.0 では、ドキュメント フィールド名に.
または$
文字を含めることができます。 MongoDB 4.4 にダウングレードする前に、 .
または$
文字を含むフィールド名を含むドキュメントを削除する必要があります。
3. 制限形式のタイムゾーン データファイル
MongoDB 5.0 では、シンプル形式のタイムゾーン データファイルのサポートが有効になっています。 配置で、 --timeZoneInfo
コマンドライン オプションまたはprocessManagement.timeZoneInfo
構成ファイル設定を使用して MongoDB に提供されるシンプル形式のタイムゾーン データファイルを使用している場合は、MongoDB 4.4.7 以降にダウングレードするか、タイムゾーン データファイルを元に戻す必要があります。 : 以前の非ストリーム形式のデータファイルを使用します。
4. 再シャーディング
ダウングレード手順を試行する前に、すべての再シャーディング操作が正常に完了していることを確認してください。 プライマリ フェイルオーバーが原因で最近のリシャーディング操作が失敗した場合は、シャーディングされたクラスターのfeatureCompatibilityVersion
をダウングレードする前に、まずcleanupReshardCollection
コマンドを実行する必要があります。
シャーディングされたクラスターのfeatureCompatibilityVersion
をダウングレードするときにリシャーディング操作がまだ実行中である場合、リシャーディング操作は中止されます。
5. 機能の互換性バージョン(fCV)をダウングレード
まず、以下の点を確認します。
最初の同期が進行中でないことを確認します。最初の同期の進行中に
setFeatureCompatibilityVersion
コマンドを実行すると、最初の同期がリスタートされます。レプリカセット構成に
newlyAdded
フィールドがないノードがないことを確認します。 これを確認するには、シャーディングされたクラスター内の各ノードで次のコマンドを実行します。use local db.system.replset.find( { "members.newlyAdded" : { $exists : true } } ); newlyAdded
フィールドは、最初の同期の実行中とその直後にのみ、ノードのレプリカセット構成ドキュメントにのみ表示されます。レプリカセット ノードが
ROLLBACK
またはRECOVERING
状態になっていないことを確認します。
次に、シャーディングされたクラスターのfeatureCompatibilityVersion
をダウングレードするには、次の手順に従います。
featureCompatibilityVersion
を"4.4"
にダウングレードします。db.adminCommand({setFeatureCompatibilityVersion: "4.4"}) setFeatureCompatibilityVersion
コマンドは内部システム コレクションへの書込みを実行し、冪等です。 何らかの理由でコマンドが正常に完了しない場合は、mongos
インスタンスでコマンドを再試行してください。注意
setFeatureCompatibilityVersion
がシャーディングされたクラスターで実行されている場合、チャンクの移行、分割、マージはConflictingOperationInProgress
で失敗する可能性があります。setFeatureCompatibilityVersion
がManualInterventionRequired
エラーで失敗し、クラスターが最近 再シャーディング操作 を実行していて、選挙が原因で失敗した場合は、setFeatureCompatibilityVersion
を再度試行する前にcleanupReshardCollection
コマンドを実行する必要があります。
シャーディングされたクラスターのすべてのノードが更新された
featureCompatibilityVersion
を反映していることを確認するには、各シャード レプリカセット ノードと各コンフィギュレーションサーバー レプリカセット ノードに接続し、featureCompatibilityVersion
を確認します。Tip
アクセス制御が有効になっているシャーディングされたクラスターの場合、シャード レプリカセット ノードに対して次のコマンドを実行するには、シャード ローカル ユーザー としてノードに接続する必要があります。
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) すべてのノードは次の内容を含む結果を返す必要があります。
"featureCompatibilityVersion" : { "version" : "4.4" } いずれかのノードが
"5.0"
のfeatureCompatibilityVersion
を返す場合は、続行する前にノードがバージョン"4.4"
を反映するまで待機します。
注意
アービタは admin.system.version
コレクションを複製しません。このため、レプリカセットの fCV 値に関係なく、アービタは常にバイナリのダウングレード バージョンと同じ機能の互換性バージョンを使用します。
たとえば、MongoDB 5.0 クラスターのアービタの fCV 値は 4.4 です。
返されたfeatureCompatibilityVersion
値の詳細については、 「 FeatureCompatibilityVersion の表示 」を参照してください。
6. fCV 5.0 永続機能を削除
次の手順は、fCV が"5.0"
に設定されたことがある場合にのみ必要です。
4.4 と互換性のないすべての永続的な 5.0機能を削除します。 これには以下が含まれます。
- 時系列コレクション
- すべての時系列コレクションを削除します。
- ランタイム監査フィルター管理
7. 5.0 機能を削除
5.0 の機能を使用するすべての永続機能を削除します。 これには以下が含まれますが、これらに限定されません。
ビュー定義に 5.0 の演算子(
$dateAdd
や$sampleRate
など)が含まれている場合は、それらを削除する必要があります。 完全なリストについては、「新しい集計演算子」を参照してください。
手順
シャーディングされたクラスターのダウングレード
警告
ダウングレード手順に入る前に、シャーディングされたクラスター内の遅延レプリカセット ノードを含むすべてのノードが前提条件の変更を反映していることを確認してください。 つまり、ダウングレードする前に、各ノードのfeatureCompatibilityVersion
と互換性のない機能が削除されていることを確認してください。
最新の 4.4 バイナリをダウンロードします。
パッケージ マネージャーまたは手動ダウンロードのいずれかを使用して、4.4 シリーズの最新リリースを取得します。 パッケージ マネージャーを使用する場合は、4.4 バイナリの新しいリポジトリを追加してから、実際のダウングレード プロセスを実行します。
重要
レプリカセットをアップグレードまたはダウングレードする前に、すべてのレプリカセット ノードが実行されていることを確認してください。そうしないと、すべてのノードが起動されるまでアップグレードまたはダウングレードは完了しません。
5.0 からダウングレードする必要がある場合は、4.4 の最新パッチ リリースにダウングレードします。
バランサーを無効にします。
mongosh
mongos
シャーディングされたクラスター内のsh.stopBalancer()
インスタンスに接続し、 を実行してバランサーを無効にします。
sh.stopBalancer()
注意
移行が進行中の場合、システムは進行中の移行を完了してから、バランサーを停止します。 sh.isBalancerRunning()
を実行して、バランサーの現在の状態を確認できます。
バランサーが無効になっていることを確認するには、 sh.getBalancerState()
を実行します。バランサーが無効になっている場合は false を返します。
sh.getBalancerState()
バランサーを無効にする方法の詳細については、「 バランサーを無効にする 」を参照してください。
各シャードを 1 つずつダウングレードします。
シャードを一度に 1 つずつダウングレードします。
シャードのセカンダリノードを一度に 1 つずつダウングレードします。
mongosh
クリーン シャットダウンを実行するには、 で次のコマンドを実行します。または、mongod
プロセスを安全に終了する追加の方法については、 「mongod
プロセスの停止 」を参照してください。db.adminCommand( { shutdown: 1 } ) 5.0 バイナリを 4.4 バイナリに置き換えて再起動します。
次のセカンダリ ノードをダウングレードする前に、ノードが
SECONDARY
状態に回復するまで待機します。 メンバーの状態を確認するには、mongosh
をシャードに接続し、rs.status()
メソッドを実行します。セカンダリ ノードごとにダウングレードするには、 を繰り返します。
シャードアービタが存在する場合は、ダウングレードします。
レプリカセットにアービタが含まれていない場合は、この手順をスキップします。
mongosh
クリーン シャットダウンを実行するには、 で次のコマンドを実行します。または、mongod
プロセスを安全に終了する追加の方法については、 「mongod
プロセスの停止 」を参照してください。db.adminCommand( { shutdown: 1 } ) アービタ データ ディレクトリの内容を削除します。
storage.dbPath
構成設定または--dbpath
コマンドライン オプションは、アービタmongod
のデータ ディレクトリを指定します。rm -rf /path/to/mongodb/datafiles/* 5.0 バイナリを 4.4 バイナリに置き換えて再起動します。
ノードが
ARBITER
状態に回復するまで待ちます。 メンバーの状態を確認するには、mongosh
をメンバーに接続し、rs.status()
メソッドを実行します。
シャードのプライマリをダウングレードします。
レプリカセットのプライマリを降格します。
mongosh
をプライマリに接続し、rs.stepDown()
を使用してプライマリを降格し、新しいプライマリの選出を強制します。rs.stepDown() rs.status() ステータスにプライマリが降格し、別のノードが
PRIMARY
状態になったことが示されたら、続行します。降格したプライマリのクリーン シャットダウンを実行するには、 から次のコマンドを実行します。または、 プロセスを安全に終了する追加の方法については、
mongod
「mongod
mongosh
プロセスの停止 」 を参照してください。db.adminCommand( { shutdown: 1 } ) 5.0 バイナリを 4.4 バイナリに置き換えて再起動します。
残りのシャードに対して を繰り返します。
コンフィギュレーションサーバー をダウングレードします。
コンフィギュレーションサーバー レプリカセット(CSRS)のセカンダリノードを一度に 1 つずつダウングレードします。
mongosh
クリーン シャットダウンを実行するには、 で次のコマンドを実行します。または、mongod
プロセスを安全に終了する追加の方法については、 「mongod
プロセスの停止 」を参照してください。db.adminCommand( { shutdown: 1 } ) 5.0 バイナリを 4.4 バイナリに置き換えて再起動します。
次のセカンダリ ノードをダウングレードする前に、ノードが
SECONDARY
状態に回復するまで待機します。 メンバーの状態を確認するには、mongosh
をシャードに接続し、rs.status()
メソッドを実行します。セカンダリ ノードごとにダウングレードするには、 を繰り返します。
コンフィギュレーションサーバーのプライマリを降格します。
mongosh
をプライマリに接続し、rs.stepDown()
を使用してプライマリを降格し、新しいプライマリの選出を強制します。rs.stepDown() rs.status() ステータスにプライマリが降格し、別のノードが
PRIMARY
状態になったことが示されたら、続行します。降格したプライマリのクリーン シャットダウンを実行するには、 から次のコマンドを実行します。または、 プロセスを安全に終了する追加の方法については、
mongod
「mongod
mongosh
プロセスの停止 」 を参照してください。db.adminCommand( { shutdown: 1 } ) 5.0 バイナリを 4.4 バイナリに置き換えて再起動します。
バランサーを再度有効にします。
シャーディングされたクラスター コンポーネントのダウングレードが完了したら、 mongosh
をmongos
に接続し、バランサーを再度有効にします。
sh.startBalancer()
mongosh
メソッドsh.startBalancer()
によってシャーディングされたクラスターの自動分割も有効になります。