01
バックグラウンド
現在、文書データベースはその柔軟なスキーマとリレーショナルデータベースに近いアクセス特性から広く利用されており、特にゲーム業界やインターネット金融業界などの顧客がMongoDBを利用して数多くのアプリケーションを構築しています。プレイヤーの属性情報を処理するため; 別の例としては、タイムラインに関連する市場データを保存するために株式 APP が使用されることです。時間の経過とビジネスの発展に伴い、MongoDB ライブラリはますます大きくなり、大規模なライブラリの管理は直面しなければならない問題になっています。
一般に、大規模なデータベース ガバナンスにはいくつかのオプションがあります。1つ目は、ホットデータとコールドデータを分離し、使用頻度に応じてデータをホット、ウォーム、コールド、フリーズレベルに分け、一定期間を超えたコールドデータは別のコールドストレージまたは低レベルのストレージにダンプします。コスト ストレージ データベース; ホット ストレージは最近のアクセス 頻繁なデータのみを保持します; 2 つ目は、垂直分割を行うことです。たとえば、大規模なシステムには複数のコレクションがあり、モジュールに従って垂直に分割され、異なるモジュールに対応するコレクションは次のように分割されます。データ量とアクセス量の垂直方向の分離を実現するために異なるライブラリを使用すること、3 番目は、ユーザー ID のハッシュ値の選択などの水平方向の分割を実行し、大規模なコレクションを複数のライブラリに水平方向に分割して、全体的なストレージとコンピューティング能力の拡張を実現することです。4 番目に、履歴データの使命が完了し、ライフサイクルが完了するため、直接削除できる企業もあります。これら 4 つのソリューションにはそれぞれ長所と短所があり、実際のビジネス シナリオに応じて選択する必要があります。多くのシナリオで、顧客は水平シャーディングを選択します。主な理由は次のとおりです。
▪多くの 企業は履歴データを頻繁にクエリする必要があり、水平シャーディングでは履歴データを削除したり分離したりする必要がありません。
▪ 長期的には、水平シャーディングの方が拡張性が高く、より大きなビジネス規模をサポートできます。
Amazon DocumentDB Elastic Cluster は、Amazon が提供する水平シャーディングをサポートするクラウド データベース サービスです。この記事では、お客様が MongoDB レプリカ セット アーキテクチャから DocumentDB Elastic Cluster に移行する過程で大量のデータを移行する方法の問題に主に焦点を当て、調査を実施し、ベスト プラクティスを提供します。
02
オプションの移行オプション
周知のとおり、大量のデータを含むデータベースの移行は困難な問題です。データベースは常に読み取りと書き込みが行われているため、ターゲット データベース内の現在の全データの初期化を完了する必要があるだけでなく、初期化中のデータの変更を新しいデータベースに同期する必要もあります。以下は移行計画の概略図です。
MongoDB は、oplog と変更ストリームという 2 つの方法でドキュメントの変更を記録することがわかっています。oplog または変更ストリームのストレージ容量は限られているため、完全な初期化フェーズでの移行速度を考慮する必要があります。さらに、増分同期フェーズの速度は、古いデータベースと新しいデータベースの間でデータの一貫性を実現するために、ソース データベースの変更速度よりも高速である必要があります。これら 2 つの段階を完了するには、安定した効率的なツールに依存する必要があります。特に大規模なデータベースを移行する場合は、特定のデータ移行戦略 (並列処理や圧縮、コールド データとホット データを別々に移行する、異なるコレクションを別々に移行するなど) と連携する必要さえあります。
考えられる移行シナリオは 3 つあります。
▪ Amazon DMS の完全 + 増分移行。
▪ Mongoshake の完全 + 増分移行。
▪ Mongodump/mongorestore + DMS 増分移行
プラン1:
Amazon DMS フル + 増分
DMS は、リレーショナル データベース、MongoDB データベース、およびその他の種類のデータ ストアの移行を可能にする Amazon のクラウド サービスです。DMS を使用すると、1 回限りの移行を実行したり、継続的な変更をソース リポジトリにレプリケートしてソースとターゲットの同期を保つことができます。DMS は、完全移行フェーズで自動セグメンテーションおよび範囲セグメンテーションのメソッドを提供し、並行して移行を加速します。CDC 増分フェーズでは、バージョン 3.5 ベータ版は DocumentDB への同時書き込みもサポートします。
構成リファレンス:
https://docs.aws.amazon.com/zh_cn/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.html。
シナリオ 2:
Mongoshake フル + インクリメンタル
オープンソースの Mongoshake は、DocumentDB への移行と書き込みもサポートしています。オープンソース製品であるため、コミュニティが活発で、問題を解決するためにカスタマイズして開発することができ、移行速度が速いという利点がありますが、問題に対する技術サポートが比較的少ないという欠点があり、ユーザーは自分自身を見つけるか、コミュニティに助けを求める必要があります。
オプション 3:
Mongodump/mongorestore + DMS インクリメンタル
Mongodump は MongoDB が提供する公式バックアップ ツールで、MongoDB データベースからデータを読み取り、BSON ファイルを生成し、それを mongorestore ツールを通じて MongoDB に復元できます。DocuemntDB からのバックアップ データもサポートします。mongodb-database-tools の 6.1 バージョンは、DocumentDB Elastic Cluster へのリカバリもサポートしています。このソリューションの利点は安定性と高速性であることですが、欠点は増分同期機能が不十分であることです。ただし、DMS の増分同期機能を利用することはできます。重要なのは、データ損失を防ぐために増分同期の開始点を選択することです。
以下の表に示すように、上記の 3 つのオプションにはそれぞれ長所と短所があります。
DMS ホスティング サービスを使用すると、ユーザーが移行タスクを構成するのに最も便利です。移行プロセス全体を通じて、ログが明確で、速度が直感的で、可観測性が良好です。Mongoshake は、DocumentDB への増分書き込みでは若干遅く、TPS が高いシナリオには適用できませんが、MongoDB の大規模なデータベース移行シナリオでは、mongodump と mongorestore は DMS フルロードよりも高速です。大規模なデータベースの移行を成功させるための非常に重要な要素は、移行速度です。したがって、オプション 3 をお勧めします。以下では、Mongodump/mongorestore + DMS 増分ソリューションの詳細な手順に焦点を当てます (他のソリューションの手順および関連する移行パフォーマンスのチューニング方法については、他の記事で補足されます)。
03
モンゴダンプ/モンゴリストア +
DMS増分計画の詳細な手順
環境の説明:
3.1 EC2環境の展開
EC2 は主に、mongo ツールと DocumentDB ツールをデプロイし、ソース ライブラリからエクスポートされた Bson ファイルを保存するために使用されます。mongodump はデータを BSON ファイルとしてエクスポートしますが、大きなテーブルの BSON ファイルも多くのスペースを占有するため、より大きなデータ ディスクを構成する必要があります。この場合、3TBのデータディスクが構成されます。
(1) 適切なオペレーティング システムを選択します。
以下の図に示すように、オペレーティング システムとして Amazon linux 2 を選択します。
(2) 適切なモデルを選択してください
mongorestore は同時インポートをサポートしているため、ユーザーは並列数をカスタマイズできます。モデルの vCPU の数は並列数と同じか 2 倍にすることをお勧めします。この記事では、16 個の同時インポート テストを使用することを目的としているため、モデル m5a.4xlarge を選択します。
(3) DocDB と同じ AZ、VPC、サブネットを選択します
インポート中のクロスアベイラビリティーゾーンによるレイテンシの増加を避けるために、mongodb ツールの EC2 と DocDB Elastic Cluster を同じ AZ および VPC にデプロイすることをお勧めします。ネットワーク設定を編集し、異なるサブネットを選択することで、適切なサブネットを選択できます。アリゾナ州
(4) 適切なサイズのディスクを追加します
mongodump によってエクスポートされた BSON ファイルのサイズに応じて、適切なサイズの EBS ディスクを選択します。たとえば、次の図では、今回テストしたデータベースは約 2.3TB であるため、3000GiB の EBS ディスクを選択します。次に、「インスタンスの起動」をクリックして EC2 インスタンスをデプロイします。
(5) ダンプファイルを格納するファイルシステムを作成し、ディレクトリをマウントします。
(4)は追加データディスクの作成のみで、EC2デプロイ後にファイルシステムの作成が必要となり、実際にダンプファイルを格納するディレクトリを作成してファイルシステムにマウントします。具体的な参考資料:
https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/add-instance-store-volumes.html#making-instance-stores-available-on-your-instances。
作成済みのEC2の場合は、EBSデバイスをデータディスクとして追加することもできます。追加方法については、以下を参照してください。
https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/ebs-attaching-volume.html。
3.2 mongo ツールのインストール
説明: この場合、データディスクが追加され、ダンプファイルを保存するディレクトリ /backup が作成されます。ソース mongoDB がクラウドにない場合は、ソース mongoDB が配置されている IDC でステップ 3.2 と 3.3 を実行し、ステップ 3.1 でデプロイされた EC2 にダンプ ファイルを転送します。次の手順では、Amazon クラウド内にお客様が独自に構築した MongoDB を例として取り上げます。
(1) EC2にログインしてツールをダウンロード
# 进入工具安装目录，自定义一个即可
cd /data/mongo
wget https://fastdl.mongodb.org/tools/db/mongodb-database-tools-amazon2-x86_64-100.6.1.tgz左にスワイプするとさらに表示されます
注: mongo tools のバージョンは mongodb-database-tools-amazon2-x86_64-100.6.1 である必要があります。mongoresotre の他のバージョンは、DocumentDB Elasti Cluster クラスターのインポートをサポートしていません。
(2) 解凍してインストール
tar zxvf mongodb-database-tools-amazon2-x86_64-100.6.1.tgz左にスワイプするとさらに表示されます
3.3 ソースデータベースデータのエクスポート
mongodump を実行してデータをエクスポートします。-d はデータベースを指定し、-c はコレクション名を指定し、-o はダンプ出力ディレクトリを指定します。詳細なパラメータは、 mongodump –help を通じて表示できます 。
cd /data/mongo/mongodb-database-tools-amazon2-x86_64-100.6.1/bin
nohup ./mongodump -h ip-172-xxxx.ec2.internal:27017 -u <YourUser> -p <YourPassword> -d demodb -c usertable -o /backup > dump.out 2>&1 &
# 查看导出进度
tail -f ycsb_test2.out
2023-04-12T04:27:01 writing demodb.usertable to /backup/demodb/usertable.bson
2023-04-12T08:48:57.031+0000 done dumping demodb.usertable (2000000000 documents)
# 查看备份文件
ls -l /backup/*
-rw-rw-r-- 1 ec2-user ec2-user 2335759066463 Apr 12 08:48 usertable.bson
-rw-rw-r-- 1 ec2-user ec2-user 204 Apr 12 04:27 usertable.metadata.json左にスワイプするとさらに表示されます
「xxxxdb.xxxxtable のダンプが完了しました」というメッセージが表示されたら、エクスポートが完了したことを意味します。
注: エクスポート開始時に UTC 時刻 2023-04-12T04:27:01 を記録する必要があります。DMS の増分タスクを構成する場合、開始時刻はこのイベント スタンプに基づいて設定されます。
3.4ターゲット DocDB に作成する
シャーディングが有効になっているデータベースとコレクション
非シャーディング コレクションをシャーディング コレクションに書き込みたいため、事前にシャーディング キーを設計し、DocumentDB Elastic Cluster でシャーディング コレクションを作成する必要があります。そうしないと、mongorestore が 1 シャード モードでインポートし、達成できません。水平シャーディング効果。
(1) ターゲットライブラリの作成
ターゲット ライブラリでは、enableharding を有効にする必要があります。tempdb という名前のライブラリを作成し、シャーディング構文を有効にします。
db.runCommand( { enablesharding :"tempdb"});
{ "ok" : 1 }左にスワイプするとさらに表示されます
(2) コレクションを作成する
sharding-key はデフォルトの _id を選択し、ハッシュ方式に従ってシャーディングします。現在、Elastic Cluster はハッシュ モードのみをサポートしています。作成構文は次のとおりです。
sh.shardCollection( "demodb.usertable", { "_id": "hashed" } )
{ "ok" : 1 }左にスワイプするとさらに表示されます
3.5 ターゲットライブラリへのデータのインポート
注: ソース mongoDB が顧客の IDC にある場合、または DocDB と同じ AZ にない場合は、ターゲット DocDB が配置されている EC2 (つまり、ステップ 3.1 でデプロイされた EC2 インスタンス) に事前に転送する必要があります。mongorestore を使用してデータをインポートするコマンドは次のとおりです。
nohup ./mongorestore -hdocdb-cluster1-xxxx.us-east-1.docdb-elastic.amazonaws.com \
--ssl -u <YourUser> -p <YourPassword> -c usertable -d tempdb \
--dir=/backup/demodb/usertable.bson \
--numInsertionWorkersPerCollection=16 > mongorestore_log.out 2>&1 &左にスワイプするとさらに表示されます
パラメータの説明:
–numInsertionWorkersPerCollection では、同時インポートのワーカー数を指定できますが、これは DocDB 内のシャードの数に直接関係しません。 -d では、ターゲット データベースの名前を指定できます。ターゲット データベースの名前はソース データベースとは異なる場合があります。–dir は、BSON ファイルの絶対アドレスを指定します。
2023-04-12T10:23:53.924+0000 checking for collection data in /backup/demodb/usertable.bson
2023-04-12T10:23:53.924+0000 reading metadata for tempdb.usertable from /backup/demodb/usertable.metadata.json
2023-04-12T10:23:53.982+0000 restoring to existing collection tempdb.usertable without dropping
2023-04-12T10:23:53.982+0000 restoring tempdb.usertable from /backup/demodb/usertable.bson
2023-04-12T10:23:56.921+0000 [........................] tempdb.usertable 141MB/2175GB (0.0%)
2023-04-12T10:23:59.920+0000 [........................] tempdb.usertable 322MB/2175GB (0.0%)
2023-04-12T10:24:02.921+0000 [........................] tempdb.usertable 555MB/2175GB (0.0%)
2023-04-12T10:24:05.920+0000 [........................] tempdb.usertable 772MB/2175GB (0.0%)
2023-04-12T10:24:08.921+0000 [........................] tempdb.usertable 1018MB/2175GB (0.0%)
2023-04-12T10:24:11.921+0000 [........................] tempdb.usertable 1.21GB/2175GB (0.1%)
2023-04-13T07:04:32.920+0000 [#######################.] tempdb.usertable 2175GB/2175GB (100.0%)
2023-04-13T07:04:35.920+0000 [#######################.] tempdb.usertable 2175GB/2175GB (100.0%)
2023-04-13T07:04:38.117+0000 [########################] tempdb.usertable 2175GB/2175GB (100.0%)
2023-04-13T07:04:38.117+0000 finished restoring tempdb.usertable (2000000000 documents, 0 failures)
2023-04-13T07:04:38.117+0000 restoring indexes for collection tempdb.usertable from metadata
2023-04-13T07:05:43.131+0000 index: &idx.IndexDocument{Options:primitive.M{"name":"idx_name", "ns":"tempdb.usertable", "v":2}, Key:primitive.D{primitive.E{Key:"name", Value:1}}, PartialFilterExpression:primitive.D(nil)}
2023-04-13T07:05:43.132+0000 2000000000 document(s) restored successfully. 0 document(s) failed to restore.左にスワイプするとさらに表示されます
「ドキュメントが正常に復元されました」というメッセージが表示されたら、インポートが完了したことを意味します。
移行インデックス
デフォルトでは、Mongorestore はデータの移行後にインデックスを自動的に移行します。ユーザーは、mongorestore 中にインデックスを移行しないことを選択し (mongorestore の後に –noIndexRestore オプションを追加)、Amazon DocumentDB インデックス ツールを使用してソース Amazon DocumentDB クラスターからインデックスをエクスポートし、ターゲット ライブラリに復元することもできます。詳細については、Amazon 開発者ガイドを参照してください: https://docs.aws.amazon.com/zh_cn/documentdb/latest/developerguide/docdb-migration.versions.html#docdb-migration.versions-step3。
インデックスについては、Elastic Cluster ではサポートされていない次のインデックスに注意する必要があります。
▪ スパースインデックス
▪ TTL インデックス
▪ 地理空間インデックス
▪ バックグラウンドインデックスの作成
3.6書き込みインジケーターの監視
CloudWatch にログインして、各シャードのインポート速度を表示できます。CloudWatch→すべてのメトリクス→DocDB Elastic→「DocumentsInserted」を検索して、各シャードを確認して、次の図に示すようにダッシュボードを生成します。
この場合、シャードが 3 つあり、各シャードのデータ書き込み速度が約 220,000 ライン/秒であることがわかります。
3.7 増分同期
DMS コンソールを介して増分同期タスクを構成します。具体的な参照は次のとおりです。
(1) エンドポイントの作成
他の移行タスクと同様に、ソース エンドポイントとターゲット エンドポイントを個別に作成する必要があります。このうち、ソース エンドポイントは MongoDB のエンドポイントであり、図に示すように、自己構築された MongoDB は接続情報を手動で入力する方法を選択します。以下では、紫色の部分の選択に注意する必要があります。
ターゲット エンドポイントは DocumentDB のエンドポイントであり、上の図とほぼ一致しています。
(2) レプリケーションインスタンスの作成
CDC の速度はレプリケーション インスタンスのモデルに関連しており、テスト用にさまざまなモデルを選択できます。インスタンスは移行のみに使用され、長期的な同期には使用されないため、レプリケートされたインスタンスと DocumentDB を同じアベイラビリティ ゾーンにデプロイできるように、単一のアベイラビリティ ゾーン (移行の完了後に解放される) 内のインスタンスを選択することをお勧めします。アベイラビリティーゾーンを強化し、CDC 書き込み速度を向上させます。さらに、DMS の並列 CDC を使用して DocumentDB に書き込む場合は、バージョン 3.5.0 (ベータ) 以降を選択する必要があります。
(3) 増分同期タスクの作成
タスクを作成するときに、識別子を入力し、上で構成したレプリケーション インスタンスとエンドポイントを選択し、次に移行タイプで「データ変更のみをレプリケートする」を選択して、CDC 増分同期のみを実行します。
次のタスク設定では、カスタム起動モードを有効にすることができます。つまり、どのタイムスタンプから変更ストリームの取得を開始し、ターゲット DocumentDB への書き込みを開始するかを宣言できます。正しい開始時刻を入力してください。この時刻は、データの整合性を確保するために Mongodump が開始される時刻である必要があります。この時刻は上で保存されています。
上に示したように、タスク設定では、ターゲット テーブル準備モードを何もしないに設定する必要があります。つまり、ターゲット ライブラリがすでに存在することが判明した場合に無視することを選択するように DMS に指示します。その理由は、シャーディングを有効にしてコレクションを作成したためです。DMS がテーブルを再構築する場合、通常の非シャーディング コレクションしか再構築できず、シャーディング設計の本来の意図から逸脱します。モニタリングタスクをより適切に行うには、「CloudWatch ログをオンにする」オプションをオンにすることをお勧めします。
次に、コレクションのマッピング ルールを構成し、同期されたデータベース名とコレクション名を宣言します。データベース全体のテーブルに対して増分タスクを実行している場合は、テーブル名を個別に構成する必要はありません。ソース ライブラリとターゲット ライブラリでスキーマの名前が異なる場合は、ここでマッピング ルールを構成することもできます。
作成ページの下部に、タスクの作成後にすぐに移行タスクを開始するかどうかに関するオプションがあります。並列 CDC のパラメーターを変更したいため、後で手動で開始することを選択し、「」にチェックを入れる必要があります。後で手動で。」最後に「タスクの作成」をクリックしてタスクの作成は完了です。
(4) 並列 CDC パラメータを変更する
タスクが作成された後、タスクは準備完了状態 (開始されていない) になっている必要があります。ここで、DocumentDB の DMS CDC の並列適用機能を有効にします。タスクを確認して、[変更] をクリックし、[タスク設定] を見つけて、(以下に示すように) Json エディターを選択します。
# 修改 TargetMetadata 中以下 3 个参数（以下参数值是配置示例）
"ParallelApplyBufferSize": 1000,
"ParallelApplyQueuesPerThread": 200,
"ParallelApplyThreads": 16,左にスワイプするとさらに表示されます
次に、「保存」をクリックします。
これら 3 つのパラメータは DMS 3.5 (ベータ版) から導入された非常に重要なパラメータであり、その目的は、DocumentDB への CDC 書き込み速度を向上させ、大容量ドキュメント データベースの移行成功率を向上させることです。
ParallelApplyThreads: CDC ロード中に Amazon DMS がデータ レコードをターゲット リポジトリにプッシュするために使用する並列スレッドの数を指定します。
ParallelApplyBufferSize: CDC ロード中に各バッファ キューに保存されるレコードの最大数を指定します。
ParallelApplyQueuesPerThread: CDC 中にスレッドごとにアクセスされるキューの数を指定します。
具体的な参考資料:
https://docs.aws.amazon.com/zh_cn/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.htmlj。
(5) CDC 開始時刻の変更
前述したように、DMS が CDC タスクを実行するときは、全量のデータを初期化する必要があります。ステップ (3) で正しい時刻を選択しなかった場合は、このステップで Amazon CLI を使用して時刻をリセットできます。データの一貫性を確保するために、DMS はデータ初期化の時点を ChangeStream をプルする開始チェックポイントとして使用する必要があります。
前提条件: Amazon CLI を設定する
Step1.ソースライブラリでoplogのスコープを確認できます
rs0:PRIMARY> rs.printReplicationInfo()
configured oplog size: 8961.375MB
log length start to end: 304secs (0.08hrs)
oplog first event time: Wed Apr 12 2023 10:06:24 GMT+0000 (UTC)
oplog last event time: Wed Apr 12 2023 10:11:28 GMT+0000 (UTC)
now: Wed Apr 12 2023 10:11:30 GMT+0000 (UTC)左にスワイプするとさらに表示されます
注: ステップ 2 で --cdc-start-time で指定した値は、上記の範囲内である必要があります。そうでない場合、oplog が見つからないため、タスクは起動時に失敗します。DMS はデフォルトで CDC 移行用の変更ストリームを選択しますが、変更ストリームのリカバリ トークンも oplog のタイムスタンプに直接関連しています。
Step2.変更を実行する
aws dms modify-replication-task \
--replication-task-arn "arn:aws:dms:us-east-1:7301234567:task:xoxxxo" \
--cdc-start-time "2023-04-12T10:06:50"左にスワイプするとさらに表示されます
注: 上記のコマンド変更を実行するには、DMS タスクが停止状態である必要があります。
--replication-task-arn は、DMS 移行タスクの ARN です。
–cdc-start-time は、mongodump が開始されたときの開始時刻です。上記のエクスポートが開始されたときに記録されます。ここでの具体的な時間の値は参照用です。
(6) CDCタスクの開始
タスクを開始すると、MongoDB から DocumentDB への CDC データの同期が正式に開始されます。具体的な方法: 開始する必要がある CDC タスクを確認し、[アクション] をクリックし、[再起動/再開] を選択してタスクを開始します。
注: CDC タスクが一度中断に失敗し、cdc-start-time が変更されている場合は、タスクを開始した後、[再起動] または [再開] を選択して、[再起動] を選択してください。[再開] が誤って選択された場合、cdc は最後の一時停止またはタスクの失敗の時点から変更ストリームをプルするため、手動で設定した cdc-start-time が有効になりません。
(7) CDC タスクの監視
タスクの開始後、増分同期のステータスを知る必要がある場合は、DMS の「CloudWatch メトリクス」または「CloudWatch ログの表示」を通じて監視できます。
CloudWatch メトリクス
以下の図に示すように、タスクを入力した後、CloudWatch メトリクス タブをクリックし、CDC タスクを選択すると、CDC レイテンシー ソースと CDC レイテンシー ターゲットのインジケーターが表示されます。遅延が短縮されない場合は、データが遅延している可能性があります。同期効率の問題。遅延が徐々に縮小している場合は、増加分が徐々に追い付いていることを意味します。
CloudWatch ログを表示する
CloudWatch Logs を通じて、特定の DMS によって実行されたログを確認できます。たとえば、Log を使用すると、Parallel apply が有効かどうか、ターゲット ライブラリ DocumentDB がログの変更を正常に適用しているかどうかを確認できます。
上の図に紫色の背景と紫色のボックス「[TARGET_APPLY]I: 一括適用モードで動作中」が表示されている場合は、並列適用が正常に有効になっていることを意味します。以下の図は、通常の書き込みログを示しています。これは、毎回 200 レコードがキューから取得され、ターゲットの DocumentDB ライブラリに適用されることを意味します。
04
要約する
この記事は主に、MongoDB を使用して大規模なドキュメント型データをサポートするときに顧客が遭遇する拡張の問題から始まり、スケーラビリティに対するさらなる解決策を提案します。また、MongoDB レプリカ セットの大規模データベースの移行の難しさを目的としており、大規模なデータベースへの移行に高いスケーラビリティを提供します。水平シャーディング 永続的な DocumentDB Elastic Cluster には 3 つのオプションがあります。次に、mongodump/mongorestore フル + DMS インクリメントの移行計画の詳細な手順を詳しく紹介します。この移行ソリューションは非常に効率的で、MongoDB を Amazon に移行するための効果的なソリューションであり、DocumentDB インスタンスベースのクラスターの Elastic Cluster への移行もサポートしています。どのデータベースも無制限の変更ストリームと oplog を保持するわけではないことに注意してください。完全な移行中に増分ログが削除されると、移行プロセスではデータの最終的な整合性が保証されなくなり、移行全体が無効になります。たとえば、DocumentDB インスタンスベースのクラスターの変更ストリームは、最大 7 日間の保存期間をサポートします (実際の環境に応じて完全な移行速度をテストし、変更中に移行できるデータの最大量を見積もることをお勧めします)ストリームの保存期間）。したがって、特定の企業の MongoDB または DocumentDB のストレージ容量が TB レベルに達し、データ量がまだ増加していることが判明した場合は、できるだけ早くシャーディングを設計および変更してください。早期検出と早期最適化により、データベースが大きくなりすぎて、アーキテクチャの最適化とデータ移行がますます困難になるのを防ぎます。
05
参照文書
DMS：
タスクの作成：
https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.Creating.html
対象メタデータタスク設定：
https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.html
ドキュメントDB：
Amazon DocumentDB への移行：
https://docs.aws.amazon.com/documentdb/latest/developerguide/docdb-migration.html
Amazon DocumentDB エラスティッククラスターの使用：
https://docs.aws.amazon.com/documentdb/latest/developerguide/docdb-using-elastic-clusters.html
この記事の著者
金川
Amazon クラウド テクノロジー データベース ソリューション アーキテクト。Amazonクラウド テクノロジーに基づくソリューション コンサルティングとデータベースのアーキテクチャ設計を担当します。Amazon Cloud Technologyに入社する前は、Huawei、Alibaba Cloud などの企業で長年勤務しており、データベースの選択とアーキテクチャ設計、データベースの最適化、データ移行、ビッグデータ、データ ウェアハウスの構築において豊富な技術経験を持っています。設計と実装の経験。
聞いたので、下の 4 つのボタンをクリックしてください
バグに遭遇することはありません！
