シャーディングされたクラスターを 6.0 にアップグレード
警告
MongoDB 6.0.3でのバランシング ポリシーの更新により、チャンク数が同じままであっても、バランサーはアップグレード後すぐに起動することがあります。
このドキュメントの内容をよく読み、前提条件を十分に確認してから、MongoDB 6.0 にアップグレードしてください。
次の手順では、シャード メンバーである mongod
をバージョン 5.0 から 6.0 にアップグレードする手順について説明します。
6.0へのアップグレードに関するガイダンスが必要な場合は、 MongoDB プロフェッショナル サービスがメジャー バージョン アップグレード サポートを提供して、MongoDB アプリケーションを中断することなくスムーズに移行できるようにします。
アップグレードの推奨事項とチェックリスト
アップグレードの際には、次の点を考慮してください。
アップグレード バージョン パス
既存の MongoDB デプロイを 6.0 にアップグレードするには、5.0 シリーズのリリースを実行している必要があります。
5.0 シリーズより前のバージョンの場合、最終的に 5.0 シリーズになるまで、メジャー リリースを順次アップグレードする必要があります。たとえば、4.4 シリーズを実行している場合、まず 5.0 にアップグレードした後に、6.0 にアップグレードする必要があります。
ドライバーの互換性を確認
MongoDB をアップグレードする前に、MongoDB 6.0の互換性があるドライバーを使用していることを確認してください。 MongoDB 6.0との互換性を確認するには、特定のドライバーのドライバー のドキュメントを参照してください。
互換性のないドライバーでアップグレードを実行した場合、予期しないまたは未定義の動作が発生する可能性があります。
警告
v3.6 で非推奨になったレガシー命令コードをドライバーが使用している場合は、サポートされている命令コードを使用するバージョンにドライバーを更新してください。 レガシー命令コードを使用するドライバーはサポートされなくなりました。
事前対策
アップグレードを開始する前に、ドキュメント「MongoDB 6.0 での互換性の変更」で、ご利用のアプリケーションとデプロイが MongoDB 6.0 と互換性があることを確認してください。アップグレードを開始する前に、お使いの環境の互換性の問題を解決してください。
MongoDB をアップグレードする際は、アップグレードを本番環境にデプロイする前に、必ずアプリケーションをステージング環境でテストします。
ダウングレードの検討事項
6.0 にアップグレードした後にダウングレードする必要がある場合は、5.0 の最新パッチ リリースにダウングレードすることをお勧めします。
前提条件
全ノードのバージョン
シャーディングされたクラスターを6.0にアップグレードするには、クラスターのすべてのノードが 以上のバージョン5.0である必要があります。 アップグレード プロセスでは、クラスターのすべてのコンポーネントがチェックされ、 5.0より前のバージョンを実行しているコンポーネントがある場合は警告が発せられます。
機能の互換性バージョン
5.0のシャーディングされたクラスターでは、 featureCompatibilityVersion
を"5.0"
に設定する必要があります。
シャーディングされたクラスターのすべてのノードでfeatureCompatibilityVersion
が"5.0"
に設定されていることを確認するには、各シャード レプリカセット ノードと各コンフィギュレーションサーバー レプリカセット ノードに接続し、 featureCompatibilityVersion
を確認します。
Tip
アクセス制御が有効になっているシャーディングされたクラスターの場合、シャード レプリカセット ノードに対して次のコマンドを実行するには、シャード ローカル ユーザー としてノードに接続する必要があります。
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
すべてのノードは "featureCompatibilityVersion" : { "version" : "5.0" }
を含む結果を返す必要があります。
featureCompatibilityVersion
を設定または更新するには、 mongos
で次のコマンドを実行します。
db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } )
レプリカセット ノードの状態
シャードとコンフィギュレーションサーバーでは、レプリカセット ノードがROLLBACK
またはRECOVERING
状態になっていないことを確認します。
config
データベースのバックアップ
任意ですが推奨します。 予防手段として、シャーディングされたクラスターをアップグレードする前に、 config
データベースのバックアップを取得してください。
6.0 バイナリのダウンロード
パッケージ マネージャーの使用
MongoDB を MongoDB の apt
、yum
、dnf
、zypper
のいずれかのリポジトリからインストールした場合、6.0 へのアップグレードにはパッケージ マネージャーを使用する必要があります。
Linux システムの場合は、6.0 のインストール手順を参照してください。新しいリリース用にリポジトリを追加して、実際にアップグレードを行う方法を解説しています。
ダウンロード6.0 手動でバイナリ化
パッケージ マネージャーを使用して MongoDB をインストールしていない場合は、 MongoDB ダウンロード センターから MongoDB バイナリを手動でダウンロードできます。
詳しくは、6.0 インストール手順を参照してください。
アップグレード手順
警告
MongoDB の既存のインスタンスを MongoDB 6.0.5 にアップグレードする場合、 mongod.conf
ファイルにfork: true
が設定されていると、そのインスタンスが起動に失敗する可能性があります。
アップグレードの問題は、 .deb
または.rpm
インストール パッケージを使用するすべての MongoDB インスタンスに影響します。 tarball( .tgz
)リリースまたはその他のパッケージ タイプを使用するインストールは影響を受けません。 詳細については、 SERVER-74345 を参照してください。
fork: true
設定を削除するには、システム ターミナルから次のコマンドを実行します。
systemctl stop mongod.service sed -i.bak '/fork: true/d' /etc/mongod.conf systemctl start mongod.service
設定が削除された後に、2 番目のsystemctl
コマンドはアップグレードされたインスタンスを起動します。
バランサーを無効にします。
mongosh
mongos
シャーディングされたクラスター内のsh.stopBalancer()
インスタンスに接続し、 を実行してバランサーを無効にします。
sh.stopBalancer()
注意
移行が進行中の場合、システムは進行中の移行を完了してから、バランサーを停止します。 sh.isBalancerRunning()
を実行して、バランサーの現在の状態を確認できます。
バランサーが無効になっていることを確認するには、 sh.getBalancerState()
を実行します。バランサーが無効になっている場合は false を返します。
sh.getBalancerState()
バランサーを無効にする方法の詳細については、「 バランサーを無効にする 」を参照してください。
各 のキャッシュされたルーティングmongos
テーブルを更新します。
クラスター内の各mongos
について、 mongosh
をmongos
インスタンスに接続し、 flushRouterConfig
を実行してキャッシュされたルーティング テーブルを更新します。
db.adminCommand("flushRouterConfig") db.adminCommand( { flushRouterConfig: 1 } )
コンフィギュレーションサーバーをアップグレードします。
レプリカセットのセカンダリノードを一度に 1 つずつアップグレードします。
セカンダリ インスタンスをシャットダウンします。
mongod
プロセスをシャットダウンするには、mongosh
を使用してクラスター ノードに接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) 5.0 バイナリを 6.0 バイナリに置き換えます。
6.0バイナリを起動します。
--configsvr
、--replSet
、--port
を使用して6.0バイナリを起動します。 配置で使用されるその他のオプションを含めます。mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> 構成ファイルを使用している場合は、ファイルを更新して
sharding.clusterRole: configsvr
、replication.replSetName
、net.port
、net.bindIp
を指定してから、6.0 バイナリを起動します。sharding: clusterRole: configsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> 配置に適したその他の設定を含めます。
次のセカンダリ ノードをアップグレードする前に、ノードが
SECONDARY
状態に回復するまで待機します。メンバーの状態を確認するには、
rs.status()
でmongosh
を発行します。セカンダリ ノードごとに繰り返します。
レプリカセットのプライマリを降格します。
プライマリを降格します。
mongosh
をプライマリに接続し、rs.stepDown()
を使用してプライマリを降格し、新しいプライマリの選出を強制します。rs.stepDown() 降格したプライマリをシャットダウンします。
rs.status()
でプライマリが降格し、別のノードがPRIMARY
状態になったことが示されたら、降格したプライマリをシャットダウンします。降格したプライマリをシャットダウンするには、
mongosh
を使用してプライマリに接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) mongod
バイナリを6.0バイナリに置き換えます。6.0バイナリを起動します。
--configsvr
、--replSet
、--port
、--bind_ip
オプションを使用して6.0を起動します。 以前の配置で使用された任意の コマンドライン オプションを含めます。mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> 構成ファイルを使用している場合は、ファイルを更新して
sharding.clusterRole: configsvr
、replication.replSetName
、net.port
、net.bindIp
を指定してから、6.0 バイナリを起動します。sharding: clusterRole: configsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> 配置に適したその他の構成を含めます。
シャード をアップグレードします。
シャードを一度に 1 つずつアップグレードします。
各シャード レプリカセットについて、レプリカセットのセカンダリノードを一度に 1 つずつアップグレードします。
セカンダリ インスタンスをシャットダウンします。
mongod
プロセスをシャットダウンするには、mongosh
を使用してクラスター ノードに接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) 5.0 バイナリを 6.0 バイナリに置き換えます。
--shardsvr
、--replSet
、--port
、--bind_ip
オプションを使用して6.0バイナリを起動します。 配置に適した追加のコマンドライン オプションを含めます。mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> 構成ファイルを使用している場合は、ファイルを更新して
sharding.clusterRole: shardsvr
、replication.replSetName
、net.port
、net.bindIp
を含めてから、 6を起動します。 0 バイナリ:sharding: clusterRole: shardsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> 配置に適したその他の構成を含めます。
次のセカンダリ ノードをアップグレードする前に、ノードが
SECONDARY
状態に回復するまで待機します。メンバーの状態を確認するには、
rs.status()
でmongosh
を発行します。セカンダリ ノードごとに繰り返します。
レプリカセットのプライマリを降格します。
mongosh
をプライマリに接続し、rs.stepDown()
を使用してプライマリを降格し、新しいプライマリの選出を強制します。rs.stepDown() 降格したプライマリをアップグレードします。
rs.status()
でプライマリが降格し、別のノードがPRIMARY
状態になったことが示されたら、降格したプライマリをアップグレードします。降格したプライマリをシャットダウンします。
降格したプライマリをシャットダウンするには、
mongosh
を使用してレプリカセット ノードに接続し、次のコマンドを実行します。db.adminCommand( { shutdown: 1 } ) mongod
バイナリを6.0バイナリに置き換えます。6.0バイナリを起動します。
--shardsvr
、--replSet
、--port
、--bind_ip
オプションを使用して6.0バイナリを起動します。 配置に適した追加のコマンドライン オプションを含めます。mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address> 構成ファイルを使用している場合は、ファイルを更新して
sharding.clusterRole: shardsvr
、replication.replSetName
、net.port
、net.bindIp
を指定してから、6.0 バイナリを起動します。sharding: clusterRole: shardsvr replication: replSetName: <string> net: port: <port> bindIp: localhost,<ip address> storage: dbpath: <path> 配置に適したその他の構成を含めます。
mongos
インスタンスをアップグレードします。
各mongos
インスタンスを6.0バイナリで置き換え、再起動します。 配置に適したその他の構成を含めます。
注意
シャーディングされたクラスター メンバーが異なるホスト上で実行されている場合、またはリモート クライアントがシャーディングされたクラスターに接続する場合は、 --bind_ip
オプションを指定する必要があります。
mongos --configdb csReplSet/<rsconfigsver1:port1>,<rsconfigsver2:port2>,<rsconfigsver3:port3> --bind_ip localhost,<ip address>
バランサーを再度有効にします。
mongosh
を使用してクラスター内のmongos
に接続し、 sh.startBalancer()
を実行してバランサーを再度有効にします。
sh.startBalancer()
MongoDB 6.0.3 以降では、自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。 詳細については、「バランシング ポリシーの変更 」を参照してください。
MongoDB バージョン 6.0.3 より前では、sh.startBalancer()
によってシャーディングされたクラスターの自動分割も有効になります。
バランサーが有効になっている間に自動分割を有効にしない場合は、 sh.disableAutoSplit()
も実行する必要があります。
バランサーを再度有効にする方法の詳細については、「 バランサーを有効にする 」を参照してください。
下位互換性のない 6.0 の機能を有効にします。
この時点で、6.0 と互換性のない 6.0 の機能を使わずに 6.0 のバイナリを実行できます。
これらの 6.0 の機能を有効にするには、機能の互換性バージョン(fCV
)を 6.0 に設定します。
Tip
下位互換性のないこうした機能を有効にすると、ダウングレード前に保持されていた下位互換性のない機能をすべて削除する必要があるため、ダウングレード プロセスが複雑になる場合があります。
ダウングレードの可能性を最小限に抑えるには、アップグレード後、バーンイン期間中にこれらの機能を有効にせずにデプロイを運用することをお勧めします。ダウングレードの可能性を最小限に抑えられたと確信できたら、これらの機能を有効にします。
mongos
インスタンスで、 admin
データベースでsetFeatureCompatibilityVersion
コマンドを実行します。
db.adminCommand( { setFeatureCompatibilityVersion: "6.0" } )
featureCompatibilityVersion (fCV) : " 6.0 " に設定します は暗黙的に各シャードでreplSetReconfig
を実行し、シャード レプリカ構成ドキュメントにterm
フィールドを追加します。
コマンドは、新しい構成がレプリカセット ノードの大部分に伝播するまで完了しません。
このコマンドは、内部システム コレクションへの書込みを実行する必要があります。 何らかの理由でコマンドが正常に完了しない場合は、操作が冪等であるため、安全にコマンドを再試行できmongos
。
注意
setFeatureCompatibilityVersion
がシャーディングされたクラスターで実行されている場合、チャンクの移行、分割、マージはConflictingOperationInProgress
で失敗する可能性があります。
シャードに存在する孤立したドキュメントは、 setFeatureCompatibilityVersion
を6.0に設定するとクリーンアップされます。 クリーンアップ プロセス:
アップグレードの完了をブロックしません。
レート制限されています。 孤立したドキュメントのクリーンアップ中にパフォーマンスへの潜在的な影響を軽減するには、「範囲削除によるパフォーマンスへの影響を軽減する 」を参照してください。
注意
追加の考慮事項
機能の互換性バージョン(FCV)がmongos
のそれよりも大きいmongod
インスタンスに接続しようとすると、 mongos
バイナリはクラッシュします。 たとえば、MongoDB 5.0 バージョンmongos
をfCVが 6.0 に設定されている 6.0 のシャーディングされたクラスターに接続することはできません。 ただし、 fCV を 5.0 に設定して、MongoDB 5.0 バージョン をmongos
6.0 のシャーディングされたクラスターに接続することは可能です。
追加のアップグレード手順
スタンドアロンをアップグレードするには、「スタンドアロンの 6.0 へのアップグレード」を参照してください。
レプリカセットをアップグレードするには、「レプリカセットを 6.0 にアップグレードする」を参照してください。