Docs Menu

Downgrade 6.0 Sharded Cluster to 5.0

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

重要

Before you upgrade or downgrade a sharded cluster, ensure all sharded cluster members are running. If you do not, the upgrade or downgrade will not complete until all members are started.

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

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

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

ダウングレード手順を開始する前に、次の前提条件手順を完了する必要があります。

1

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

バックアップの作成方法については、「自己管理型配置のバックアップ メソッド 」を参照してください。

2

6.0 から 5.0 にダウングレードするには、5.0 と 互換性のない 6.0 の機能を削除する必要があります。 互換性のない機能のリストと削除方法については、「ダウングレードの考慮事項 」を参照してください。

3

Ensure that any resharding operations have successfully completed. If a recent resharding operation has failed due to a primary failover, you must first run the cleanupReshardCollection command before downgrading the featureCompatibilityVersion of your sharded cluster.

If a resharding operation is still running while you downgrade the featureCompatibilityVersion of your sharded cluster, the resharding operation will not complete.

4

To downgrade the FCV of your sharded cluster:

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

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

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

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

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

  4. Use mongosh to connect to your mongos instance.

  5. featureCompatibilityVersion"5.0"にダウングレードします。

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

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

    注意

    Troubleshooting

  6. レプリカセットのすべてのノードに更新されたfeatureCompatibilityVersionが適用されていることを確認するには、各レプリカセット ノードに接続し、 featureCompatibilityVersionを確認します。

    db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

    Tip

    アクセス制御

    For a sharded cluster that has access control enabled, to run the adminCommand on a shard replica set member, you must connect to the member as a shard local user.

    すべてのノードは次の内容を含む結果を返す必要があります。

    "featureCompatibilityVersion" : { "version" : "5.0" }

    いずれかのノードが"6.0"featureCompatibilityVersionを返す場合は、続行する前にノードがバージョン"5.0"を返すまで待機します。

返されたfeatureCompatibilityVersion値の詳細については、 「 FeatureCompatibilityVersion の取得 」を参照してください。

警告

Before proceeding with the downgrade procedure, ensure that all sharded cluster members, including delayed replica set members, have the prerequisite changes. To do that, check the featureCompatibilityVersion and the remove the incompatible features for each node before downgrading.

1

Using either a package manager or a manual download, get the latest release in the 5.0 series. If using a package manager, add a new repository for the 5.0 binaries, then perform the actual downgrade process.

重要

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

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

2

5.0 バイナリがシステム パスにあることを確認します。 バイナリのバージョンを確認するには、次のコマンドを実行します。

mongod --version

コマンド出力に 5.0 シリーズのリリースが表示されるはずです。

3

To disable the balancer, connect mongosh to a mongos instance in the sharded cluster, and run the following command:

sh.stopBalancer()

注意

If a migration is in progress, MongoDB completes the in-progress migration before stopping the balancer. To check the balancer's current state, run sh.isBalancerRunning().

To verify that the balancer is disabled, run the following command:

sh.getBalancerState()

sh.getBalancerState() returns false if the balancer is disabled.

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

4
  1. To stop mongos, run the following command:

    db.shutdownServer()
  2. 再起動 mongos with the 5.0 binary.

5
  1. Downgrade the shard's secondary members, one at a time.

    1. ノードをシャットダウンします。

      To shut down the mongod process, use mongosh to connect to the deployment and run the following command:

      db.adminCommand( { shutdown: 1 } )
    2. ノードを再起動します。

      mongodプロセスを開始するには、次のコマンドを実行します。

      mongod --dbpath </path-to-data-folder>
    3. ノードがSECONDARY状態になるまで待ちます。

      Before downgrading the next secondary, wait for the member to recover to the SECONDARY state. To check the member's state, use the rs.status() method in mongosh.

    4. Repeat the previous steps to downgrade each secondary member.

  2. Downgrade the shard arbiter, if any.

    Skip this step if the replica set does not include an arbiter.

    Downgrade the arbiter member of the sharded cluster:

    1. ノードをシャットダウンします。

      To shut down the arbiter, use mongosh to connect to the arbiter and run the following command:

      db.adminCommand( { shutdown: 1 } )
    2. アービタ データ ディレクトリの内容を削除します。

      アービタmongodのデータディレクトリを見つけるには、 storage.dbPath構成設定または--dbpathコマンドライン オプションのいずれかを確認します。

      次のコマンドを実行します:

      rm -rf /path/to/mongodb/datafiles/*
    3. アービタを再起動します。

      mongodプロセスを開始するには、次のコマンドを実行します。

      mongod --dbpath </path-to-mongodb-datafiles>
    4. ノードがARBITER状態になるまで待ちます。

      Before downgrading the primary, wait for the member to recover to the ARBITER state. To check the member's state, use the rs.status() method in mongosh.

  3. Downgrade the shard primary.

    1. プライマリを降格します。

      In mongosh, use rs.stepDown() to step down the primary and start an election for a new primary:

      rs.stepDown()
    2. プライマリが降格したことを確認します。

      次のコマンドを実行します:

      rs.status()

      Verify that the primary has stepped down and another member has assumed the PRIMARY state.

    3. Shut down the former primary member.

      To shut down the former primary, connect to the deployment using mongosh and run the following command:

      db.adminCommand( { shutdown: 1 } )
    4. Restart the mongod with the 5.0 binary.

      mongodプロセスを開始するには、次のコマンドを実行します。

      mongod --dbpath </path-to-mongodb-datafiles>
    5. Repeat for the remaining shards.

6
  1. Downgrade the shard's secondary members of the config servers replica set (CSRS) one at a time:

    1. セカンダリをシャットダウンします。

      Connect to the secondary and run the following command:

      db.adminCommand( { shutdown: 1 } )
    2. ノードを再起動します。

      mongodプロセスを開始するには、次のコマンドを実行します。

      mongod --dbpath </path-to-data-folder>
    3. ノードがSECONDARY状態になるまで待ちます。

      Before downgrading the next secondary, wait for the member to recover to the SECONDARY state. To check the member's state, use the rs.status() method in mongosh.

    4. Repeat the previous steps to downgrade each secondary member.

  2. Downgrade the config server primary.

    1. プライマリを降格します。

      In mongosh, run rs.stepDown() to step down the primary and start an election for a new primary:

      rs.stepDown()
    2. プライマリが降格したことを確認します。

      次のコマンドを実行します:

      rs.status()

      Verify that the primary has stepped down and another member has assumed the PRIMARY state.

    3. Shut down the former primary member.

      To shut down the former primary, connect to the deployment using mongosh and run the following command:

      db.adminCommand( { shutdown: 1 } )
    4. Restart the mongod with the 5.0 binary.

      mongodプロセスを開始するには、次のコマンドを実行します。

      mongod --dbpath </path-to-mongodb-datafiles>
7

After you downgrade all of the sharded cluster components, connect to a mongos and run the following command to re-enable the balancer:

sh.startBalancer()

The sh.startBalancer() method also enables auto-splitting for the sharded cluster.