Amazon Web Services ブログ
Amazon RDS for SQL Server で変更データキャプチャパラメータを構成する
AWS Database Migration Service (AWS DMS) は、データベースと分析ワークロードを AWS に迅速かつ安全に移行するためのマネージド型のマイグレーションおよびレプリケーションサービスです。移行中もソースデータベースは完全に稼働し続けるため、データベースに依存するアプリケーションのダウンタイムを最小限に抑えることができます。AWS DMS は、最も広く使用されている商用およびオープンソースのソースデータベースとターゲットデータベースの間でデータを移行できます。
SQL Server は Microsoft が開発したリレーショナルデータベースです。 Amazon Relational Database Service (Amazon RDS) for SQL Server を使用すると、クラウド上で SQL Server の展開を簡単に設定、運用、スケーリングできます。Amazon RDS はデータ レプリケーションをサポートしており、変更データキャプチャ (CDC) を有効にすることが、AWS DMS と Amazon RDS for SQL Server を使用するための前提条件の 1 つとなっています。CDC はテーブルのデータに加えられた変更をキャプチャします。それぞれの変更に関するメタデータを格納し、後で参照できます。
この投稿では、CDC パラメータについて深く掘り下げ、AWS DMS の設定時の影響について説明するとともに、いくつかのベストプラクティスについても説明します。
前提条件
この投稿に沿って進めるには、次の AWS サービスに精通している必要があります。
- AWS DMS
- Amazon RDS for SQL Server
さらに、このソリューションに必要なリソースを起動するのに十分な権限を持つ AWS アカウントが必要です。
AWS DMS は Amazon RDS for SQL Server とどのように連携するのか
Amazon RDS for SQL Server の場合、AWS DMS は Microsoft の関数を使用してトランザクションログを読み取り、デフォルトで上位 50,000 イベントを取得します。AWS DMS は、AWS DMS タスクで定義されたテーブルに関連する特定のパーティション ID のデータベースログを照会することから始まります。パーティション ID は、フルロードと CDC の両方で、各テーブルの再ロード、タスクの再起動、タスクの再開時に読み取られます。AWS DMS はオブジェクト ID を取得し、それらのオブジェクト ID に対応するデータパーティション ID を取得します。パーティション ID を取得した後、関連するパーティションをトランザクションログからフェッチします。このサイクルは 1 秒ごとに実行されます。
次の図は、アーキテクチャを示しています。この例では、Amazon RDS for SQL Server をソースとして使用しています。AWS DMS タスクのターゲットは、サポートされている任意のエンドポイントになります。
AWS DMS は、Microsoft の関数を使ってトランザクションログを読み取り、AWS の DMS タスクの対象となるテーブルとソースデータベースで CDC が有効になっている必要があります。
なぜ AWS DMS で CDC が必要なのか ?
テーブルで CDC が有効になると、SQL Server は cdc
スキーマにテーブルを作成します。作成されたテーブル (変更テーブル) には変更データが格納され、トラッキングされているスキーマとテーブルに基づいて名前が付けられます。たとえば、dbo
スキーマに customer
という名前のテーブルがある場合、dbo.customer
テーブルに対するすべての変更を記録するために cdc.customer_CT
という名前のテーブルが cdc
スキーマに作成されます。
AWS DMS は変更テーブルを読み取りません。AWS DMS は、変更がトランザクションログに確実に記録されるように CDC を有効にする必要があります。前のセクションで説明したように、AWS DMS は Microsoft の関数を使ってトランザクションログから変更を読み取ります。ソース側の次のテーブルを考えてみましょう。
このテーブルに UPDATE ステートメントを発行して [name]
列を更新すると、 [RowLog Contents 0]
と [RowLog Contents 1]
に変更情報が更新されます。AWS DMS がソース上で実行する次のクエリの一部を示します。
クエリの結果を見ると、2 番目のレコードに CDC を有効にした後に発行した UPDATE ステートメントの状態がトランザクションログにキャプチャされていることが分かります。
Current LSN | operation | RowLog Contents 0 | RowLog Contents 1 |
0000014f:0000c16d:0002 | LOP_MODIFY_ROW | 0x1800746573747573657267 | 0x190074657374757365726162 |
0000014f:0000c9ba:0016 | LOP_MODIFY_ROW | 0x30000800020000000200000100190074657374757365726162 | 0x300008000200000002000001001800746573747573657267 |
CDC パラメータの理解
CDC では、2 つのジョブが作成されます。
- キャプチャジョブ – トランザクションログファイルを読み取り、変更をトラッキングするテーブルにプッシュします。
- クリーンアップジョブ – 保持期間を過ぎた変更トラッキングテーブルのレコードを削除します。
以下は、AWS DMS に関連する CDC パラメータです。
- max_trans – 各スキャンサイクルで処理するトランザクションの最大数
- max_scans – ログからすべての行を抽出するために実行するスキャンサイクルの最大数
- continuous – キャプチャジョブを継続的に実行するか (1)、1回だけ実行するか (0) を示します
- polling_interval – ログスキャンサイクル間の秒数
- retention – 変更行がテーブルに保持される分数
AWS DMS は変更テーブルを読み取らないので、トランザクションログの変更の保持を制御するために CDC パラメータを調整する必要があります。
次のセクションでは、max_trans
、max_scans
、polling_interval
パラメータがトランザクションログ内のレコードの保持にどのように役立つのか、AWS DMS が変更をキャプチャするのに十分な期間変更が保持されるように調整する方法について説明します。
CDC パラメータの実行
これらのパラメーターを説明するために、次の手順を踏みます。
dmscdc
データベースとその中のdmstestcdc
テーブルを作成してください。- データベース
dmscdc
およびテーブルdmstestcdc
で CDC を有効にします。CDC パラメータを調整して、ログレコードが十分な期間保持されるようにする必要があります。そうすることで、AWS DMS がトランザクションレコード、つまり、ソースデータベースのトランザクションログファイルで探している特定のログシーケンス番号 (LSN) を照会できるようになります。これらは次の要因に左右されます。
- ターゲットがソースに比べてどれくらいトランザクションが遅れているか
- CDC ジョブの実行頻度、つまり特定のポーリング間隔はどのくらいか
Maxtrans
とMaxscans
の値は何か。これらのパラメータは、CDC が各実行でどれくらいのトランザクションを処理するかを決定します。
- 次のように取り込みジョブを構成してください。取り込みジョブのパラメーターを変更する場合は、毎回 CDC ジョブを停止して再起動する必要があります。この場合、
pollinginterval
を変更する必要があります。 - 次のコマンドを実行して CDC パラメータを確認してください。
job_id job_type job_name maxtrans maxscans continuous pollinginterval retention threshold A49487C5-BF3C-4A8C-9385-6AFA7A3541B9 capture cdc.dmscdc_capture
500 10 1 3599 0 0 17511020-59D2-4C9E-BEA9-0578C0D23B11 cleanup cdc.dmscdc_cleanup
0 0 0 0 4320 5000 前述の設定では、キャプチャジョブは 1 時間の周期で 5,000 レコード (
maxtrans
*maxscans
) を処理します。 - テーブル
dmstestcdc
にレコードをいくつか挿入して確認してください。キャプチャジョブは、トランザクションログから前の取引を読み取り、それらを
replicated
されたものとしてマークします。この場合は 100,001 レコードです。CDC ジョブが実行されると、キャプチャジョブはそれらの取引を完了としてマークします。 - 次のクエリを実行して CDC セッションを確認してください。これにより 10 行が取得されるはずです。このクエリにより、CDC が処理したレコード数が分かります。今回の場合は 5,000 件です。
tran_count | start_time | end_time | scan_phase |
500 | 2023-12-07 20:34:15.100 | 2023-12-07 20:34:15.123 | Done |
500 | 2023-12-07 20:34:15.067 | 2023-12-07 20:34:15.083 | Done |
500 | 2023-12-07 20:34:15.037 | 2023-12-07 20:34:15.053 | Done |
500 | 2023-12-07 20:34:15.003 | 2023-12-07 20:34:15.023 | Done |
500 | 2023-12-07 20:34:14.963 | 2023-12-07 20:34:14.990 | Done |
500 | 2023-12-07 20:34:14.927 | 2023-12-07 20:34:14.950 | Done |
500 | 2023-12-07 20:34:14.883 | 2023-12-07 20:34:14.910 | Done |
500 | 2023-12-07 20:34:14.840 | 2023-12-07 20:34:14.870 | Done |
500 | 2023-12-07 20:34:14.797 | 2023-12-07 20:34:14.827 | Done |
500 | 2023-12-07 20:34:14.540 | 2023-12-07 20:34:14.773 | Done |
前述のレコードは、通常 5 分ごとに行われる Amazon RDS for SQL Server のトランザクションログのバックアップ時にトランザクションログから削除されます。これにより、トランザクションログのサイズを維持し、LSN を進めることができます。残りのレコード (95,001件) は、次のキャプチャジョブの実行時に取り込まれます。
SQL Server は CDC によってトランザクションが読み取られた後でしか トランザクションログをフラッシュしません。トランザクションログに保持するレコード数と AWS DMS のレプリケーションラグのバランスを取る必要があります。この場合、ポーリング間隔を短くすることで、キャプチャジョブのパラメータを積極的に設定します。その結果、トランザクションログから LSN が欠落するシナリオが発生する可能性があります。トランザクションログの切り捨てを回避して、変更が十分な期間トランザクションログに保持されるようにするには、次のコマンドを実行してポーリング間隔を 1 日に設定することをお勧めします。
CDC の履歴情報のキャプチャ
キャプチャジョブの履歴情報を監視するには、sys.dm_cdc_log_scan_sessions テーブルを照会できます。このテーブルには、現在のデータベース内の各ログスキャンセッションに対して 1 行が含まれています。最大 32 のスキャンセッションが含まれます。次のクエリを実行して、最新の 10 レコードを取得します。
以下はサンプル出力です。
session_id | start_time | end_time | duration | scan_phase | error_count | tran_count | command_count | last_commit_cdc_time | latency | empty_scan_count | failed_sessions_count |
0 | 2023-12-07 19:21:27.283 | 2023-12-08 00:34:12.837 | 6 | Aggregate | 0 | 125001 | 125001 | 2023-12-07 19:50:32.657 | 17020 | 0 | 0 |
651 | 2023-12-08 00:34:12.820 | 2023-12-08 00:34:12.837 | 0 | Done | 0 | 500 | 500 | 2023-12-07 19:50:32.657 | 17020 | 0 | 0 |
650 | 2023-12-08 00:34:12.790 | 2023-12-08 00:34:12.810 | 0 | Done | 0 | 500 | 500 | 2023-12-07 19:50:31.700 | 17021 | 0 | 0 |
649 | 2023-12-08 00:34:12.760 | 2023-12-08 00:34:12.780 | 0 | Done | 0 | 500 | 500 | 2023-12-07 19:50:30.707 | 17022 | 0 | 0 |
648 | 2023-12-08 00:34:12.703 | 2023-12-08 00:34:12.723 | 0 | Done | 0 | 500 | 500 | 2023-12-07 19:50:29.757 | 17023 | 0 | 0 |
647 | 2023-12-08 00:34:12.670 | 2023-12-08 00:34:12.693 | 0 | Done | 0 | 500 | 500 | 2023-12-07 19:50:28.620 | 17024 | 0 | 0 |
646 | 2023-12-08 00:34:12.633 | 2023-12-08 00:34:12.660 | 0 | Done | 0 | 500 | 500 | 2023-12-07 19:50:27.523 | 17025 | 0 | 0 |
645 | 2023-12-08 00:34:12.587 | 2023-12-08 00:34:12.620 | 0 | Done | 0 | 500 | 500 | 2023-12-07 19:50:26.527 | 17026 | 0 | 0 |
644 | 2023-12-08 00:34:12.530 | 2023-12-08 00:34:12.573 | 0 | Done | 0 | 500 | 500 | 2023-12-07 19:50:25.490 | 17027 | 0 | 0 |
643 | 2023-12-08 00:34:12.500 | 2023-12-08 00:34:12.520 | 0 | Done | 0 | 500 | 500 | 2023-12-07 19:50:24.450 | 17028 | 0 | 0 |
ベストプラクティスと既知の問題
このセクションでは、CDC パラメーターに関するベストプラクティスと考慮事項をいくつか説明します。
Multi-AZ インスタンスでのフェイルオーバー時にトランザクションログレコードが切り捨てられる
プライマリインスタンスで CDC パラメータを変更した場合は、必ず rds_set_configuration コマンドを実行して、フェイルオーバー時にも変更内容が保持されるようにしてください。
例えば、dms_test
データベース上で次のサンプルコマンドを実行して、maxtrans
と pollinginterval
パラメータを設定できます。
フェイルオーバー後もこれらの値が保持されるように、次のコマンドを実行してください。
AWS DMS レプリケーションインスタンスの計画的フェイルオーバーまたはメンテナンス
Amazon RDS for SQL Server の場合、ソースでメンテナンス作業を行う際、あるいは関連する AWS DMS レプリケーションインスタンスの計画的なスケーリングを行う際に、AWS DMS タスクが停止する度にキャプチャジョブが実行されないようにする必要があります。キャプチャジョブが実行されると、スキャンされたイベントは Amazon Simple Storage Service (Amazon S3) で 5 分ごとにトランザクションログバックアップが行われるときにトランザクションログから削除されます。
- 次のコマンドを実行してキャプチャジョブを停止してください。
- AWS DMS タスクを停止します。
- 必要なメンテナンスを完了します。
- AWS DMS タスクを再開します。
- ソースの遅延が 0 になるのを待ちます。
- 次のコマンドを実行してキャプチャジョブを開始します。
AWS DMS タスクは、上記の手順に従わない場合、次のエラーメッセージで失敗します。
ソースでキャプチャジョブを停止した後に LSN が切り捨てられているのを確認した場合、アクティブなトランザクションログ内に切り捨てを防ぐ CDC イベントがない可能性があります。これはデータベースがアイドル状態にあるか、トランザクション数が少ない場合に発生する可能性があります。この場合、手順は次のとおりです。
- 次のコマンドを実行してキャプチャジョブを停止してください。
- AWS DMS タスクを停止する前に、CDC 対応のデータベースにいくつかのトランザクションまたは変更があることを確認してください。毎秒 DML ステートメントを実行するスクリプトを実行できます。テストスクリプトを作成する場合は、このセクションの後半に記載されている手順に従ってください。
- AWS DMS タスクを停止します。
- 必要なメンテナンスを完了させます。
- AWS DMS タスクを再開します。
- ソースレイテンシを監視して同期を待ちます。
- ステップ 2 で設定したスクリプトを停止します。
- 次のコマンドを実行してキャプチャジョブを開始します。
ステップ 2 で言及されたテストスクリプトを実行するためのスクリプトを設定するには、以下の手順に従ってください。以下のスクリプトでは、dbo スキーマの下に test_table という名前のテーブルを作成し、その test_table テーブルで CDC を有効にします。次に、SQL Server エージェントジョブを設定し、上記のテーブルにレコードを挿入してから削除します。これにより、CDC ジョブによってピックアップされる必要のあるトランザクションログに変更があり、トランザクションログの切り捨てを防ぐことができます。
- テストテーブルを作成します。
- 新しいテーブルを CDC に追加してください。
- Amazon RDS で SQL Server エージェントジョブを作成し、1 分ごとにレコードを挿入または削除します。エージェントジョブで適切な owner_login_name と database_name の値を使用してください。
- AWS DMS コンソールで、AWS DMS タスクのテーブル選択ルールにワイルドカード (%) を使用してこのテーブルを複製する場合は、マッピングルールを使用してこのテーブルを AWS DMS タスクから除外してください。
SQL Server インスタンスの RDS の計画的な再起動またはフェイルオーバー
RDS for SQL Server エージェントサービスは、RDS for SQL Server インスタンスの再起動やフェイルオーバーが発生するたびに再起動し、これにより再起動またはフェイルオーバー後に CDC ジョブが再実行されます。トランザクションログの切り捨てを回避するには、次の手順に従ってください。
- AWS DMS タスクを停止します。
- フェイルオーバー後に元に戻すため、現在の
maxtrans
とmaxscans
の値を取得します。 - CDC の設定を変更して、
maxtrans
とmaxscans
を 1 に設定します。 - フェイルオーバー後も CDC パラメーターを保持するため、次のステートメントを実行してください。
- RDS for SQL Server インスタンスを再起動します。
- AWS DMS タスクを再開します。
- キャプチャされた構成で、キャプチャされたジョブを再起動します。次のスクリプトでは、
maxtrans
を 500、maxscans
を 10 と想定していますが、ステップ 2 でキャプチャした値を使用する必要があります。 - フェイルオーバー後も CDC パラメータを保持するために、次のステートメントを実行してください。
後片付け
定期的な課金を避けるために、リソースをクリーンアップしてください。
- AWS DMS コンソールで、設定したすべての AWS DMS タスクを削除します。
- 次のコマンドを実行してデータベースを削除します。
結論
この投稿では、Amazon RDS for SQL Server をソースとして AWS DMS タスクを構成する際の CDC パラメーターの設定の重要性を説明し、さらにベストプラクティスについても説明しました。
翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文はこちらです。
著者について
Suchindranath Hegde は、Amazon Web Services のデータマイグレーションスペシャリストソリューションアーキテクトです。AWS DMS を使用して AWS クラウドへのデータ移行に関するガイダンスと技術支援をお客様に提供しています。
Abhishek Chaturvedi は、Amazon Web Services の DMS チームのシニアデータベースエンジニアです。
Mahesh Kansara は、Amazon Web Services のデータベースエンジニアリングマネージャーです。彼は開発およびエンジニアリングチームと密接に協力し、移行およびレプリケーションサービスの改善に取り組んでいます。また、お客様と協力し、さまざまなデータベースおよび分析プロジェクトに関するリードとテクニカルサポートを提供し、AWS を使用する際のソリューションの価値向上をサポートしています。
Junu Thankappan は、Amazon Web Services のシニアデータベースエンジニアです。彼は AWS RDS チームに所属し、商用データベースエンジンと SQL Server に注力しています。