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をダウングレードするには、次の手順に従います。

mongo shell をmongosインスタンスに接続します。
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機能を削除します。これには以下が含まれます。

時系列コレクション

すべての時系列コレクションを削除します。

ランタイム監査フィルター管理

ノードの構成ファイルでauditLog.runtimeConfigurationをfalseに設定して、ランタイム監査フィルター管理を無効にします。
このmongodまたはmongosインスタンスの監査フィルターをローカル構成ファイルで更新します。

7. 5.0 機能を削除

5.0 の機能を使用するすべての永続機能を削除します。これには以下が含まれますが、これらに限定されません。

ビュー定義に 5.0 の演算子（ $dateAddや$sampleRateなど）が含まれている場合は、それらを削除する必要があります。完全なリストについては、「新しい集計演算子」を参照してください。

手順

シャーディングされたクラスターのダウングレード

警告

ダウングレード手順に入る前に、シャーディングされたクラスター内の遅延レプリカセットノードを含むすべてのノードが前提条件の変更を反映していることを確認してください。つまり、ダウングレードする前に、各ノードのfeatureCompatibilityVersionと互換性のない機能が削除されていることを確認してください。

重要

5.0 からダウングレードする必要がある場合は、4.4 の最新パッチリリースにダウングレードします。

バランサーを無効にします。

mongoshをシャーディングされたクラスター内のmongosインスタンスに接続し、 sh.stopBalancer()を実行してバランサーを無効にします。

sh.stopBalancer()

注意

移行が進行中の場合、システムは進行中の移行を完了してから、バランサーを停止します。 sh.isBalancerRunning()を実行して、バランサーの現在の状態を確認できます。

バランサーが無効になっていることを確認するには、 sh.getBalancerState()を実行します。バランサーが無効になっている場合は false を返します。

sh.getBalancerState()

バランサーを無効にする方法の詳細については、「バランサーを無効にする」を参照してください。

`mongos`インスタンスをダウングレードします。

バイナリをダウングレードして再起動します。

各シャードを 1 つずつダウングレードします。

シャードを一度に 1 つずつダウングレードします。

シャードのセカンダリノードを一度に 1 つずつダウングレードします。
1. mongoshクリーンシャットダウンを実行するには、で次のコマンドを実行します。または、 mongodプロセスを安全に終了する追加の方法については、「mongod プロセスの停止」を参照してください。
  db.adminCommand( { shutdown: 1 } )
2. 5.0 バイナリを 4.4 バイナリに置き換えて再起動します。
3. 次のセカンダリノードをダウングレードする前に、ノードがSECONDARY状態に回復するまで待機します。メンバーの状態を確認するには、 mongoshをシャードに接続し、 rs.status()メソッドを実行します。
  セカンダリノードごとにダウングレードするには、を繰り返します。
シャードアービタが存在する場合は、ダウングレードします。
レプリカセットにアービタが含まれていない場合は、この手順をスキップします。
1. mongoshクリーンシャットダウンを実行するには、で次のコマンドを実行します。または、 mongodプロセスを安全に終了する追加の方法については、「mongod プロセスの停止」を参照してください。
  db.adminCommand( { shutdown: 1 } )
2. アービタデータディレクトリの内容を削除します。 storage.dbPath構成設定または--dbpathコマンドラインオプションは、アービタmongodのデータディレクトリを指定します。
  rm -rf /path/to/mongodb/datafiles/*
3. 5.0 バイナリを 4.4 バイナリに置き換えて再起動します。
4. ノードがARBITER状態に回復するまで待ちます。メンバーの状態を確認するには、 mongoshをメンバーに接続し、 rs.status()メソッドを実行します。
シャードのプライマリをダウングレードします。
1. レプリカセットのプライマリを降格します。 mongoshをプライマリに接続し、 rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選出を強制します。
  rs.stepDown()
2. rs.status()を実行します。
  rs.status()
  ステータスにプライマリが降格し、別のノードがPRIMARY状態になったことが示されたら、続行します。
3. 降格したプライマリのクリーンシャットダウンを実行するには、から次のコマンドを実行します。または、プロセスを安全に終了する追加の方法については、 mongod「 mongodmongoshプロセスの停止」を参照してください。
  db.adminCommand( { shutdown: 1 } )
4. 5.0 バイナリを 4.4 バイナリに置き換えて再起動します。

残りのシャードに対してを繰り返します。

コンフィギュレーションサーバーをダウングレードします。

コンフィギュレーションサーバーレプリカセット（CSRS）のセカンダリノードを一度に 1 つずつダウングレードします。
1. mongoshクリーンシャットダウンを実行するには、で次のコマンドを実行します。または、 mongodプロセスを安全に終了する追加の方法については、「mongod プロセスの停止」を参照してください。
  db.adminCommand( { shutdown: 1 } )
2. 5.0 バイナリを 4.4 バイナリに置き換えて再起動します。
3. 次のセカンダリノードをダウングレードする前に、ノードがSECONDARY状態に回復するまで待機します。メンバーの状態を確認するには、 mongoshをシャードに接続し、 rs.status()メソッドを実行します。
  セカンダリノードごとにダウングレードするには、を繰り返します。
コンフィギュレーションサーバーのプライマリを降格します。
1. mongoshをプライマリに接続し、 rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選出を強制します。
  rs.stepDown()
2. rs.status()を実行します。
  rs.status()
  ステータスにプライマリが降格し、別のノードがPRIMARY状態になったことが示されたら、続行します。
3. 降格したプライマリのクリーンシャットダウンを実行するには、から次のコマンドを実行します。または、プロセスを安全に終了する追加の方法については、 mongod「 mongodmongoshプロセスの停止」を参照してください。
  db.adminCommand( { shutdown: 1 } )
4. 5.0 バイナリを 4.4 バイナリに置き換えて再起動します。

バランサーを再度有効にします。

シャーディングされたクラスターコンポーネントのダウングレードが完了したら、 mongoshをmongosに接続し、バランサーを再度有効にします。

sh.startBalancer()

mongoshメソッドsh.startBalancer()によってシャーディングされたクラスターの自動分割も有効になります。

戻る

レプリカセット

変更履歴

ダウングレード パス

重要