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

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

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

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

埋め込みコンフィギュレーションサーバーはサポート対象外

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

インバウンド接続は自動検証されない

ドライバーは、 Kubernetesから仮想マシンへの接続のみを検証します。仮想マシンと Kubernetes のインバウンド接続を自動的にチェックすることはありません。依存する前に、その接続の方向を自分で確認してください。

自動ロールバックなし

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

進行中の移行を手動でロールバックするには:

シード処理または事前コピーなし

移行では、 MongoDBレプリケーションのみがデータを移動されます。 Kubernetes Operator は、他のメカニズムを通じて新しいKubernetesメンバーにデータをシードしたり事前コピーしたりしません。

自動プルーニングなし

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

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

このワークフローは、Ops Manager またはCloud Managerが管理するMongoDBデプロイのみを移行します。 Ops Manager またはCloud Manager自体は移行されません。

移行中は構成が固定されます

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

移行自体の一環として、一部のフィールドが変更されることが予想されます。

• メンバー数と memberConfig の votes フィールドと priority フィールドは、メンバーを拡張、昇格、プルーニングすると変化します。

その他の設定は移行全体でソース配置と一致する必要があり、変更してはなりません。

• MongoDB バージョン

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

• ポート

• 認証モード

• 内部クラスター認証

新しいノードに継承されない設定

Kubernetes Operator は新しいKubernetesメンバーでこれらを複製しないため、移行する前にこれらの設定を計画します。

• secondaryDelaySecs 遅延メンバー。

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

• buildIndexes ノードで false に設定されている。

仮想マシンで 分析ノード または 遅延ノード を実行する場合は、レプリカセットに参加した後、 Kubernetesノードの同等の設定を自分で再構成します。

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

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

詳細

• Kubernetesへの移行の仕組み

• Kubernetesへの移行の前提条件

• レプリカセットのKubernetesへの移行