AWS DMS を使用した継続的なレプリケーション用のタスクの作成 - AWS Database Migration Service

英語の翻訳が提供されている場合で、内容が矛盾する場合には、英語版がオリジナルとして取り扱われます。翻訳は機械翻訳により提供されています。

AWS DMS を使用した継続的なレプリケーション用のタスクの作成

ソースデータストアへの継続的な変更をキャプチャする AWS DMS タスクを作成できます。データの移行中にこのキャプチャを実行できます。サポートされているターゲットデータストアへの初回(全ロード)の移行が完了した後で、継続的な変更をキャプチャするタスクを作成することもできます。このプロセスは継続的なレプリケーションまたは変更データキャプチャ (CDC) と呼ばれます。AWS DMS では、このプロセスを使用してソースデータストアの継続的な変更をレプリケートします。このプロセスでは、データベースエンジンのネイティブ API を使用してデータベースログへの変更を収集します。

注記

全ロードタスクのみを使用してビューを移行できます。タスクが CDC のみのタスクであるか、完了後に CDC を開始する全ロードタスクである場合、移行にはソースのテーブルのみが含まれます。全ロードのみのタスクを使用して、ビューまたはテーブルとビューの組み合わせを移行できます。詳細については、 JSON を使用したテーブル選択および変換ルールの指定 を参照してください。

ソースエンジンごとに、この変更ストリームを指定されたユーザーアカウントに開示するための固有の設定要件があります。ほとんどのエンジンでは、キャプチャプロセスでデータ損失を発生させずに意味のある方法で変更データを使用するために、追加の設定が必要です。たとえば、Oracleは補足ログの追加を要求します。 MySQL には、行レベルのバイナリ ロギング(bin logging)が必要です。

ソースデータベースから継続的な変更を読み取るために、AWS DMS はエンジン固有の API アクションを使用してソースエンジンのトランザクションログから変更を読み取ります。これを AWS DMS で実行する例を以下に示します。

  • Oracleの場合、 AWS DMS OracleまたはOracleの LogMiner 進行中の変更を読み取るための API またはバイナリリーダー API (bfile API)。 AWS DMS システム変更番号(SCN)に基づいて、オンラインまたはアーカイブREDOログから進行中の変更を読み取ります。

  • Microsoft SQL Server の場合、AWS DMS は MS-Replication または MS-CDC を使用して SQL Server のトランザクションログに情報を書き込みます。次に、SQL Server の fn_dblog() 関数または fn_dump_dblog() 関数を使用して、ログシーケンス番号 (LSN) に基づいてトランザクションログの変更を読み取ります。

  • 対象 MySQL、 AWS DMS 行ベースのバイナリ ログ(binlog)から変更を読み取り、それらの変更をターゲットに移行します。

  • 対象 PostgreSQL、 AWS DMS 論理レプリケーション スロットを設定し、test_decodingプラグインを使用してソースから変更を読み取り、ターゲットに移行します。

  • ソースとしての Amazon RDS の場合は、CDC をセットアップするためのバックアップが有効になっていることを確認してください。また、変更ログを十分な時間だけ (通常は 24 時間) 保持するようにソースデータベースが設定されていることを確認してください。

継続的なレプリケーションタスクには 2 つのタイプがあります。

  • 全ロード + CDC – タスクでは、まず既存のデータを移行し、次にソースデータベースへの変更に応じてターゲットデータベースを更新します。

  • CDC のみ – タスクでは、ターゲットデータベースにデータが取り込まれた後の継続的な変更を移行します。

CDC 開始ポイントからのレプリケーションの実行

AWS DMS の継続的なレプリケーションタスク (変更データのキャプチャのみ) は、複数のポイントから開始できます。これには次のものが含まれます。

  • カスタム CDC 開始時刻から – AWS マネジメントコンソール または AWS CLI を使用して、レプリケーションを開始するタイムスタンプを AWS DMS に提供できます。AWS DMS は、このカスタム CDC 開始時刻から継続的なレプリケーションタスクを開始します。AWS DMS は、提供されたタイムスタンプ (UTC) をネイティブ開始ポイント (SQL Server の LSN または Oracle の SCN など) に変換します。AWS DMS は、エンジン固有の方法を使用し、ソースエンジンの変更ストリームに基づいて移行タスクの開始位置を決定します。

    注記

    PostgreSQL をソースとする場合、カスタム CDC の開始時刻はサポートされません。これは、 PostgreSQL データベースエンジンには、OracleやSQL Serverのように、LSNやSCNにタイムスタンプをマッピングする方法がありません。

  • CDC ネイティブの開始ポイントから – ソースエンジンのトランザクションログのネイティブポイントから開始することもできます。場合によっては、タイムスタンプはトランザクションログで複数のネイティブポイントを示すことができるため、このアプローチのほうが適している場合があります。AWS DMS では、この機能を以下のソースエンドポイントでサポートしています。

    • SQL Server

    • PostgreSQL

    • Oracle

    • MySQL

CDC ネイティブの開始ポイントの決定

CDC ネイティブの開始ポイントは、CDC を開始できる時間を定義するデータベースエンジンのログ内のポイントです。たとえば、特定の時点からあるバルクデータダンプがターゲットに適用されているとします。この場合、ダンプが取得されるより前のポイントから継続的なレプリケーションのみのタスクのネイティブ開始ポイント始点を参照できます。

以下の例では、サポートされているソースエンジンから CDC ネイティブの開始ポイントを見つける方法を示します。

SQL Server

SQL Server では、ログシーケンス番号 (LSN) は以下の 3 つのパートで構成されています。

  • 仮想ログファイル (VLF) シーケンス番号

  • ログブロックの開始オフセット

  • スロット番号

LSN の例: 00000014:00000061:0001

トランザクションログのバックアップ設定に基づいて SQL Server の移行タスクの開始ポイントを取得するには、SQL Server の fn_dblog() 関数または fn_dump_dblog() 関数を使用します。

SQL Server で CDC ネイティブの開始ポイントを使用するには、継続的なレプリケーションに参加しているいずれかのテーブルでパブリケーションを作成します。パブリケーションの作成の詳細については、「 継続的なレプリケーション用の SQL Server パブリケーションの作成」を参照してください。CDC ネイティブ開始ポイントを使用せずに CDC を使用すると、AWS DMS が自動的にパブリケーションを作成します。

PostgreSQL

CDCリカバリ チェックポイントは、 PostgreSQL ソース データベース。進行中のレプリケーションタスクはソースデータベース (親タスク) に対して実行されるため、このチェックポイント値はまざまな時点で生成されます。チェックポイント全般の詳細については、以下を参照してください。 チェックポイントを CDC の開始ポイントとして使用する.

ネイティブ開始ポイントとして使用するチェックポイントを特定するには、データベース pg_replication_slots ビューを使用するか、AWS マネジメントコンソール から親タスクの概要の詳細を使用します。

コンソールで親タスクの概要の詳細を検索するには

  1. AWS マネジメントコンソール にサインインした後、https://console.aws.amazon.com/dms/v2/ にある AWS DMS コンソールを開きます。

    IAMユーザーとしてサインインしている場合は、アクセスするための適切な権限があることを確認してください。 AWS DMS. 必要なアクセス権限の詳細については、「AWS DMS の使用に必要な IAM アクセス許可」を参照してください。

  2. ナビゲーションペインで、[データベース移行タスク] を選択します。

  3. [データベース移行タスク] ページのリストから親タスクを選択します。これにより、親タスクページが開き、概要の詳細が表示されます。

  4. [データキャプチャの変更 (CDC)]、[データキャプチャの変更 (CDC) の開始位置]、および [データキャプチャの変更 (CDC) リカバリチェックポイント] でチェックポイント値を見つけます。

    値は、次のようになります。

    checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

    ここでは、このネイティブ CDC 開始ポイントを指定するために必要な 4AF/B00000D0 コンポーネントです。DMS APIの設定 CdcStartPosition CDCタスクを作成して、この開始ポイントでレプリケーションを開始するときに、このパラメータをこの値に指定してください。 PostgreSQL ソース。AWS CLI を使用して CDC タスクを作成する方法の詳細については、「RDS での CDC の使用 PostgreSQL DBインスタンス」を参照してください。

Oracle

システム変更番号(SCN)は、Oracleデータベースで使用される論理的な内部タイムスタンプです。 SCNs トランザクションのACIDプロパティを満たすために必要な、データベース内で発生するイベントの順序を指定します。Oracleデータベースは SCNs すべての変更がディスクに書き込まれた場所をマークして、リカバリ アクションがすでに書き込まれた変更を適用しないようにします。Oracleは、 SCNs リカバリを停止できるように、データのセットのやり直しが存在しないポイントにマークを付けます。

Oracleデータベースの現在のSCNを取得するには、次のコマンドを実行します。

SELECT CURRENT_SCN FROM V$DATABASE

現在のSCNを使用してCDCタスクを開始すると、未完了のトランザクションの結果が見つからず、これらの結果を移行できません。未処理のトランザクション は、以前に開始されたがコミットされていないトランザクションです。すべてのオープントランザクションを含む時点で、CDCタスクを開始するためのSCNとタイムスタンプを識別できます。詳細については、以下を参照してください。 取引 Oracleのオンラインマニュアルを参照してください。

MySQL

のリリース前 MySQL バージョン5.6.3、ログシーケンス番号(LSN) MySQL は 4 バイトの符号なし整数です。イン MySQL バージョン5.6.3では、redoログ・ファイルのサイズ制限が4 GBから512 GBに増加した場合、LSNは8バイトの符号なし整数になります。この引き上げは、サイズ情報の保存に追加のバイトが必要になったことが理由です。アプリケーション構築の基盤 MySQL LSN値を使用する5.6.3以降では、32ビット変数ではなく64ビットを使用して、LSN値を格納および比較する必要があります。詳細情報については、 MySQL LSNs」を参照してください。 MySQL ドキュメント.

現在のLSNを MySQL 次のコマンドを実行します。

mysql> show master status;

このクエリから、binlog ファイルの名前、位置、およびその他いくつかの値が返されます。CDCネイティブ開始点は、binlogsファイル名と位置の組み合わせです。たとえば、 mysql-bin-changelog.000024:373. この例では mysql-bin-changelog.000024 はbinlogsファイル名で、 373 は、 AWS DMS は、変更のキャプチャを開始する必要があります。

チェックポイントを CDC の開始ポイントとして使用する

継続的なレプリケーションタスクでは変更を移行し、AWS DMS では AWS DMS 固有のチェックポイント情報を時々キャッシュします。AWS DMS が作成するチェックポイントに含まれている情報に従って、レプリケーションエンジンは変更ストリームの復旧ポイントを確認します。チェックポイントを使用して変更のタイムラインをさかのぼり、失敗した移行タスクを復旧できます。チェックポイントを使用して、別のターゲットに向けて別の継続的なレプリケーションタスクを任意の時点から開始することもできます。

チェックポイント情報は、以下の 2 つの方法で取得できます。

  • API コマンド DescribeReplicationTasks を実行して結果を確認します。情報をタスク別にフィルタ処理し、チェックポイントを検索できます。タスクが停止状態または失敗状態のときに最新のチェックポイントを取得できます。

  • ターゲットインスタンスで awsdms_txn_state というメタデータテーブルを表示します。テーブルにクエリを実行してチェックポイント情報を取得できます。メタデータテーブルを作成するには、タスクの作成時に TaskRecoveryTableEnabled パラメータを Yes に設定します。この設定により、AWS DMS はチェックポイント情報を継続的にターゲットメタデータテーブルに書き込みます。タスクを削除すると、この情報は失われます。

    次に、メタデータテーブル checkpoint:V1#34#00000132/0F000E48#0#0#*#0#121 でのチェックポイントの例を示します

コミット時間ポイントまたはサーバー時間ポイントでのタスクの停止

CDC ネイティブの開始ポイントの導入により、AWS DMS では以下のポイントでタスクを停止することもできます。

  • ソースのコミット時間

  • レプリケーションインスタンスのサーバー時間

必要に応じてタスクを変更し、停止する時刻を UTC で設定できます。タスクは、設定したコミット時間またはサーバー時間に基づいて自動的に停止します。または、タスクの作成時に移行タスクを停止する時間があらかじめわかっている場合は、タスクの作成時に停止時間を設定できます。

双方向レプリケーションの実行

AWS DMS タスクを使用すると、2 つのシステム間で双方向レプリケーションを実行できます。双方向レプリケーションでは、2 つのシステム間で同じテーブル (またはテーブルのセット) のデータを両方向にレプリケートします。

たとえば、データベース A からデータベース B に EMPLOYEE テーブルをコピーし、テーブルの変更内容をデータベース A からデータベース B にレプリケートできます。さらに、EMPLOYEE テーブルの変更内容をデータベース B から A にレプリケートすることもできます。したがって、双方向レプリケーションを実行していることになります。

注記

AWS DMS 双方向レプリケーションは、プライマリノード、競合解決などを含む完全なマルチマスターソリューションとしては意図されていません。

異なるノード上のデータが動作的に分離されている状況で双方向レプリケーションを使用します。つまり、ノード A で動作しているアプリケーションによって変更されたデータ要素があり、そのノード A がノード B との双方向レプリケーションを実行するとします。ノード A のそのデータ要素は、ノード B で動作するアプリケーションによって変更されることはありません。

AWS DMS バージョン 3.3.1 以上では、次のデータベースエンジンでの双方向レプリケーションがサポートされています。

  • Oracle

  • SQL Server

  • MySQL

  • PostgreSQL

  • MySQL と互換性がある Amazon Aurora

  • PostgreSQL との互換性がある Aurora

双方向レプリケーションタスクの作成

AWS DMS 双方向レプリケーションを有効にするには、両方のデータベース (A と B) のソースとターゲットのエンドポイントを設定します。たとえば、データベース A のソースエンドポイント、データベース B のソースエンドポイント、データベース A のターゲットエンドポイント、データベース B のターゲットエンドポイントを設定します。

次に、ソース A からターゲット B にデータを移動するタスクと、ソース B からターゲット A にデータを移動するタスクの 2 つのタスクを作成します。さらに、各タスクでループバック防止が設定されていることを確認します。これにより、両方のタスクのターゲットに同一の変更が適用されて、少なくとも一方のタスクのデータが破損するのを防ぐことができます。詳細については、ループバックの防止 を参照してください。

最も簡単な方法として、まずデータベース A とデータベース B の両方に同一のデータセットを作成します。次に CDC 専用タスクを 2 つ作成します。1 つは A から B にデータをレプリケートするタスクで、もう 1 つは B から A にデータをレプリケートするタスクです。

AWS DMS を使用してノード A からノード B の新しいデータセット (データベース) をインスタンス化するには、次の操作を行います。

  1. データベース A から B にデータを移動するには全ロードおよび CDC タスクを使用します。この間、アプリケーションによりデータベース B のデータが変更されないようにしてください。

  2. 全ロードが完了した後、アプリケーションがデータベース B のデータを変更できるようになる前に、データベー ス B の時刻または CDC 開始位置をメモします。手順については、「CDC 開始ポイントからのレプリケーションの実行」を参照してください。

  3. この開始時刻または CDC 開始位置を使用して、データベース B から A にデータを移動する CDC 専用タスクを作成します。

注記

全ロードと CDC にできる双方向ペアのタスクは 1 つだけです。

ループバックの防止

ループバックの防止について説明するため、タスク T1 で AWS DMS がソースデータベース A から変更ログを読み取り、ターゲットデータベース B に変更内容を適用するとします。

次に、2番目のタスクであるT2は、ソース・データベースBから変更ログを読み取り、それをターゲット・データベースAに適用します。これを行う前に、DMSは、ソース・データベースAからターゲット・データベースBに行われた変更と同じ変更がソース・データベースAに行われていないことを確認する必要があります。つまり、DMSは、これらの変更がターゲット・データベースAにエコー(ループ)されていないことを確認する必要があります。そうしないと、データベースAのデータが破損する可能性があります。

変更のループバックを防止するには、各双方向レプリケーションタスクに次のタスク設定を追加します。これにより、ループバックデータの破損がどちらの方向でも発生しなくなります。

{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": Boolean, "SourceSchema": String, "TargetSchema": String }, . . . }

LoopbackPreventionSettings タスク設定により、トランザクションが新規であるか、反対方向のレプリケーションタスクからのエコーであるかが決まります。AWS DMS がトランザクションをターゲットデータベースに適用すると、DMS テーブル (awsdms_loopback_prevention) が変更のマークで更新されます。各トランザクションをターゲットに適用する前に、DMS はこの awsdms_loopback_prevention テーブルへの参照を含むトランザクションをすべて無視します。したがって、変更が適用されません。

これらのタスク設定は、双方向ペアの各レプリケーションタスクに含めます。これらの設定により、ループバック防止が有効になります。さらに、各エンドポイントの awsdms_loopback_prevention テーブルを含むタスク内の各ソースおよびターゲットデータベースのスキーマも指定します。

各タスクがこのようなエコーを識別し、破棄できるようにするには、 EnableLoopbackPreventiontrue. を含むソースでスキーマを指定するには awsdms_loopback_prevention、セット SourceSchema をソース データベース内のスキーマの名前に変更します。同じテーブルを含むターゲットでスキーマを指定するには、TargetSchema をターゲットデータベース内のそのスキーマの名前に設定します。

次の例では、レプリケーションタスク T1 とその反対方向のレプリケーションタスク T2 の SourceSchema および TargetSchema 設定が、反対方向の設定で指定されています。

タスク T1 の設定は以下のとおりです。

{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": true, "SourceSchema": "LOOP-DATA", "TargetSchema": "loop-data" }, . . . }

反対方向のタスク T2 の設定は以下のとおりです。

{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": true, "SourceSchema": "loop-data", "TargetSchema": "LOOP-DATA" }, . . . }
注記

AWS CLI を使用する場合、create-replication-task または modify-replication-task コマンドだけを使用して、双方向レプリケーションタスクで LoopbackPreventionSettings を設定します。

双方向レプリケーションの制限

AWS DMS の双方向レプリケーションには、次の制限があります。

  • ループバック防止は、データ操作言語 (DML) ステートメントのみを追跡します。AWS DMS は、データ定義言語 (DDL) ループバックの防止をサポートしていません。これを行うには、双方向ペアのいずれかのタスクを、DDL ステートメントが除外されるように設定します。

  • ループバック防止を使用するタスクは、一括変更のコミットをサポートしていません。ループバック防止を使用してタスクを設定するには、BatchApplyEnabledfalse に設定します。

  • DMS 双方向レプリケーションには、競合の検出や解決は含まれていません。データの不整合を検出するには、両方のタスクでデータ検証を使用します。