6.0 のシャーディングされたクラスターを 5.0 にダウングレードする

項目一覧

ダウングレードパス
前提条件
ダウングレード手順

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

ダウングレードパス

重要

シャーディングされたクラスターをアップグレードまたはダウングレードする前に、すべてのシャーディングされたクラスターのメンバーが実行されていることを確認してください。そうしないと、すべてのメンバーが起動されるまでアップグレードまたはダウングレードは完了しません。

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

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

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

前提条件

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

バックアップの作成

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

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

下位互換性のない機能を削除する

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

リシャーディング操作が進行中でないことを確認する

リシャーディング操作が正常に完了したことを確認します。プライマリフェイルオーバーが原因で最近のリシャーディング操作が失敗した場合は、シャーディングされたクラスターのfeatureCompatibilityVersionをダウングレードする前に、まずcleanupReshardCollectionコマンドを実行する必要があります。

シャーディングされたクラスターのfeatureCompatibilityVersionをダウングレードするときにリシャーディング操作がまだ実行中の場合、リシャーディング操作は完了しません。

ダウングレード機能の互換性バージョン（FCV）

シャーディングされたクラスターの FCV をダウングレードするには、以下の手順を行います。

最初の同期が進行中でないことを確認します。最初の同期の進行中にsetFeatureCompatibilityVersionコマンドを実行すると、最初の同期がリスタートされます。
レプリカセット構成にnewlyAddedフィールドがないノードがないことを確認します。これを確認するには、レプリカセット内の各ノードで次のコマンドを実行します。
```
use local
db.system.replset.find( { "members.newlyAdded" : { $exists : true } } );
```
newlyAddedフィールドは、最初の同期の実行中とその直後にのみ、ノードのレプリカセット構成ドキュメントにのみ表示されます。
レプリカセットノードがROLLBACKまたはRECOVERING状態になっていないことを確認します。
mongoshを使用してmongosインスタンスに接続します。
featureCompatibilityVersionを"5.0"にダウングレードします。
```
db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } )
```
setFeatureCompatibilityVersionコマンドは内部システムコレクションへの書込みを実行し、冪等です。コマンドが正常に完了しない場合は、 mongosインスタンスでコマンドを再試行してください。
注意
トラブルシューティング
- setFeatureCompatibilityVersionがシャーディングされたクラスターで実行されている場合、チャンクの移行、分割、マージはConflictingOperationInProgressで失敗する可能性があります。
- setFeatureCompatibilityVersionがManualInterventionRequiredエラーで失敗し、クラスターが最近再シャーディング操作を実行していて、選挙が原因で失敗した場合は、 setFeatureCompatibilityVersionを再度実行する前にcleanupReshardCollectionコマンドを実行する必要があります。
レプリカセットのすべてのノードに更新されたfeatureCompatibilityVersionが適用されていることを確認するには、各レプリカセットノードに接続し、 featureCompatibilityVersionを確認します。
```
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
```
Tip
アクセス制御
アクセス制御が有効になっているシャーディングされたクラスターの場合、シャードレプリカセットメンバーでadminCommandを実行するには、シャードローカルユーザーとしてメンバーに接続する必要があります。
すべてのノードは次の内容を含む結果を返す必要があります。
```
"featureCompatibilityVersion" : { "version" : "5.0" }
```
いずれかのノードが"6.0"のfeatureCompatibilityVersionを返す場合は、続行する前にノードがバージョン"5.0"を返すまで待機します。

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

ダウングレード手順

警告

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

重要

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

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

6.0 バイナリをダウンロードした 5.0 バイナリに置き換えます。

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

mongod --version

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

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

バランサーを無効にするには、 mongoshをシャーディングされたクラスター内のmongosインスタンスに接続し、次のコマンドを実行します。

sh.stopBalancer()

注意

移行が進行中の場合、MongoDB はバランサーを停止する前に、進行中の移行を完了します。バランサーの現在の状態を確認するには、 sh.isBalancerRunning()を実行します。

バランサーが無効になっていることを確認するには、次のコマンドを実行します。

sh.getBalancerState()

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

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

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

mongosを停止するには、次のコマンドを実行します。
```
db.shutdownServer()
```
5.0 バイナリでmongosを再起動します。

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

シャードのセカンダリノードを一度に 1 つずつダウングレードします。
1. ノードをシャットダウンします。
  mongodプロセスをシャットダウンするには、 mongoshを使用して配置に接続し、次のコマンドを実行します。
  db.adminCommand( { shutdown: 1 } )
2. ノードを再起動します。
  mongodプロセスを開始するには、次のコマンドを実行します。
  mongod --dbpath </path-to-data-folder>
3. ノードがSECONDARY状態になるまで待ちます。
  次のセカンダリをダウングレードする前に、ノードがSECONDARY状態に回復するまで待ちます。メンバーの状態を確認するには、rs.status() mongoshでメソッドを使用します。
4. 前の手順を繰り返して、各セカンダリノードをダウングレードします。
シャードアービタ（存在する場合）をダウングレードします。
レプリカセットにアービタが含まれていない場合は、この手順をスキップします。
シャーディングされたクラスターのアービタノードをダウングレードします。
1. ノードをシャットダウンします。
  アービタをシャットダウンするには、 mongoshを使用してアービタに接続し、次のコマンドを実行します。
  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状態になるまで待ちます。
  プライマリをダウングレードする前に、ノードがARBITER状態に回復するまで待ちます。メンバーの状態を確認するには、rs.status() mongoshでメソッドを使用します。
シャードプライマリをダウングレードします。
1. プライマリを降格します。
  mongoshでは、 rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選挙を開始します。
  rs.stepDown()
2. プライマリが降格したことを確認します。
  次のコマンドを実行します:
  rs.status()
  プライマリが降格し、別のノードがPRIMARY状態になったことを確認します。
3. 以前のプライマリノードをシャットダウンします。
  以前のプライマリをシャットダウンするには、 mongoshを使用して配置に接続し、次のコマンドを実行します。
  db.adminCommand( { shutdown: 1 } )
4. 5.0バイナリを使用してmongodを再起動します。
  mongodプロセスを開始するには、次のコマンドを実行します。
  mongod --dbpath </path-to-mongodb-datafiles>
5. 残りのシャードに対してを繰り返します。

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

コンフィギュレーションサーバーレプリカセット（CSRS）のシャードのセカンダリノードを一度に 1 つずつダウングレードします。
1. セカンダリをシャットダウンします。
  セカンダリに接続し、次のコマンドを実行します。
  db.adminCommand( { shutdown: 1 } )
2. ノードを再起動します。
  mongodプロセスを開始するには、次のコマンドを実行します。
  mongod --dbpath </path-to-data-folder>
3. ノードがSECONDARY状態になるまで待ちます。
  次のセカンダリをダウングレードする前に、ノードがSECONDARY状態に回復するまで待ちます。メンバーの状態を確認するには、rs.status() mongoshでメソッドを使用します。
4. 前の手順を繰り返して、各セカンダリノードをダウングレードします。
コンフィギュレーションサーバーのプライマリをダウングレードします。
1. プライマリを降格します。
  mongoshで、 rs.stepDown()を実行してプライマリを降格し、新しいプライマリの選挙を開始します。
  rs.stepDown()
2. プライマリが降格したことを確認します。
  次のコマンドを実行します:
  rs.status()
  プライマリが降格し、別のノードがPRIMARY状態になったことを確認します。
3. 以前のプライマリノードをシャットダウンします。
  以前のプライマリをシャットダウンするには、 mongoshを使用して配置に接続し、次のコマンドを実行します。
  db.adminCommand( { shutdown: 1 } )
4. 5.0バイナリを使用してmongodを再起動します。
  mongodプロセスを開始するには、次のコマンドを実行します。
  mongod --dbpath </path-to-mongodb-datafiles>

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

シャーディングされたクラスターのすべてのコンポーネントをダウングレードした後、 mongosに接続し、次のコマンドを実行してバランサーを再度有効にします。

sh.startBalancer()

sh.startBalancer()メソッドも、シャーディングされたクラスターの自動分割を有効にします。

戻る

レプリカセット

変更履歴