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

5.0 レプリカセットから 4.4 にダウングレード

項目一覧

  • ダウングレード パス
  • バックアップの作成
  • アクセス制御
  • 前提条件
  • 手順

ダウングレードを試みる前に、このドキュメントの内容を理解してください。

重要

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

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

MongoDB は 1 つのバージョンのダウングレードのみをサポートします。現在のリリースより数バージョン前のリリースにダウングレードすることはできません。

たとえば、5.0 シリーズの配置を 4.4 シリーズにダウングレードできます。ただし、4.4 シリーズの配置から 4.2 シリーズへのさらなるダウングレードはサポートされていません。

任意ですが推奨します。 データベースのバックアップを作成します。

レプリカセットでアクセス制御が有効になっている場合、ダウングレード ユーザーの権限には、データベース全体のインデックスを一覧表示して管理する特権が含まれている必要があります。 rootロールを持つユーザーには必要な特権があります。

5.0 から 4.4 にダウングレードするには、永続化されている互換性のない機能を削除するか、互換性のない構成設定を更新する必要があります。 これには以下が含まれます。

MongoDB 5.0 では、クラスター全体の読み取りと書込み保証 (write concern) のデフォルト値が変更されました。MongoDB 4.4 にダウングレードすると、これらのデフォルトが変更される可能性があります。 ダウングレードする前に、クラスターのデフォルトの読み取りおよび書込み保証 (write concern) を手動で設定することを検討してください。

  • クラスターの読み取りまたは書込み保証 (write concern) のデフォルト値を手動で設定するには、 setDefaultRWConcernコマンドを使用します。

  • クラスターにアービタが含まれており、特定の状況でキャッシュの負荷を防ぐために以前に"Majority"の読み取り保証を無効にしていた場合は、ダウングレードが完了したら、 --enableMajorityReadConcern falseまたはreplication.enableMajorityReadConcern: falseを構成することをお勧めします。

MongoDB 5.0 では、ドキュメント フィールド名に.または$文字を含めることができます。 MongoDB 4.4 にダウングレードする前に、 .または$文字を含むフィールド名を含むドキュメントを削除する必要があります。

MongoDB 5.0 では、シンプル形式のタイムゾーン データファイルのサポートが有効になっています。 配置で、 --timeZoneInfoコマンドライン オプションまたはprocessManagement.timeZoneInfo構成ファイル設定を使用して MongoDB に提供されるシンプル形式のタイムゾーン データファイルを使用している場合は、MongoDB 4.4.7 以降にダウングレードするか、タイムゾーン データファイルを元に戻す必要があります。 : 以前の非ストリーム形式のデータファイルを使用します。

まず、以下の点を確認します。

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

  • レプリカセット構成newlyAddedフィールドがないノードがないことを確認します。 これを確認するには、レプリカセット内の各ノードで次のコマンドを実行します。

    use local
    db.system.replset.find( { "members.newlyAdded" : { $exists : true } } );

    newlyAddedフィールドは、最初の同期の実行中とその直後にのみ、ノードのレプリカセット構成ドキュメントにのみ表示されます。

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

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

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

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

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

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

  3. 更新されたfeatureCompatibilityVersionをレプリカセットのすべてのノードが反映しているようにするには、各レプリカセット ノードに接続し、 featureCompatibilityVersionを確認します。

    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 の取得 」を参照してください。

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

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

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

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

  • db.admin.runCommandを使用して、グループ内のプライマリサーバーのデフォルトをリセットします。 プライマリは、グループ内で更新される最後の構成サーバーである必要があります。

    db.admin.runCommand(
    {
    setAuditConfig: 1,
    filter: {},
    auditAuthorizationSuccess: false
    }
    )

    また、構成ドキュメントはダウングレード後に削除することもできます。

    config.settings.remove({_id: 'audit'});
  • 各ノードのランタイム監査フィルター管理を無効にするには、ノードの構成ファイルでauditLog.runtimeConfigurationfalseに設定します。

  • ローカル構成ファイルでこのインスタンスの監査フィルターを更新します。

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

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

警告

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

1

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

重要

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

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

2

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

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

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

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

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

3

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

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

  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()メソッドを実行します。

4

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

rs.stepDown()

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

5

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

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

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

戻る

スタンドアロン