Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

専用コンフィギュレーションサーバーへの移行

注意

自己管理型型配置を実行中いる場合は、 transitionToDedicatedConfigServerデータベースコマンドを使用してコンフィギュレーションサーバーのタイプを移行する方法については、「 埋め込みから専用コンフィギュレーションサーバーへの移行 」を参照してください。

シャーディングされたクラスターがコンフィギュレーションシャード と呼ばれる 埋め込みコンフィギュレーションサーバーを使用する場合、Atlas またはユーザーはクラスターを専用のコンフィギュレーションサーバーを使用するように移行できます。埋め込みコンフィギュレーションサーバーの場合、コンフィギュレーションシャードにはクラスターメタデータとユーザー データの両方が保存されます。専用のコンフィギュレーションサーバーがある場合、コンフィギュレーションノードはメタデータのみを保存します。 Atlas は、特定の条件下でクラスターを埋め込みコンフィギュレーションサーバーから専用コンフィギュレーションサーバーに自動的に移行します。移行を手動で開始することもできます。

埋め込みから専用のコンフィギュレーションサーバーへの移行は、すべてのユーザー データをコンフィギュレーションシャードから移動する必要があるオンライン操作です。コンフィギュレーションシャード上に大量のデータがあるクラスターの場合、このプロセスには 時間から 日間かかる場合があります。移行を開始する前に、以下を確認してください。

  • 宛先シャードにはヘッドルームがあります。移行中に、 コンフィギュレーションシャード からデータを受け取るシャードでは、CPU、メモリ、I/O が使用されます。移行の実行中は、Atlas では一度に実行できる長時間実行プランが 1 つしか実行できないため、クラスター層を増やすたり、ストレージを変更したりすることはできません。受信シャードがキャパシティー に近い場合は、移行を開始する前に増やすアップします。

  • クラスターはサポートされている機能のみを使用します。 MongoDB Search、 MongoDB ベクトル検索、シャーディングされていない時系列コレクション、およびコンフィギュレーションシャード上のシャーディングされていないクエリ可能な暗号化コレクションは、自動移行をブロックします。ブロッキング機能の完全なリストについては、「 制限と例外 」を参照してください。

  • drop system.profile 以前のMongoDBバージョンに移行する前に、 コンフィギュレーションシャードの system.profileコレクションはトランザクションをブロックする可能性があります。プロファイリングが有効になっている場合は、移行を開始する前に を削除するか、system.profile MongoDB8.2.7 以降にアップグレードしてください。

Atlas 管理型コンフィギュレーションサーバー が有効になっている場合、Atlas は埋め込みコンフィギュレーションサーバーと専用コンフィギュレーションサーバーの間の移行を自動的に管理します。次の図は、Atlas が各トランザクションをトリガーするタイミングを示しています。

「シャード数が 3 を超え、ブロッキング機能がない場合、Atlas は埋め込みから専用のコンフィギュレーションサーバーに移行します。」
クリックして拡大します

Atlas は、すべての クラスターに対して Atlas マネージド8.0 コンフィギュレーションサーバーをデフォルトで有効にします。有効にすると、Atlas はシャード数に基づいてクラスターをコンフィギュレーションサーバーのタイプ間で自動的に移行します。

  • シャード数が 3 を超えると、Atlas は埋め込みコンフィギュレーションサーバーから専用のコンフィギュレーションサーバーに移行します。

  • シャード数が 3 以下に減少すると、Atlas は専用のコンフィギュレーションサーバーから 埋め込みコンフィギュレーションサーバーに移行します。

専用コンフィギュレーションサーバーへの移行を手動でトリガーするには、次の手順を実行します。

1
  1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーで、 Database見出しの下のClustersをクリックします。

[ Clusters (クラスター) ] ページが表示されます。

2

クラスターの名前の横にあるをクリックし、Edit Configuration を選択します。 []Additional Settings パネルを展開して、クラスターの追加設定を構成します。

3

Atlas-Managed Configuration Servers トグルをオフにします。

Additional Settings > More Configuration Options の下で、Atlas-Managed Configuration Servers トグルをオフにします。

4

[Review Changes をクリックし、Apply Changes をクリックします。 Atlas はすぐに専用のコンフィギュレーションサーバーへの変換を開始します。

MongoDB は構成メタメタデータを移動できないため、Atlas は専用のコンフィギュレーションサーバーに移行する前に、まずコンフィギュレーションシャード config-0 からすべてのユーザー データをドレイニングする必要があります。移行の一環として、config-0 はユーザー データを提供しなくなったため、Atlas はターゲット シャード数を維持するために置換シャードを追加します。

次の表は、Atlas マネージド コンフィギュレーションサーバー が有効になっている シャード クラスターに 4 つ目のシャードを追加して移行を開始するときに Atlas が実行する手順を示しています。3

ステップ
アクション
有効なシャード数

始める

埋め込みコンフィギュレーションサーバーを備えた 3 シャード クラスター(config-0shard-0shard-1

3

1

Atlas は shard-2 を追加し、クラスターをターゲットのシャード数に戻します。クラスターには現在、ユーザー向けシャードが 4 個あります。これは、shard-0shard-1shard-2config-0 であり、ユーザー データは引き続き保存されます。

4

2

Atlas はtransitionToDedicatedConfigServer を実行し、内部的にはremoveShard 上でconfig-0 を実行します。シャーディングされたコレクションは、 チャンク移行 を使用してバランサーを介して他のシャードにドレインします。シャーディングされていないコレクションはmoveCollection 経由で移動されます。

4(ドレインが進行中)

3

AtlasorphanCleanupDelaySecs config-0は8.2.7 がクリアされることを確認する前に、 が経過するのを待機します。 より前のバージョンのMongoDBを実行中クラスターでは、Atlas は代わりにすべての範囲の削除が完了するまで待機します。これには大幅な時間がかかる可能性があります。

4(クリーンアップが進行中)

4

config-0 は専用のコンフィギュレーションサーバーに変換されます。 Atlas はターゲット シャード数を復元するために shard-3 を追加します。 4 ユーザー向けシャードは、shard-0shard-1shard-2shard-3 になりました。

4

5

Atlas は、config-0 を専用コンフィギュレーションサーバーのデフォルトである M30 にスケールダウンします。

4

移行期間は、コンフィギュレーションシャード上のユーザー データの量によって異なります。構成シャードをドレインするには、シャーディングされたコレクションでは チャンクの移行 と、シャーディングされていないコレクションでは moveCollection 操作が含まれ、どちらもネットワーク全体にデータを移動します。期間はデータセットのサイズによって異なります。

  • 小規模なデータセット(数GB): 分から少数の時間

  • 大規模なデータセット(数百GBから複数 TB): 時間から 日

注意

クラスターのコンフィギュレーションシャードに大量のデータがある場合は、低トラフィック期間中に移行を実行します。

埋め込みから専用コンフィギュレーションサーバーへの移行は、クラスターに次の運用上の影響を与えます。

  • ダウンタイムはありません。トランザクションはオンラインです。アプリケーションは全体にわたって読み取りと書込みを続行します。

  • 受信シャードでのリソース使用量の増加。コンフィギュレーションシャード からデータを消費するシャードでは、移行中に CPU、メモリ、 I/O が増加する可能性があります。影響を受けるシャードのアプリケーションレイテンシは、ある程度増加する可能性があります。

  • Atlas プランロック。移行の実行中、Atlas はクラスター上で実行される他のプラン(クラスター層のスケーリング 、ストレージの変更 、他のシャードの追加または削除など)を実行することはできません。一度に実行できる長時間実行プランは 1 つだけです。

警告

トランザクションが開始された後は、キャンセル しない でください。

移行の進行中は、Atlas UIを使用したり、シャード数を減らしたりしてキャンセルしないでください。キャンセルが必要な場合は、 MongoDBサポート にお問い合わせください。

次の図は、移行の進行状況を監視するために利用できる方法を示しています。

「埋め込みコンフィギュレーションサーバーから専用コンフィギュレーションサーバーへの移行の進行状況をモニタリング」
クリックして拡大します

移行の進行中、Atlas はクラスター ページに次のバナーを表示します。

We are deploying your changes (current action: transitioning config server type).

Atlas は、次の機能を使用するクラスターのコンフィギュレーションサーバーを自動的に移行しません。クラスターでこれらの機能のいずれかを使用しており、コンフィギュレーションサーバーのタイプを変更する必要がある場合は、 MongoDBサポートにお問い合わせください。

機能
自動トランザクション
解決法

MongoDB Search / ベクトル検索

Atlas は、コンフィギュレーションサーバーのタイプを、検索が有効になっているときの状態に固定します。この制限は、シャーディングされたコレクションとシャーディングされていないコレクションの両方に適用されます。

ブロック(ピン留め)

シャーディングされていない時系列

MongoDB Server はバージョン 8.0.10 で基礎となる制限を解除しましたが、Atlas ではこの変更はまだ採用されていません。

ブロック

シャーディングされていないクエリ可能な暗号化

moveCollection では、クエリ可能な暗号化コレクションはサポートされていません。

ブロック

グローバルクラスター

埋め込みコンフィギュレーションサーバーをサポートしていません。

該当なし

常に専用

レプリカセットからシャーディングされたクラスターへの変換

レプリカセットをAtlas のシャーディングされたクラスターに変換すると、Atlas-Managed Configuration Servers 設定に関係なく、結果として得られるクラスターは常に専用のコンフィギュレーションサーバーを使用します。

該当なし

上記のいずれも

許可された

Proceeds online

戻る

クラスターシャーディング

項目一覧