MongoDB Enterprise（シャーディングされたクラスター）へのアップグレード
MongoDB Enterpriseは 、次のようなMongoDB Community Editionでは利用できないさまざまな機能を提供しています。
次の手順では、シャーディングされたクラスターを MongoDB Community Edition から MongoDB Enterprise Edition にアップグレードする手順を概説します。 たとえば、次の手順を使用して MongoDB 7.0をアップグレードできます MongoDB 7.0へのコミュニティ Enterprise。
検討事項
警告
別のリリース バージョンにアップグレードする場合は、以下の手順は使用しないでください。リリースバージョンをアップグレードするには、「MongoDB 8.0 へのアップグレード」など、適切なリリースのアップグレード手順を参照してください。
エンタープライズ バイナリのダウンロード
オペレーティング システムに応じて、パッケージ マネージャーを使用するか、バイナリを手動でダウンロードして、MongoDB Enterprise バイナリをインストールできます。
パッケージ マネージャーを使用して MongoDB Community をインストールした場合は、ご使用のオペレーティング システムのパッケージ マネージャーの手順に従います。
インストール中に、パッケージ マネージャーはコミュニティ パッケージを削除します。これは再起動するまで実行中の配置には影響しません。
パッケージ マネージャーを使用して MongoDB をインストールしていない場合は、 MongoDB ダウンロード センターから MongoDB バイナリを手動でダウンロードできます。 MongoDB Enterprise の特定の前提条件を含む、お使いのオペレーティング システムのマニュアル手順に従います。
重要
現在の MongoDB Community Edition とは異なるロケーションにインストールします。
アップグレード手順では、既存のデータディレクトリと、既存の構成ファイル（該当する場合）を使用します。
重要
同じリリース シリーズの が同じマシンにインストールされている場合、{0 を使用して.msi Enterprise エディションをインストールすることはできません。MongoDB Community Editionつまり、バージョン4.4.0の場合 MongoDB Community Editionがインストールされている場合、.msi を使用して 4.4.0 または 4.4 をインストールすることはできません。1 エンタープライズ エディション。
インストールするには、 現在のMongoDB Community Editionとは異なるロケーションに ファイルを抽出/解凍します。
アップグレード手順では、既存のデータディレクトリと、既存の構成ファイル（該当する場合）を使用します。
バイナリをインストールします。
現在のMongoDB Community Editionとは異なるロケーションに ファイルを抽出します。 ファイルの抽出方法の詳細については、「 macOS 」を参照してください。
アップグレード手順では、既存のデータディレクトリと、既存の構成ファイル（該当する場合）を使用します。
始める前に
MongoDB 8.0以降では、 directShardOperationsロールを使用して、シャードに対してコマンドを直接実行する必要があるメンテナンス操作を実行できます。
警告
directShardOperationsロールを使用して コマンドを実行すると、クラスターが正しく動作しなくなり、データが破損する可能性があります。 directShardOperationsロールは、メンテナンス目的で、または MongoDB サポートのガイダンスに必ず従う必要があります。 メンテナンス操作を実行したら、 directShardOperationsロールの使用を停止します。
手順
ダウンタイムを最小限に抑えるには、「ローリング」アップグレードを使用して、他のノードが利用可能である間に個別にアップグレードを行い、MongoDB Community から Enterprise Edition にアップグレードします。
バランサーを無効にします。
mongoshmongosシャーディングされたクラスター内のsh.stopBalancer() インスタンスに接続し、 を実行してバランサーを無効にします。
sh.stopBalancer()
注意
移行が進行中の場合、システムは進行中の移行を完了してから、バランサーを停止します。 sh.isBalancerRunning()を実行して、バランサーの現在の状態を確認できます。
バランサーが無効になっていることを確認するには、 sh.getBalancerState()を実行します。バランサーが無効になっている場合は false を返します。
sh.getBalancerState()
MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。
MongoDB バージョン 6.0.3 より前では、sh.stopBalancer() によってシャーディングされたクラスターの自動分割も無効になります。
バランサーを無効にする方法の詳細については、「 バランサーを無効にする 」を参照してください。
コンフィギュレーションサーバーをアップグレードします。
レプリカセットのセカンダリノードを一度に 1 つずつアップグレードします。
セカンダリ
mongodインスタンスをシャットダウンします。同じ構成
mongod（例: 同じデータディレクトリ、構成ファイルなど）。次のセカンダリ ノードをアップグレードする前に、ノードが
SECONDARY状態に回復するまで待機します。 メンバーの状態を確認するには、rs.status()でmongoshを発行します。
残りのセカンダリ メンバーごとにを繰り返します。
レプリカセットのプライマリを降格します。
mongoshをプライマリに接続し、rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選出を強制します。rs.stepDown() rs.status()でプライマリが降格し、別のノードがプライマリであることが示されたら、降格したプライマリをアップグレードします。降格したプライマリをシャットダウンします。
同じ構成
mongod（例: 同じデータディレクトリ、構成ファイルなど）。
シャード をアップグレードします。
シャードを一度に 1 つずつアップグレードします。
各シャード レプリカセット:
レプリカセットのセカンダリノードを一度に 1 つずつアップグレードします。
セカンダリ
mongodインスタンスをシャットダウンします。同じ構成
mongod（例: 同じデータディレクトリ、構成ファイルなど）。次のセカンダリ ノードをアップグレードする前に、ノードが
SECONDARY状態に回復するまで待機します。 メンバーの状態を確認するには、rs.status()でmongoshを発行します。
残りのセカンダリ メンバーごとにを繰り返します。
レプリカセットのプライマリを降格します。
mongoshをプライマリに接続し、rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選出を強制します。rs.stepDown() rs.status()でプライマリが降格し、別のノードがプライマリであることが示されたら、降格したプライマリをアップグレードします。降格したプライマリをシャットダウンします。
同じ構成
mongod（例: 同じデータディレクトリ、構成ファイルなど）。
バランサーを再度有効にします。
mongoshを使用してクラスター内のmongosに接続し、 sh.startBalancer()を実行してバランサーを再度有効にします。
sh.startBalancer()
MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。
MongoDB バージョン 6.0.3 より前では、sh.startBalancer() によってシャーディングされたクラスターの自動分割も有効になります。
バランサーの詳細については、「 バランサーを有効にする 」を参照してください。
重要
Enterprise 機能を使用する前に、すべてのメンバーが Enterprise エディションにアップグレードされていることを確認してください。