ダウングレード4.4 4.2へのレプリカセット
ダウングレードを試みる前に、このドキュメントの内容を理解してください。
ダウングレード パス
重要
レプリカセットをアップグレードまたはダウングレードする前に、すべてのレプリカセット ノードが実行されていることを確認してください。そうしないと、すべてのノードが起動されるまでアップグレードまたはダウングレードは完了しません。
4.4 からダウングレードする必要がある場合は、4.2 の最新パッチ リリースにダウングレードします。
MongoDB は 1 つのバージョンのダウングレードのみをサポートします。現在のリリースより数バージョン前のリリースにダウングレードすることはできません。
たとえば、 4.4シリーズの配置を4.2シリーズにダウングレードできます。 ただし、 4.2シリーズの配置から4.0シリーズの配置へのさらなるダウングレードはサポートされていません。
警告
ダウングレード 階層
バージョン 4.4 からダウングレードする必要がある場合は、4.2.6 以降のバージョンにダウングレードします。 4.2.5 またはそれ以前のバージョンにダウングレードすることはできません。
バックアップの作成
任意ですが推奨します。 データベースのバックアップを作成します。
アクセス制御
レプリカセットでアクセス制御が有効になっている場合、ダウングレード ユーザーの権限には、データベース全体のインデックスを一覧表示して管理する特権が含まれている必要があります。 root
ロールを持つユーザーには必要な特権があります。
前提条件
4.2 から 4.0 にダウングレードするには、永続化されている互換性のない機能を削除するか、互換性のない構成設定を更新する必要があります。
1. 名前空間の長さ
MongoDB 4.4 以降:
名前空間の長さは、シャーディングされていないコレクションとビューでは、255 バイト、シャーディングされたコレクションでは 235 バイトを上限とします。コレクションまたはビューの名前空間には、データベース名、ドット(.
)セパレーター、コレクションまたはビューの名前(例: <database>.<collection>
)が含まれます。
ダウングレードする前に、 機能の互換性バージョン(fCV) 4.2 の 120 バイトの名前空間の長さ制限を超える名前空間を持つコレクションまたはビューを解決します。
120 バイトの制限を超える名前空間を持つコレクションまたはビューがあるかどうかを確認するには、 mongo
shell をプライマリに接続して次のコマンドを実行します。
db.adminCommand("listDatabases").databases.forEach(function(d){ let mdb = db.getSiblingDB(d.name); mdb.getCollectionInfos( ).forEach(function(c){ namespace = d.name + "." + c.name namespacelenBytes = encodeURIComponent(namespace).length if (namespacelenBytes > 120) { print (c.type.toUpperCase() + " namespace exceeds 120 bytes:: " + namespace ) } } ) })
コレクションまたはビューの名前空間のいずれかが 120 バイトを超える場合、fCV をダウングレードする前には次のことを行います。
renameCollection
コマンドを使用してコレクションの名前を変更します。ビューの場合は、
db.createView()
を使用して短い名前でビューを再作成し、元のビューを削除します。
2. 機能の互換性バージョン(fCV)をダウングレード
Tip
最初の同期が進行中でないことを確認します。最初の同期の進行中に
setFeatureCompatibilityVersion
コマンドを実行すると、最初の同期がリスタートされます。レプリカセット ノードが
ROLLBACK
またはRECOVERING
状態になっていないことを確認します。featureCompatibilityVersion (fCV) : "4.2"にダウングレード 暗黙的に
replSetReconfig
を実行して構成ドキュメントからterm
フィールドを削除し、新しい構成がレプリカセット ノードの大部分に伝播するまでブロックします。
レプリカセットのfeatureCompatibilityVersion
をダウングレードするには:
mongo
shell をプライマリに接続します。featureCompatibilityVersion
を"4.2"
にダウングレードします。db.adminCommand({setFeatureCompatibilityVersion: "4.2"}) setFeatureCompatibilityVersion
コマンドは内部システム コレクションへの書込みを実行し、冪等です。 何らかの理由でコマンドが正常に完了しない場合は、プライマリでコマンドを再試行してください。更新された
featureCompatibilityVersion
をレプリカセットのすべてのノードが反映しているようにするには、各レプリカセット ノードに接続し、featureCompatibilityVersion
を確認します。db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) すべてのノードは次の内容を含む結果を返す必要があります。
"featureCompatibilityVersion" : { "version" : "4.2" } いずれかのノードが
"4.4"
のfeatureCompatibilityVersion
を返す場合は、続行する前にノードがバージョン"4.2"
を反映するまで待機します。
返されたfeatureCompatibilityVersion
値の詳細については、 「 FeatureCompatibilityVersion の取得 」を参照してください。
注意
アービタは admin.system.version
コレクションを複製しません。このため、レプリカセットの fCV 値に関係なく、アービタは常にバイナリのダウングレード バージョンと同じ機能の互換性バージョンを使用します。
たとえば、MongoDB 4.4 クラスターのアービタの fCV 値は 4.2 です。
3. fCV 4.4 の永続的な機能を削除する
次の手順は、fCV が"4.4"
に設定されたことがある場合にのみ必要です。
4.2 と 互換性のない すべての永続 4.4機能を削除します。 これには以下が含まれます。
- ハッシュされた複合インデックス
コレクション内のハッシュされた複合インデックスを識別するには
db.collection.getIndexes()
を使用し、それらのインデックスを削除するにはdb.collection.dropIndex()
を使用します。
4. 4.4 の機能を削除する
4.4 の機能を使用するすべての永続機能を削除します。 これには以下が含まれますが、これらに限定されません。
4.4 演算子(
$unionWith
や$function
など)を含むビュー定義の場合。 「新しい集計演算子 」も参照してください。
手順
警告
ダウングレード手順に入る前に、遅延レプリカセット ノードを含むすべてのレプリカセット ノードが前提条件の変更を反映していることを確認してください。 つまり、ダウングレードする前に、各ノードのfeatureCompatibilityVersion
と互換性のない機能が削除されていることを確認してください。
最新の 4.2 バイナリをダウンロードします。
パッケージ マネージャーまたは手動ダウンロードのいずれかを使用して、4.2 シリーズの最新リリースを取得します。 パッケージ マネージャーを使用する場合は、4.2 バイナリの新しいリポジトリを追加してから、実際のダウングレード プロセスを実行します。
重要
レプリカセットをアップグレードまたはダウングレードする前に、すべてのレプリカセット ノードが実行されていることを確認してください。そうしないと、すべてのノードが起動されるまでアップグレードまたはダウングレードは完了しません。
4.4 からダウングレードする必要がある場合は、4.2 の最新パッチ リリースにダウングレードします。
レプリカセットのセカンダリ ノードをダウングレードします。
レプリカセットの各セカンダリノードを 1 つずつダウングレードします。
mongosh
クリーン シャットダウンを実行するには、 で次のコマンドを実行します。または、mongod
プロセスを安全に終了する追加の方法については、 「mongod
プロセスの停止 」を参照してください。db.adminCommand( { shutdown: 1 } ) 4.4 バイナリを 4.2 バイナリに置き換え、再起動します。
次のセカンダリをダウングレードする前に、メンバーが
SECONDARY
状態に回復するまで待機します。 メンバーの状態を確認するには、mongo
shell でrs.status()
メソッドを使用します。ノードが
SECONDARY
ステージに達したら、次のセカンダリをダウングレードします。
アービタ レプリカセット ノードがある場合は、ダウングレードします。
レプリカセットにアービタが含まれていない場合は、この手順をスキップします。
レプリカセットのアービタノードをダウングレードします。
mongosh
クリーン シャットダウンを実行するには、 で次のコマンドを実行します。または、mongod
プロセスを安全に終了する追加の方法については、 「mongod
プロセスの停止 」を参照してください。db.adminCommand( { shutdown: 1 } ) アービタ データ ディレクトリの内容を削除します。
storage.dbPath
構成設定または--dbpath
コマンドライン オプションは、アービタmongod
のデータ ディレクトリを指定します。rm -rf /path/to/mongodb/datafiles/* 4.4 バイナリを 4.2 バイナリに置き換え、再起動します。
ノードが
ARBITER
状態に回復するまで待ちます。 メンバーの状態を確認するには、mongo
shell をメンバーに接続し、rs.status()
メソッドを実行します。
プライマリを降格します。
mongo
shell でrs.stepDown()
を使用してプライマリを降格し、通常のフェイルオーバー手順を強制します。
rs.stepDown()
rs.stepDown()
はフェイルオーバー プロセスを迅速化するため、プライマリを直接 シャットダウン するより、推奨されます。
以前のプライマリmongod
を置き換えて再起動します。
rs.status()
がプライマリが降格し、別のノードがPRIMARY
状態になったことを示しているとき: