Docs Menu
Docs Home
/
MongoDBマニュアル
/ / /

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

項目一覧

  • アップグレードの推奨事項とチェックリスト
  • 前提条件
  • 5.0 バイナリのダウンロード
  • アップグレード プロセス
  • 追加のアップグレード手順

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

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

5.0へのアップグレードに関するガイダンスが必要な場合は、 MongoDB プロフェッショナル サービスがメジャー バージョン アップグレード サポートを提供して、MongoDB アプリケーションを中断することなくスムーズに移行できるようにします。

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

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

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

MongoDB をアップグレードする前に、MongoDB 5.0の互換性があるドライバーを使用していることを確認してください。 MongoDB 5.0との互換性を確認するには、特定のドライバーのドライバー のドキュメントを参照してください。

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

警告

v3.6 で非推奨になったレガシー命令コードをドライバーが使用している場合は、サポートされている命令コードを使用するバージョンにドライバーを更新してください。 レガシー命令コードを使用するドライバーはサポートされなくなりました。

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

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

5.0にアップグレードしてから、ダウングレードが必要な場合は、 4.4の最新パッチ リリースにダウングレードすることをお勧めします。

シャーディングされたクラスターをアップグレードする前に、 5.0のパフォーマンスに関する注意事項で、 5.0にアップグレードした際に考えられるパフォーマンスへの影響について確認してください。

TTL 構成が有効であることを確認します。アップグレードする前に、expireAfterSecondsNaN に設定されている TTL インデックスを削除または修正してください。MongoDB 5.0 以降では、expireAfterSecondsNaN に設定すると、expireAfterSeconds0 に設定するのと同じ効果があります。詳しくは、「NaN に設定した場合の expireAfterSeconds TTL の動作」を参照してください。

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

シャーディングされたクラスターのノードをアップグレードする前に、そのノードが完全にシャットダウンされている ことを確認してください。

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

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

Tip

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

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

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

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

db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } )

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

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

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

MongoDB を MongoDB の aptyumdnfzypper のいずれかのリポジトリからインストールした場合、5.0 へのアップグレードにはパッケージ マネージャーを使用する必要があります。

Linux システムの場合は、5.0 のインストール手順をご利用ください。新しいリリース用にリポジトリを追加して、実際にアップグレードを行う方法を解説しています。

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

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

警告

MongoDB の既存のインスタンスを MongoDB 5.0.15にアップグレードする場合、 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コマンドはアップグレードされたインスタンスを起動します。

1

mongoshmongosシャーディングされたクラスター内のsh.stopBalancer() インスタンスに接続し、 を実行してバランサーを無効にします。

sh.stopBalancer()

注意

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

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

sh.getBalancerState()

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

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

    1. セカンダリのmongodインスタンスをシャットダウンし、 4.4バイナリを5.0バイナリに置き換えます。

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

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

      構成ファイルを使用している場合は、ファイルを更新してsharding.clusterRole: configsvrreplication.replSetNamenet.portnet.bindIpを指定してから、 5を起動します。 0 バイナリ:

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

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

    3. 次のセカンダリ ノードをアップグレードする前に、ノードがSECONDARY状態に回復するまで待機します。 メンバーの状態を確認するには、rs.status()mongosh を発行します。

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

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

    1. mongoshをプライマリに接続し、 rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選出を強制します。

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

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

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

      構成ファイルを使用している場合は、ファイルを更新してsharding.clusterRole: configsvrreplication.replSetNamenet.portnet.bindIpを指定してから、 5を起動します。 0 バイナリ:

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

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

3

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

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

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

    1. mongod インスタンスをシャットダウンし、4.4 バイナリを 5.0 バイナリに置き換えます。

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

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

      構成ファイルを使用している場合は、ファイルを更新してsharding.clusterRole: shardsvrreplication.replSetNamenet.portnet.bindIpを含めてから、 5を起動します。 0 バイナリ:

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

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

    3. 次のセカンダリ ノードをアップグレードする前に、ノードがSECONDARY状態に回復するまで待機します。 メンバーの状態を確認するには、rs.status()mongosh を発行します。

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

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

    mongoshをプライマリに接続し、 rs.stepDown()を使用してプライマリを降格し、新しいプライマリの選出を強制します。

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

    1. ステップダウンしたプライマリノードをシャットダウンし、mongod バイナリを 5.0 バイナリに置き換えます。

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

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

      構成ファイルを使用している場合は、ファイルを更新してsharding.clusterRole: shardsvrreplication.replSetNamenet.portnet.bindIpを指定してから、 5を起動します。 0 バイナリ:

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

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

4

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

注意

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

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

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

sh.startBalancer()

MongoDB 6.0.3 以降では、自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません。 詳細については、「バランシング ポリシーの変更 」を参照してください。

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

バランサーが有効になっている間に自動分割を有効にしない場合は、 sh.disableAutoSplit()も実行する必要があります。

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

6

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

これらの 5.0 の機能を有効にするには、機能の互換性バージョン(fCV)を 5.0 に設定します。

Tip

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

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

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

db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } )

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

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

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

注意

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

シャードに存在する孤立したドキュメントは、 setFeatureCompatibilityVersionを5.0に設定するとクリーンアップされます。 クリーンアップ プロセス:

注意

追加の考慮事項

機能の互換性バージョン(FCV)mongosのそれよりも大きいmongodインスタンスに接続しようとすると、 mongosバイナリはクラッシュします。 たとえば、MongoDB 4は接続できません。 4 バージョンmongosから5へのアップグレード0 sharded cluster with fCV set to 5.0. ただし、MongoDB 4を接続することはできます。 4 バージョンmongosから5へのアップグレード0 FCV が4に設定されているシャーディングされたクラスターには接続できます。 4 。

戻る

レプリカセット