MongoDB 6.0.13+ または 7.0.8+ のライブ移行(プル) Atlas へのクラスター化
ソースクラスターと宛先クラスターの両方が MongoDB 6.0.13 + または7.0.8 + を実行している場合、 Atlas は、このセクションに記載されている手順を使用して、ソースクラスターを Atlas クラスターにプルすることができます。
このプロセスでは、 mongosyncを基礎のデータ移行ツールとして使用し、ダウンタイムを少なくしてライブ移行を迅速化します。
Atlas は、アプリケーションが宛先の Atlas クラスターに切り替わるまで、ソースクラスターから宛先クラスターにデータを同期します。
次の手順でカットオーバーのステップに到達したら、
ソースクラスターへの書き込みを停止します。
アプリケーション インスタンスを停止してから、Atlas クラスターを向くように設定し、再起動します。
制限事項
このライブ移行にはCluster-to-Cluster Sync 制限が適用されます。
ライブ移行(プル)では、以下はサポートされていません。
ソースまたは宛先クラスターのバージョンとしてMongoDB 8.0 または Rapid Release を使用します。
ライブ移行では、ソースクラスターから宛先クラスターへの Atlas Search インデックスの移行はサポートされていません。
サポートされている移行パス
このセクションで説明する Atlas ライブ移行は、次の移行パスをサポートしています。
Source Cluster MongoDB Version | Destination Atlas Cluster MongoDB Version |
---|---|
6.0.13 | 6.0.13 |
7.0.8 | 7.0.8 |
必要なアクセス権
データをライブ移行するには、Atlas への Project Owner
アクセス権が必要です。
Organization Owner
アクセス権を持つユーザーは、自分自身を Project Owner
としてプロジェクトに追加する必要があります。
サポートされているソースクラスターと宛先クラスターの構成ペア
このタイプのライブ移行では、Atlas は次のソースクラスターと宛先クラスターの構成ペアをサポートしています。
ソースクラスター構成 | 宛先クラスターの構成 | ライブ移行サポート | ノート |
---|---|---|---|
スタンドアロン | 任意のタイプのクラスター | この移行手順を使用してスタンドアロンのソースクラスターを移行する前に、 スタンドアロンをレプリカセットに変換します。 | |
レプリカセット | レプリカセット | ||
レプリカセット | シャーディングされたクラスター | このタイプの移行を実行する場合は、シャーディング パラメーターを指定できます。 詳細については、このセクションのライブ移行手順とこのシャーディングの例を参照してください。 | |
シャーディングされたクラスター | シャーディングされたクラスター | ソースクラスターと宛先クラスターのシャードの数は異なる場合があります。 ソースのシャーディングされたクラスターは、CSRS(Config Server レプリカセット)を使用する必要があります。 詳細については、「レプリカ セット コンフィギュレーションサーバー 」を参照してください。 | |
シャーディングされたクラスター | レプリカセット |
前提条件
クラスターが認証を使用して実行されている場合は、次の前提条件を満たす必要があります。
レプリカセットの場合は、移行プロセスを実行するユーザーに、管理データベースに対して
backup
} ロールとreadAnyDatabase
ロールを付与します。シャーディングされたクラスターの場合は、移行プロセスを実行するユーザーに、管理データベースに対して
backup
、readAnyDatabase
、clusterMonitor
ロールを付与します。 指定されたユーザーがすべてのシャードとコンフィギュレーションサーバーのレプリカセットに存在することを確認します。 ユーザーには、次のアクションを許可する権限が必要です。シャーディングされたクラスター バランサーを停止または起動します。
ホスト上のすべてのデータベースとコレクションを読み取る。
ホスト上の oplog を読みとります。
このユーザーがSCRAM-SHA- 1と SCRAM-SHA- 256の両方を使用して認証されていることを確認します。 詳細については、 「ソースクラスターのセキュリティ」 を参照してください。
重要
ソースクラスタの準備状況
スムーズなデータ移行を実現するには、ソースクラスターが本番クラスターの推奨事項をすべて満たしている必要があります。ライブ移行プロセスを開始する前に、操作チェックリストとプロダクション ノートを確認してください。
ネットワーク アクセス
以下のコンポーネントのネットワーク権限を設定します。
ソースクラスターのファイアウォールはライブ移行サーバからのトラフィックを許可します
ソースクラスターのファイアウォールはすべて、MongoDB ライブ移行サーバーからソースクラスターへのアクセスを許可する必要があります。
Atlas ライブ移行プロセスでは、MongoDB が制御するライブ移行サーバーを介してデータが転送されます。Atlas は、ライブ移行プロセス中に MongoDB ライブ移行サーバーの IP 範囲を提供します。これらの IP 範囲にソースクラスターへのアクセスを許可します。これにより、MongoDB ライブ移行サーバーがソースクラスターに接続できるようになります。
注意
組織の厳格なネットワーク要件により、MongoDB ライブ移行サーバーへの必要なネットワーク アクセスを有効にできない場合は、「コミュニティ配置の Atlas へのライブ移行」を参照してください。
Atlas クラスターはアプリケーションサーバーからのトラフィックを許可します
Atlas では、プロジェクトのIP アクセス リストに追加されたホストからクラスターへの接続を許可します。アプリケーション ホストの IP アドレスまたは CIDR ブロックをプロジェクトの IP アクセス リストに追加します。これは、移行手順を開始する前に行ってください。
Atlas は、MongoDB 移行サーバーの IP アドレスをプロジェクトの IP アクセス リストに一時的に追加します。移行手順中は、このエントリを編集または削除することはできません。Atlas は手順が完了すると、このエントリを削除します。
Atlas IP アクセス リストにエントリを追加する方法については、「IP アクセス リスト エントリの設定」を参照してください。
移行前の検証
次のライブ移行手順を開始する前に、Atlas はソースクラスターと宛先クラスターの検証チェックを実行し、次のことを確認します。
ソースクラスターと宛先クラスターの MongoDB バージョンは、少なくともFCV 6.0.13 + と一致しているか、少なくともFCV 7.0.8 + と 一致しています。
ソースクラスターのデータベースユーザーには、「ソースクラスターのセキュリティ 」で説明されている適切な権限があります。
ソースクラスタのセキュリティ
さまざまな組み込みロールによって、十分な権限が付与されます。以下に例を挙げます。
ソース レプリカセット クラスターの場合、MongoDB ユーザーはreadAnyDatabase
} ロールとbackup
ロールを持っている必要があります。
ソース シャーディングされたクラスターの場合、MongoDB ユーザーにはreadAnyDatabase
、 backup
、およびclusterMonitor
ロールが必要です。
ライブ移行プロセスを実行するデータベースユーザーがこれらのロールを持っていることを確認するには、 admin
データベースでdb.getUser()コマンドを実行します。 たとえば、レプリカセットの場合は、次を実行します。
use admin db.getUser("admin") { "_id" : "admin.admin", "user" : "admin", "db" : "admin", "roles" : [ { "role" : "backup", "db" : "admin" }, { "role" : "readAnyDatabase", "db" : "admin" } ] } ...
ライブ移行手順のウォークスルー画面でプロンプトが表示されたら、Atlas にユーザー名とパスワードを指定します。
Atlas は、認証を強制するソースクラスターへの接続には SCRAM のみサポートします。
MongoDB のライブ移行サーバーの保護方法
Atlas へのプル タイプのライブ移行は、ライブ移行を実行するサーバーをAtlas が管理し、ソースから宛先クラスターにデータを送信します。
MongoDB では、Atlas に送信されるデータの整合性と機密性を保護するために、次の措置を講じています。
MongoDB では、Atlas が管理するライブ移行サーバーと宛先クラスター間で転送されるデータは暗号化されます。ソースクラスターと Atlas が管理する移行サーバー間で転送されるデータの暗号化が必要な場合は、ソースクラスターで TLS を設定します。
MongoDB では、Atlas の他の部分へのアクセスが保護されるのと同様に、Atlas が管理する移行サーバー インスタンスへのアクセスが保護されます。
クリティカルなサービスの調査や復旧のために介入が必要となる稀なケースでは、MongoDB は最小権限の原則に準じ、クリティカルな問題を修復するために必要最小限の限られた時間だけ、少数の権限ユーザーのグループにお客様の Atlas クラスターへのアクセスを許可します。MongoDB では、これらのユーザーは Atlas クラスターにログインし、要塞ホスト経由で SSH 接続を確立するために MFA が必要です。この種の権限ユーザーにアクセス権を付与するには、MongoDB 上級管理職の承認が必要です。MongoDB では、他のいかなる MongoDB 担当者による、お客様の MongoDB Atlas クラスターへのアクセスは許可されていません。
MongoDB では、特権アクティビティでのみ特権ユーザー アカウントの使用が許可されます。 非特権アクティビティを実行するには、特権ユーザーは別のアカウントを使用する必要があります。 特権ユーザー アカウントでは、共有認証情報を使用できません。 特権ユーザー アカウントは、 Atlas セキュリティのホワイトペーパーのセクション4.3.3に記載されているパスワードの要件に従う必要があります。
Atlas では、権限ユーザーを含むすべての MongoDB 担当者による、お使いのクラスターへのアクセスを制限することができます。お客様がそのようなアクセス制限をすることを選択し、MongoDB がお問い合わせの問題を解決するためにアクセスが必要であると判断した場合、MongoDB はまずお客様へアクセス許可をリクエストする必要があります。そしてお客様は、最大 24 時間の権限ユーザーアクセスを一時的に復元するかどうかを決定できます。一時的な 24 時間のアクセス許可はいつでも取り消すことができます。この制限を有効にすると、お問い合わせの問題への対応とその解決にかかる時間が長くなり、その結果、Atlas クラスターの可用性に悪影響を及ぼす可能性があります。
MongoDB では、権限ユーザーのアクセス承認を四半期ごとに確認します。さらに MongoDB では、不要となった権限ユーザーのアクセス権を取り消します。権限ユーザーのロールが変更となったり、会社を退職した場合は、 24 時間以内にアクセス権を取り消します。また、MongoDB の担当者によるお客様の Atlas クラスターへのアクセスを記録し、タイムスタンプ、アクター、アクション、出力を含んだ監査ログを少なくとも 6 年間保持します。MongoDBは、自動レビューと手動レビューの組み合わせを使用して、これらの監査ログを精査します。
Atlas セキュリティの詳細については、 Atlas セキュリティのホワイトペーパーを参照してください。特に、「MongoDB Atlas クラスターへの MongoDB 担当者のアクセス」セクションを確認してください。
Considerations
ネットワークの暗号化
プル型のライブ移行中、ソースクラスターが自身のデータに対して TLS 暗号化を使用しない場合、ソースクラスターから Atlas へのトラフィックは暗号化されません。これが受け入れられるかどうかを、プル型のライブ移行手順を開始する前に判断してください。
データベースユーザーとロール
Atlas は、いかなるユーザー データーまたはロール データも宛先クラスターに移行しません。
ソースクラスターが認証を使用しない場合、Atlas でユーザーを作成する必要があります。Atlas では認証無しの実行がサポートされないためです。
ソースクラスターが認証を強制する場合、アプリケーションが宛先の Atlas クラスターで使用する認証情報を再び作成する必要があります。Atlas ではユーザー認証に SCRAM が使用されます。詳細については、「データベースユーザーの設定」を参照してください。
ソースクラスターと宛先クラスターのバランサー
移行中の書込みパフォーマンスへの影響を回避するため、Atlas は手順の開始時にソースクラスターと宛先クラスターのシャーディングされたクラスターのバランサーを停止し、手順の最後にバランサーを起動します。
ライブ移行をキャンセルすると、Atlas はソースクラスターと宛先クラスターのバランサーを再起動します。
Atlas がライブ移行の成功の最後にソースクラスターまたは宛先クラスターのロード バランサーを再起動できない場合、警告バナーはソースまたは宛先クラスターのバランサーを手動で再起動する必要があることを示します。
宛先クラスターの構成
宛先クラスターを構成する際には、次の点を考慮してください。
ライブ移行プロセスでは、MongoDB が管理するライブ移行サーバーを介してデータがストリーミング転送されます。各サーバーは、ソースクラスターに最も近いリージョンでホストされているインフラストラクチャ上で動作します。次のリージョンがご利用いただけます。
- ヨーロッパ
フランクフルト
アイルランド
London
- Americas
アメリカ東部
アメリカ西部
- APAC
ムンバイ
香港
シドニー
Tokyo
Atlas の宛先クラスターには、アプリケーションサーバーまたはソースクラスターでホストされている配置と比較して、ネットワークレイテンシーが最も低いクラウドリージョンをお使いください。理想的なのは、アプリケーションのサーバーは、宛先の Atlas クラスターのプライマリ リージョンと同じリージョンのクラウドで実行されていることです。詳細については、「クラウドプロバイダー」を参照してください。
Atlas の宛先クラスターは、RAM、CPU、およびストレージの点でソースとなる配置と同じかそれを上回る必要があります。移行プロセスと予想されるワークロードの両方に対応できるように、適切なサイズの宛先クラスターをプロビジョニングするか、宛先クラスターをより処理能力、帯域幅、またはディスク IO のある階層にスケールアップします。
移行のパフォーマンスを最大化するには、宛先クラスターに少なくとも 1 つの M40 クラスターを使用してください。大規模なデータセットを移行する場合は、6000 IOPS 以上のディスクを搭載した M80 クラスターを使用してください。
移行プロセスの実行中に宛先 Atlas クラスターのサイズを一時的に増やすことも選択できます。
アプリケーションのワークロードを Atlas のクラスターに移行したら、コストを最小限に抑えるために宛先クラスターのさらなるパフォーマンス調整とサイズ設定に関するサポートを受けるため、サポートにお問い合わせください 。
予期しないサイズ変更を避けるため、宛先クラスターでオートスケーリングを無効にします。詳細については、「クラスターの管理」を参照してください。
oplog コレクションの無制限の増加を防ぎ、ライブ移行のラグ ウィンドウが oplog レプリケーション ラグ ウィンドウの範囲内に収まるようにするには、ライブ移行プロセスの実行中に十分な固定値の oplog サイズ を設定します。
詳しくは以下を参照してください。
これらの推奨事項に従っていてもパフォーマンスの問題が見られる場合は、サポートにお問い合わせください 。
M0
(無料階層)またはM2/M5
共有階層クラスターをライブ移行の宛先クラスターとして選択することはできません。Atlas ライブ移行の実行中は、
featureCompatibilityVersion
フラグを変更しないでください。
宛先クラスターでワークロードを避ける
宛先クラスターでは、ライブ移行プロセスと重複しない名前空間で実行されうるワークロードを含め、いかなるワークロードも実行しないでください。このアクションにより、ライブ移行プロセス中に発生する可能性のあるロックの競合やパフォーマンスの低下を回避できます。
同じ宛先クラスターに対して、複数の移行を同時に実行しないでください。
ライブ移行プロセスの同期中は、アプリケーションの宛先クラスターへのカットオーバーのプロセスを開始しないでください。
クラウドバックアップを避ける
Atlas は、ライブ移行中に宛先クラスターのオンデマンド クラウドバックアップのスナップショットの取得を停止します。このページに記載されているライブ移行手順のカットオーバーのステップが完了すると、Atlas はバックアップ ポリシーに基づいてクラウドバックアップのスナップショットの取得を再開します。
選挙を避ける
ライブ移行プロセスは、ソースクラスターまたは宛先クラスターで一時的にネットワークの中断が発生したり、選挙が行われても、移行が継続されるように最善を尽くします。ただし、これらのイベントによりライブ移行プロセスが失敗する可能性があります。ライブ移行プロセスが自動的に回復しない場合は、最初からやり直してください。
お使いのクラスターを移行する
注意
ステージングと本番環境の移行
この手順を 2 回実行することを検討してください。まず、 Perform the Cutover ステップで停止する部分的な移行を実行します。これにより、最新の Atlas ベースのステージング クラスターが作成され、MongoDB 向けの Atlas クラスターをサポートする最新のドライバー バージョンを使用して、アプリケーションの動作とパフォーマンスをテストできます。
アプリケーションをテストした後、別の Atlas クラスターを使用して完全な移行手順を実行し、Atlas ベースの本番環境を作成します。
移行前チェックリスト
ライブ移行手順を開始する前に、
宛先クラスターがまだない場合は、新しい Atlas 配置を作成し、必要に応じて構成します。Atlas クラスターの作成に関する詳細なドキュメントについては、「クラスターの作成」を参照してください。
Atlas クラスターを配置した後に、アプリケーションを実行するすべてのクライアント ハードウェアからこのクラスターに接続できることを確認します。接続文字列のテストをすることによって、データ移行プロセスが最小限のダウンタイムで完了することを確認できます。
まだインストールしていない場合は、代表のクライアント マシンに
mongosh
ダウンロードしてインストールします。Atlas UI から接続文字列を使用して宛先クラスターに接続します。詳細については、「
mongosh
経由で接続」を参照してください。
宛先クラスターへの接続を確認したら、ライブ移行手順を開始します。
手順
移行プロセスを開始します。
宛先の Atlas クラスターを選択します。
宛先の Atlas クラスターに移動し、省略記号 ... ボタンをクリックします。クラスター リストでは、クラスター名の下に省略記号 ... ボタンが表示されます。クラスターの詳細を表示すると、画面の右側の Connect ボタンと Configuration ボタンの横に省略記号 ... が表示されます。
[Migrate Data to this Cluster] をクリックします。
Atlas には、ライブ移行の進め方を示すウォークスルー画面が表示されます。このプロセスでは、ソースクラスターのデータが新しい宛先クラスターに同期されます。ウォークスルーを完了したら、お使いのアプリケーションが新しいクラスターに向くよう設定できます。
移行を容易に行うために、ソースクラスターの以下の詳細を収集します。
レプリカセットの場合、ソースクラスタープライマリのホスト名とポート。 たとえば、
mongoPrimary.example.net:27017
。 Atlas は、デフォルトではソースクラスターのプライマリ メンバーにのみ接続します。 必要に応じて回復力を高め、フェイルオーバーを容易にするために、Atlas は他のソースクラスター ノードが公開されている DNS レコードを持つ場合、その IP アドレスを取得します。シャーディングされたクラスターの場合、各シャード上の各
mongos
のホスト名とポート。 たとえば、mongos.example.net:27017
。ソースクラスターへの接続に使用されるデータベース認証ユーザー名とパスワード。 レプリカセットの場合、データベースユーザーには
readAnyDatabase
} ロールとbackup
ロールが必要です。 シャーディングされたクラスターの場合、データベースユーザーにはreadAnyDatabase
、backup
、clusterMonitor
ロールが必要です。ソースクラスターが
TLS/SSL
を使用し、公開認証局(CA)を使用していない場合は、ソースクラスターのCAファイルが必要になります。
ウォークスルー画面に記載されている情報を準備し、I'm Ready To Migrate をクリックします。
Atlas は、ソースクラスターに接続するために必要な情報を収集するためにウォークスルー画面を表示します。
Atlas では、ライブ移行を担う MongoDB ライブ移行サーバーの IP アドレスがウォークスルー画面の上部に表示されます。表示された IP アドレスへのアクセスを許可するように、ソースクラスターのファイアウォールを設定します。
レプリカセットの場合は、表示されたテキストボックスに、ソースクラスターのプライマリノードのホスト名とポートを入力します。 シャーディングされたクラスターの場合は、各
mongos
のホスト名とポートを入力します。レプリカセットをシャーディングされたクラスターに移行する場合、次の手順に従います。
コレクションをシャーディングする場合は、 Include sharding parametersのチェックマークをクリックし、シャーディングの例を使用してシャーディング構成 JSON を テキストボックスに貼り付けます。 後で参照したい場合に備えて、この構成を外部の ファイルに保存します。
シャーディング構成 JSON は、シャーディングするコレクションとシャーディングに使用するキーを指定する
shardingEntries
配列を定義します。 MongoDB は、この配列に含めたコレクションのみをシャーディングします。 詳細については、「シャーディング 」を参照してください。シャーディング構成の指定を省略する場合は、クラスターを Atlas に移行した後に、宛先クラスターでコレクションをシャードできます。
シャーディング構成に加えて、指定されたシャーディングキーの互換性のあるインデックスがサービス内の宛先クラスターに存在する必要があります。
Create supporting indexesのチェックマークをクリックすると、MongoDB が Atlas の宛先クラスターにサポートするシャードキー インデックスを自動的に作成するようになります。
ソースクラスターが認証を強制する場合は、表示されたテキストボックスにユーザー名とパスワードを入力します。
Atlas ライブ移行に必要なユーザー権限に関するガイダンスについては、「ソースクラスターのセキュリティ」を参照してください。
ソースクラスターが
TLS/SSL
を使用しており、公開認証局(CA)を使用していない場合は、スイッチIs encryption in transit enabled?を切り替えて、ソースクラスターの CA ファイルの内容を表示されたテキストボックスにコピーします。宛先クラスターに保持したいデータがある場合は、 Clear any existing data on your destination clusterオプションはオフのままにします。 ライブ移行サービスは検証中にドキュメントのサンプルをチェックし、重複する名前空間が見つかった場合は警告を発します。 既存のデータを削除する場合は、このオプションをオンにして、宛先クラスターの名前を入力します。
[ Validateをクリックして、Atlas がソースクラスターに接続できることを確認します。
検証に失敗した場合は、以下を確認します。
ソースクラスターの IP アクセス リストに Atlas を追加しました。
ユーザー認証情報(指定した場合)がソースクラスターに存在しており、必要な権限を持っている。
Is encryption in transit enabled? トグルは、ソースクラスターで必要な場合にのみ有効になっている。
CA ファイル(指定した場合)は有効かつ正しい。
Start Migration をクリックして、移行プロセスを開始します。
移行プロセスが開始されると、Atlas UI に、宛先 Atlas クラスターの Migrating Data ウォークスルー画面が表示されます。 ウォークスルー画面は、宛先クラスターの移行プロセスが進行すると更新されます。移行プロセスには、次のものが含まれます。
ソースクラスター データへの新しい書込みを宛先クラスター データに適用します。
ソースクラスターから宛先クラスターへのデータのコピー。
宛先クラスターで移行を終了します。
移行プロセスの最終フェーズでは、ソースクラスターと宛先クラスター間の現在のラグを表すラグ タイム値が表示されます。
有効期限が近づくと、メール通知が届きます。
ソースの遅延が 0 に近く、移行プロセスが追いつくと、Atlas はCutover to your destination clusterボタンをアクティブ化し、ソースクラスターと宛先クラスターが同期していることを示します。 次の手順に進みます。
カットオーバーを実行します。
カットオーバーは、アプリケーションの読み取りと書込みをソースクラスターから宛先クラスターに指示する 3 ステップのプロセスです。
Atlas は、ソースクラスターと宛先クラスターがほぼ同期していることを検出すると、延長可能な120時間( 5日)のタイマーを開始してライブ移行手順のカットオーバーのステージを開始します。 120時間が経過すると、Atlas はソースクラスターとの同期を停止します。
移行プロセスのこのステージでは、カットオーバーに進むか、同期期間を延長してから、カットオーバーに進むことができます。
I'm ready to cutoverをクリックすると、Atlas はカットオーバー プロセスを開始します。
Extend Syncをクリックし、拡張同期が正常に完了すると、Atlas はソースクラスターと宛先クラスターが同期していることを確認します。 カットオーバー プロセスに進みます。 同期時間が経過した場合は、移行を再試行できます。
移行の有効期限が迫っている場合、Atlas は次の例のようなメールを送信します。
A migration to your Atlas cluster will expire in <number> hours! Navigate to your destination cluster to start the cutover process. If you don't take any action within <number> hours, the migration will be cancelled and you will need to start again. You can also extend the migration process if you need more time.
[ I'm ready to cutoverをクリックします。 アプリケーションのダウンタイムを最小限に抑えるために、3 ステップのカットオーバー プロセスを迅速に処理します。
[ Proceed to cutoverをクリックします。 3 ステップのカットオーバー プロセスが開始されます。
ソースクラスターへの書き込みを停止します。 [ I confirm that I've stopped writes to my source clusterをクリックします。 続行するにはFinalize migrationをクリックします。
Atlas が移行を完了するまで、数分待ちます。 Atlas は、プロセスを完了するために次のアクションを実行します。
MongoDB ライブ移行サーバーのサブネットを宛先クラスターの IP アクセスリストから削除する。
ライブ移行で宛先クラスターへのデータのインポートに使用したデータベースユーザーを削除します。
カットオーバー プロセスが少なくとも12時間進行している場合、Atlas は移行プロセスを確認するか、サポートに連絡することを提案するメールを送信します。
移行が成功すると、 You have successfully migrated to Atlasページが表示されます。 Atlas には、同期された変更のステータス、アプリケーションのダウンタイム、移行プロセスの期間、コピーされた初期データの量、コピーされたコレクションの数が表示されます。
ドキュメント数を比較し、ハッシュを実行して、データが宛先クラスターに転送されていることを確認します。 詳細については、「データ転送の Cluster-to-Cluster Sync 検証 」を参照してください。
[ Connect to your new clusterをクリックします。 Atlas は接続方法を選択できるConnect to Atlasページにリダイレクトします。
クラスターに接続したら、宛先クラスターへの書込みを再開します。
移行サポート
ライブ移行プロセスのいずれかの段階で移行が失敗した場合、Atlas は移行結果を確認するためのリンクを記載したメールで通知を行います。
このドキュメントで説明されている範囲外で移行のサポートに関して質問がある場合、または移行中にエラーが発生した場合は、Atlas UI からサポートをリクエストしてください。
サポートチケットを提出するには:
Atlas で、Project Support ページに移動します。
まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Projects メニューの横にある Options メニューをクリックし、 Project Support をクリックします。
プロジェクト サポートページが表示されます。
サポートをリクエストします。
[Request Support] をクリックします。
Issue Category の場合は
Help with live migration
を選択します。Priority には、お問い合わせの優先度を選択します。ご質問の場合は、
Medium Priority
を選択してください。移行に失敗した場合は、High Priority
を選択してください。Request Summary には、
Live Migration
を要約に含めてください。More details には、ご質問または移行エラーに関するその他の詳細も含めてください。
Request Support ボタンをクリックして、フォームを送信します。