移行制限およびサポートされていないシナリオ

プロジェクトごとに 1 つの配置

MongoDB Ops ManagerまたはCloud Managerプロジェクトには、配置が1つだけ含まれている必要があります。プロジェクトに複数の配置が含まれている場合、kubectl mongodbプラグインはエラーになります。

プロジェクトに複数の配置が含まれている場合は、移行する前にそれらを個別のプロジェクトに分裂してください。その方法については、MongoDB配置の新しいプロジェクトへの移行（MongoDB Ops Managerドキュメント内）を参照してください。

埋め込み型コンフィギュレーションサーバーはサポートされていません

クラスターのコンフィギュレーションサーバーがそのシャードの 1 つによってもバックアップされている場合、移行することができません。Kubernetes 演算子は、埋め込まれたコンフィギュレーションサーバーを検出し、インポート時の移行を拒否します。

受信接続性は自動で検証されません

ドライランでは、Kubernetes からバーチャル マシンへの接続のみが検証されます。VM から Kubernetes へのインバウンド接続性を自動的に確認しません。それを信頼する前に、接続の方向を自身で確認してください。

自動ロールバックなし

移行が開始された後に、その移行を元に戻す自動化された方法はありません。プラグインや演算子を使用して元に戻すことはできないため、移行を計画し、開始する前にバックアップを作成してください。

進行中の移行を手動でロールバックするには、次の手順を実行します。

シーディングまたはプレコピーなし

移行は、MongoDBのレプリケーションのみを使用してデータを移動します。Kubernetes 演算子は、他のメカニズムを通じて新しいKubernetesノードにデータをシードしたり、事前にコピーしたりすることはありません。

自動削除なし

外部ノードを除く操作は手動で行います。spec.externalMembers からエントリを一度に 1 つずつ除きます。演算子はこのステップを自動化しません。

MongoDB Ops Manager それ自体は移行されない

このワークフローは、MongoDB Ops Manager または Cloud Manager がマネージドする MongoDB 配置のみを移行します。これは、Ops Manager または Cloud Manager 自体を移行しません。

移行中の構成凍結

移行の進行中は、移行手順以外の配置に対するバージョンや構成の変更を行わないでください。移行中は、MongoDB Ops Manager UI を介した同時編集もサポートされていません。

移行そのものの一環として、いくつかのフィールドが変更されることが予想されます。

• ノード数および memberConfig 内の votes および priority フィールドは、ノードを拡張、プロモート、プルーンすると変化します。

その他の設定は、移行中はソース配置と一致させる必要があり、変更しないでください。

• MongoDB バージョン

• 機能の互換性バージョン

• ポート

• 認証モード

• 内部クラスター認証

新しいノードに引き継がれない設定

Kubernetes 演算子は新しいKubernetesノードでこれらの設定を再現しないため、移行する前に計画を立ててください。

• secondaryDelaySecs 遅延ノードで。

• 非表示メンバーの非表示設定。

• buildIndexes ノードで false に設定します。

バーチャル マシン上で分析ノードまたは遅延ノードを実行する場合は、ノードがレプリカセットに参加した後、Kubernetes ノード上で同等の設定を自身で再構成してください。

MongoDBMultiClusterではサポートされていません

Kubernetes 演算子は、MongoDBMultiCluster リソースでの移行をサポートしていません。spec.externalMembers フィールドは、意図的にその CRD に追加されなかった。MongoDBProject CRD は存在しません。

詳細

• Kubernetes への移行の仕組み

• Kubernetes への移行の前提条件

• レプリカセットを Kubernetes に移行する