MongoDB Enterprise（シャーディングされたクラスター）へのアップグレード

項目一覧

検討事項

エンタープライズバイナリのダウンロード
手順

MongoDB Enterpriseは、次のようなMongoDB Community Editionでは利用できないさまざまな機能を提供しています。

次の手順では、シャーディングされたクラスターを MongoDB Community Edition から MongoDB Enterprise Edition にアップグレードする手順を概説します。たとえば、次の手順を使用して、MongoDB 6.0 Community から MongoDB 6.0 Enterprise にアップグレードできます。

検討事項

警告

別のリリースバージョンにアップグレードする場合は、以下の手順は使用しないでください。リリースバージョンをアップグレードするには、「 MongoDB 6.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 ダウンロードセンターからアーカイブファイルを手動でダウンロードします。
インストールするには、現在のMongoDB Community Editionとは異なるロケーションにファイルを抽出/解凍します。
アップグレード手順では、既存のデータディレクトリと、既存の構成ファイル（該当する場合）を使用します。

バイナリをインストールします。

MongoDB ダウンロードセンターからアーカイブファイルを手動でダウンロードします。
現在のMongoDB Community Editionとは異なるロケーションにファイルを抽出します。ファイルの抽出方法の詳細については、「 macOS 」を参照してください。
アップグレード手順では、既存のデータディレクトリと、既存の構成ファイル（該当する場合）を使用します。

手順

ダウンタイムを最小限に抑えるには、「ローリング」アップグレードを使用して、他のノードが利用可能である間に個別にアップグレードを行い、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 つずつアップグレードします。
1. セカンダリmongodインスタンスをシャットダウンします。
2. 同じ構成mongod （例: 同じデータディレクトリ、構成ファイルなど）。
3. 次のセカンダリノードをアップグレードする前に、ノードがSECONDARY状態に回復するまで待機します。メンバーの状態を確認するには、rs.status() でmongosh を発行します。
残りのセカンダリメンバーごとにを繰り返します。
レプリカセットのプライマリを降格します。
mongoshをプライマリに接続し、 rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選出を強制します。
```
rs.stepDown()
```
rs.status()でプライマリが降格し、別のノードがプライマリであることが示されたら、降格したプライマリをアップグレードします。
1. 降格したプライマリをシャットダウンします。
2. 同じ構成mongod （例: 同じデータディレクトリ、構成ファイルなど）。

シャードをアップグレードします。

シャードを一度に 1 つずつアップグレードします。

各シャードレプリカセット:

レプリカセットのセカンダリノードを一度に 1 つずつアップグレードします。
1. セカンダリmongodインスタンスをシャットダウンします。
2. 同じ構成mongod （例: 同じデータディレクトリ、構成ファイルなど）。
3. 次のセカンダリノードをアップグレードする前に、ノードがSECONDARY状態に回復するまで待機します。メンバーの状態を確認するには、rs.status() でmongosh を発行します。
残りのセカンダリメンバーごとにを繰り返します。
レプリカセットのプライマリを降格します。
mongoshをプライマリに接続し、 rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選出を強制します。
```
rs.stepDown()
```
rs.status()でプライマリが降格し、別のノードがプライマリであることが示されたら、降格したプライマリをアップグレードします。
1. 降格したプライマリをシャットダウンします。
2. 同じ構成mongod （例: 同じデータディレクトリ、構成ファイルなど）。

`mongos`インスタンスをアップグレードします。

mongosインスタンスごとに、 mongosをシャットダウンし、Enterprise mongosで再起動し、同じ構成オプションを指定します。

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

mongoshを使用してクラスター内のmongosに接続し、 sh.startBalancer()を実行してバランサーを再度有効にします。

sh.startBalancer()

MongoDB バージョン 6.0.3 より前では、sh.startBalancer() によってシャーディングされたクラスターの自動分割も有効になります。

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

重要

Enterprise 機能を使用する前に、すべてのメンバーが Enterprise エディションにアップグレードされていることを確認してください。

戻る

レプリカセット

パッケージの整合性の検証