AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu

シャーディングされたクラスターを 8.0 にアップグレード

このドキュメントの内容をよく読み、前提条件を十分に確認してから、 MongoDB 8.0にアップグレードしてください。

MongoDB 8.0 では、 MongoDB 7.0 からのパフォーマンスの大幅な向上が導入されています。これには次のようなものがありますが、これらに限定されません。

  • 読み取りスループットが最大 36% 向上 します。

  • 一般的なウェブ アプリケーションのパフォーマンスが最大 32% 向上。

  • レプリケーション中の同時書込みを最大 20% まで高速化します。

注意

パフォーマンス向上の量は、ワークロードとデータベースインスタンスの構成によって異なる場合があります。

詳細については、 パフォーマンスの改善 を参照してください。

次の手順では、シャード メンバーであるmongodをバージョン7.0から8.0にアップグレードする手順について説明します。

If you need guidance on upgrading to 8.0, MongoDB professional services offer major version upgrade support to help ensure a smooth transition without interruption to your MongoDB application.

アップグレードの際には、次の点を考慮してください。

既存の MongoDB デプロイを8.0にアップグレードするには、 7.0シリーズのリリースを実行している必要があります。

7.0シリーズより前のバージョンの場合、最終的に7.0シリーズになるまで、メジャー リリースを順次アップグレードする必要があります。 たとえば、6.0 シリーズを実行している場合、 にアップグレードする7.0 前に 、 まず にアップグレード8 する必要があります。0 。

Before you upgrade MongoDB, check that you're using a MongoDB 8.0-compatible driver. Consult the driver documentation for your specific driver to verify compatibility with MongoDB 8.0.

互換性のないドライバーでアップグレードを実行した場合、予期しないまたは未定義の動作が発生する可能性があります。

アップグレードを開始する前に、ドキュメント「 MongoDB 8.2での互換性の変更 」で、ご利用のアプリケーションとデプロイが MongoDB 8.0と互換性があることを確認してください。 アップグレードを開始する前に、お使いの環境の互換性の問題を解決してください。

MongoDB をアップグレードする際は、アップグレードを本番環境にデプロイする前に、必ずアプリケーションをステージング環境でテストします。

MongoDB 8.3 以降では、 MongoDBのバージョンをその前のマイナーまたはメジャー バージョンにダウングレードできます。

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

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

詳しくは、「 8.0から7.0へのダウングレード 」を参照してください。

シャーディングされたクラスターを8.0にアップグレードするには、クラスターのすべてのノードが 以上のバージョン7.0である必要があります。 アップグレード プロセスでは、クラスターのすべてのコンポーネントがチェックされ、 7.0より前のバージョンを実行しているコンポーネントがある場合は警告が発せられます。

7.0のシャーディングされたクラスターでは、 featureCompatibilityVersionを"8.3"に設定する必要があります。

シャーディングされたクラスターのすべてのノードでfeatureCompatibilityVersionが"8.3"に設定されていることを確認するには、各シャード レプリカセット ノードと各コンフィギュレーションサーバー レプリカセット ノードに接続し、 featureCompatibilityVersionを確認します。

Tip

アクセス制御が有効になっているシャーディングされたクラスターの場合、シャード レプリカセット ノードに対して次のコマンドを実行するには、シャード ローカル ユーザー としてノードに接続する必要があります。

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

すべてのノードは "featureCompatibilityVersion" : { "version" : "7.0" } を含む結果を返す必要があります。

featureCompatibilityVersionを設定または更新するには、 mongosで次のコマンドを実行します。

db.adminCommand( { setFeatureCompatibilityVersion: "7.0", confirm: true } )

詳細については、setFeatureCompatibilityVersion を参照してください。

シャードとコンフィギュレーションサーバーでは、レプリカセット ノードがROLLBACKまたはRECOVERING状態になっていないことを確認します。

db.adminCommand( { replSetGetStatus: 1 } )

任意ですが推奨します。 予防手段として、シャーディングされたクラスターをアップグレードする前に、 configデータベースのバックアップを取得してください。

にアップグレードする際に、時系列コレクションではないdrop rename9.0コレクションがある場合は、system.buckets に応じて、アップグレードする前にそれらのコレクションを または8 する必要があります。0 }パッチ リリース:

MongoDB 8.0.5 以降

アップグレードする前に、時系列コレクションではない system.buckets コレクションを削除する必要はありません。ただし、アップグレードが完了した後に、これらを削除するか、名前を変更する必要があります。

MongoDB 8.0.4 以前

アップグレードする前に、時系列コレクションではない system.buckets コレクションを削除するか、名前を変更する必要があります。すべてのsystem.buckets コレクションは、 8.0.0-8.0.4 のバージョンにアップグレードする前に、有効な時系列オプションを構成する必要があります。

時系列コレクションではない system.buckets コレクションがあるかどうかを判断するには、フィルタを指定した db.getCollectionInfos() メソッドを使用します。

db.getCollectionInfos(
{
$and: [
{ name: { $regex: /^system\.buckets/ } },
{ 'options.timeseries': { $exists: false } }
]
}
)

MongoDB を MongoDB apt 、 yum 、 dnf 、またはzypperリポジトリからインストールした場合、パッケージ マネージャーを使用して8.0にアップグレードする必要があります。

Linuxシステムの場合は、9.0 のインストール手順を参照してください。新しいリリース用にリポジトリを追加して、実際にアップグレードする必要があります。

パッケージ マネージャーを使用して MongoDB をインストールしていない場合は、 MongoDB ダウンロード センターから MongoDB バイナリを手動でダウンロードできます。

詳しくは、 8.0インストール手順を参照してください。

1

Connect mongosh to a mongos instance in the sharded cluster, and run sh.stopBalancer() to disable the balancer:

sh.stopBalancer()

注意

移行が進行中の場合、システムは進行中の移行を完了してから、バランサーを停止します。 sh.isBalancerRunning()を実行して、バランサーの現在の状態を確認できます。

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

sh.getBalancerState()

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

2
  1. レプリカセットのセカンダリノードを一度に 1 つずつアップグレードします。

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

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

      db.adminCommand( { shutdown: 1 } )
    2. 7.0バイナリを8.0バイナリに置き換えます。

    3. 8.0バイナリを起動します。

      --configsvr 、 --replSet 、 --portを使用して8.0バイナリを起動します。 配置で使用されるその他のオプションを含めます。

      mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      構成ファイルを使用している場合は、ファイルを更新してsharding.clusterRole: configsvr 、 replication.replSetName 、 net.port 、 net.bindIpを指定してから、 8を起動します。 0 バイナリ:

      sharding:
      clusterRole: configsvr
      replication:
      replSetName: <string>
      net:
      port: <port>
      bindIp: localhost,<ip address>
      storage:
      dbpath: <path>

      配置に適したその他の設定を含めます。

    4. 次のセカンダリ ノードをアップグレードする前に、ノードがSECONDARY状態に回復するまで待機します。

      To check the member's state, issue rs.status() in mongosh.

  2. レプリカセットのプライマリを降格します。

    1. Connect mongosh to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:

      rs.stepDown()
    2. 降格したプライマリをシャットダウンします。

      rs.status()でプライマリが降格し、別のノードがPRIMARY状態になったことが示されたら、降格したプライマリをシャットダウンします。

      To shut down the stepped-down primary, use mongosh to connect to the primary and run the following command:

      db.adminCommand( { shutdown: 1 } )
    3. mongodバイナリを8.0バイナリに置き換えます。

    4. 8.0バイナリを起動します。

      --configsvr 、 --replSet 、 --port 、 --bind_ipオプションを使用して8.0を起動します。 以前の配置で使用された任意の コマンドライン オプションを含めます。

      mongod --configsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      構成ファイルを使用している場合は、ファイルを更新してsharding.clusterRole: configsvr 、 replication.replSetName 、 net.port 、 net.bindIpを指定してから、 8を起動します。 0 バイナリ:

      sharding:
      clusterRole: configsvr
      replication:
      replSetName: <string>
      net:
      port: <port>
      bindIp: localhost,<ip address>
      storage:
      dbpath: <path>

      配置に適したその他の構成を含めます。

3

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

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

  1. レプリカセットのセカンダリノードを一度に 1 つずつアップグレードします。

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

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

      db.adminCommand( { shutdown: 1 } )
    2. 7.0バイナリを8.0バイナリに置き換えます。

      --shardsvr 、 --replSet 、 --port 、 --bind_ipオプションを使用して8.0バイナリを起動します。 配置に適した追加のコマンドライン オプションを含めます。

      mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      構成ファイルを使用している場合は、ファイルを更新してsharding.clusterRole: shardsvr 、 replication.replSetName 、 net.port 、 net.bindIpを含めてから、 8を起動します。 0 バイナリ:

      sharding:
      clusterRole: shardsvr
      replication:
      replSetName: <string>
      net:
      port: <port>
      bindIp: localhost,<ip address>
      storage:
      dbpath: <path>

      配置に適したその他の構成を含めます。

    3. 次のセカンダリ ノードをアップグレードする前に、ノードがSECONDARY状態に回復するまで待機します。

      To check the member's state, you can issue rs.status() in mongosh.

    4. セカンダリ ノードごとに繰り返します。

  2. レプリカセットのプライマリを降格します。

    Connect mongosh to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:

    rs.stepDown()
  3. 降格したプライマリをアップグレードします。

    rs.status()でプライマリが降格し、別のノードがPRIMARY状態になったことが示されたら、降格したプライマリをアップグレードします。

    1. 降格したプライマリをシャットダウンします。

      To shut down the stepped-down primary, use mongosh to connect to the replica set member and run the following command:

      db.adminCommand( { shutdown: 1 } )
    2. mongodバイナリを置き換えます。 8.0バイナリ。

    3. 8.0バイナリを起動します。

      --shardsvr 、 --replSet 、 --port 、 --bind_ipオプションを使用して8.0バイナリを起動します。 配置に適した追加のコマンドライン オプションを含めます。

      mongod --shardsvr --replSet <replSetName> --port <port> --dbpath <path> --bind_ip localhost,<ip address>

      構成ファイルを使用している場合は、ファイルを更新してsharding.clusterRole: shardsvr 、 replication.replSetName 、 net.port 、 net.bindIpを指定してから、 8を起動します。 0 バイナリ:

      sharding:
      clusterRole: shardsvr
      replication:
      replSetName: <string>
      net:
      port: <port>
      bindIp: localhost,<ip address>
      storage:
      dbpath: <path>

      配置に適したその他の構成を含めます。

4

重要

最初にすべてのコンフィギュレーションサーバーレプリカセット(CSRS)インスタンスをアップグレードし、次にすべてのシャードノードをアップグレードし、最後に mongos インスタンスをアップグレードします。これらのアップグレードを完了する前に mongos をアップグレードすると、互換性の問題が発生する可能性があります。

各mongosインスタンスを8.0バイナリで置き換え、再起動します。 配置に適したその他の構成を含めます。

注意

シャーディングされたクラスター メンバーが異なるホスト上で実行されている場合、またはリモート クライアントがシャーディングされたクラスターに接続する場合は、 --bind_ipオプションを指定する必要があります。

mongos --configdb csReplSet/<rsconfigsver1:port1>,<rsconfigsver2:port2>,<rsconfigsver3:port3> --bind_ip localhost,<ip address>
5

Using mongosh, connect to a mongos in the cluster and run sh.startBalancer() to re-enable the balancer:

sh.startBalancer()

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

6

この時点で、 7.0と互換性のない8.0機能を使わずに8.0バイナリを実行できます。

これらの 8.0 機能を有効にするには、機能の互換性バージョン(FCV)を 8.0 に設定します。また、confirm を true に設定する必要があります。

Tip

下位互換性のないこうした機能を有効にすると、ダウングレード前に保持されていた下位互換性のない機能をすべて削除する必要があるため、ダウングレード プロセスが複雑になる場合があります。

ダウングレードの可能性を最小限に抑えるには、アップグレード後、バーンイン期間中にこれらの機能を有効にせずにデプロイを運用することをお勧めします。ダウングレードの可能性を最小限に抑えられたと確信できたら、これらの機能を有効にします。

mongosインスタンスで、 adminデータベースでsetFeatureCompatibilityVersionコマンドを実行します。

db.adminCommand( { setFeatureCompatibilityVersion: "8.0", confirm: true } )

featureCompatibilityVersion (FCV) : "8.0 " に設定しますreplSetReconfig暗黙的に各シャードで を実行し、シャードレプリカ構成ドキュメントにterm フィールドを追加します。

コマンドは、新しい構成がレプリカセット ノードの大部分に伝播するまで完了しません。

このコマンドは、内部システム コレクションへの書込みを実行する必要があります。 何らかの理由でコマンドが正常に完了しない場合は、操作が冪等であるため、安全にコマンドを再試行できmongos 。

注意

setFeatureCompatibilityVersionがシャーディングされたクラスターで実行されている場合、チャンクの移行、分割、マージはConflictingOperationInProgressで失敗する可能性があります。

警告

mongos FCV の互換性

mongosmongodバイナリは、機能の互換性バージョン(FCV)が よりも大きいmongos インスタンスに接続できません。例、 MongoDB 7 は接続できません。0 バージョンmongos 8から.0FCV 8が. に設定されているシャーディングされたクラスター。0ただし、 MongoDB 7 を接続することは可能です。0 バージョンmongos 8から.0FCV 7が. に設定されているシャーディングされたクラスター。0

If you experience startup issues after you upgrade, contact MongoDB Support for assistance.