Docs Menu
Docs Home
/
MongoDB マニュアル
/ / /

ダウングレード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 にダウングレードするには、永続化されている互換性のない機能を削除するか、互換性のない構成設定を更新する必要があります。

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()を使用して短い名前でビューを再作成し、元のビューを削除します。

Tip

  • 最初の同期が進行中でないことを確認します。最初の同期の進行中に setFeatureCompatibilityVersion コマンドを実行すると、最初の同期がリスタートされます。

  • レプリカセット ノードがROLLBACKまたはRECOVERING状態になっていないことを確認します。

  • featureCompatibilityVersion (fCV) : "4.2"にダウングレード 暗黙的にreplSetReconfigを実行して構成ドキュメントからtermフィールドを削除し、新しい構成がレプリカセット ノードの大部分に伝播するまでブロックします。

レプリカセットのfeatureCompatibilityVersionをダウングレードするには:

  1. mongo shell をプライマリに接続します。

  2. featureCompatibilityVersion"4.2"にダウングレードします。

    db.adminCommand({setFeatureCompatibilityVersion: "4.2"})

    setFeatureCompatibilityVersionコマンドは内部システム コレクションへの書込みを実行し、冪等です。 何らかの理由でコマンドが正常に完了しない場合は、プライマリでコマンドを再試行してください。

  3. 更新された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 です。

次の手順は、fCV が"4.4"に設定されたことがある場合にのみ必要です。

4.2 と 互換性のない すべての永続 4.4機能を削除します。 これには以下が含まれます。

ハッシュされた複合インデックス

すべての複合ハッシュインデックスを削除します。

コレクション内のハッシュされた複合インデックスを識別するにはdb.collection.getIndexes()を使用し、それらのインデックスを削除するにはdb.collection.dropIndex()を使用します。

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

警告

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

1

パッケージ マネージャーまたは手動ダウンロードのいずれかを使用して、4.2 シリーズの最新リリースを取得します。 パッケージ マネージャーを使用する場合は、4.2 バイナリの新しいリポジトリを追加してから、実際のダウングレード プロセスを実行します。

重要

レプリカセットをアップグレードまたはダウングレードする前に、すべてのレプリカセット ノードが実行されていることを確認してください。そうしないと、すべてのノードが起動されるまでアップグレードまたはダウングレードは完了しません。

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

2

レプリカセットの各セカンダリノードを 1 つずつダウングレードします。

  1. mongoshクリーン シャットダウンを実行するには、 で次のコマンドを実行します。または、 mongodプロセスを安全に終了する追加の方法については、 「mongod プロセスの停止 」を参照してください。

    db.adminCommand( { shutdown: 1 } )
  2. 4.4 バイナリを 4.2 バイナリに置き換え、再起動します。

  3. 次のセカンダリをダウングレードする前に、メンバーがSECONDARY状態に回復するまで待機します。 メンバーの状態を確認するには、 mongo shell でrs.status()メソッドを使用します。

  4. ノードがSECONDARYステージに達したら、次のセカンダリをダウングレードします。

3

レプリカセットにアービタが含まれていない場合は、この手順をスキップします。

レプリカセットのアービタノードをダウングレードします。

  1. mongoshクリーン シャットダウンを実行するには、 で次のコマンドを実行します。または、 mongodプロセスを安全に終了する追加の方法については、 「mongod プロセスの停止 」を参照してください。

    db.adminCommand( { shutdown: 1 } )
  2. アービタ データ ディレクトリの内容を削除します。 storage.dbPath構成設定または--dbpathコマンドライン オプションは、アービタmongodのデータ ディレクトリを指定します。

    rm -rf /path/to/mongodb/datafiles/*
  3. 4.4 バイナリを 4.2 バイナリに置き換え、再起動します。

  4. ノードがARBITER状態に回復するまで待ちます。 メンバーの状態を確認するには、 mongo shell をメンバーに接続し、 rs.status()メソッドを実行します。

4

mongo shell でrs.stepDown()を使用してプライマリを降格し、通常のフェイルオーバー手順を強制します。

rs.stepDown()

rs.stepDown() はフェイルオーバー プロセスを迅速化するため、プライマリを直接 シャットダウン するより、推奨されます。

5

rs.status()がプライマリが降格し、別のノードがPRIMARY状態になったことを示しているとき:

  1. mongoshクリーン シャットダウンを実行するには、 で次のコマンドを実行します。または、 mongodプロセスを安全に終了する追加の方法については、 「mongod プロセスの停止 」を参照してください。

    db.adminCommand( { shutdown: 1 } )
  2. mongodバイナリを 4.2 バイナリに置き換えて再起動します。

戻る

スタンドアロン