はじめに
AWS DMSを使用したデータ移行時、失敗したレコードがawsdms_validation_failures_v1に記録される問題に直面することがあります。特に、継続的にデータベース間のデータ同期を行う場合、これらの問題を無視し続けることはできず、適切なデータの補正作業が必要となります。
本記事では、この課題を解決するために構築したシステムの概要を紹介します。データ不整合の修正と再同期のプロセスを詳しく解説し、同じ問題を抱えるエンジニアの方々に役立つ情報を提供します。
問題の背景
awsdms_validation_failures_v1とは？
AWS DMSが移行に失敗したレコードを記録するシステムテーブルです。このテーブルには以下のような情報が格納されます：
-
table_name: 失敗が発生したテーブル名 -
column_name: 問題の発生したカラム名 -
error_message: 詳細なエラーメッセージ詳細はAWSドキュメントの「制御テーブルタスク設定」「トラブルシューティング」で確認できます
主な移行失敗の原因
- LOB設定の問題
- データ型の不一致
- CDC中のエラー
詳細はAWSドキュメントの「AWS DMS のソースデータベースとターゲットデータベース間のデータ不一致の問題をトラブルシューティングするにはどうすればよいですか?」で確認できます
解決策の概要
解決方法
データの不整合を解決する方法として、テーブル全体をフルロードして再同期する方法があります。しかし、この方法は、テーブル全体のデータ量に対して修復が必要なレコードが少ない場合には、非効率でコストが高くなる可能性があります。
こうした非効率なケースに対応するために、個別レコードを対象とした修復システムを構築しました。このシステムを利用することで、不整合データの修復を自動化し、効率的かつ迅速にデータを同期できるようになります。
システム構成
システムの概要
- 自動補正アプリケーションが
awsdms_validation_failures_v1を定期的にチェック -
awsdms_validation_failures_v1を解析し、検証エラーが発生したSourceTableとTargetTableの当該レコード解析する - TargetTableに対して、修正クエリーを発行する
-
awsdms_validation_failures_v1の処理結果をApp_logTableに書き込む
修正方法の詳細はAWSドキュメントの「トラブルシューティング」で確認できます
システム構築の詳細
使用技術
- Java : 自作するアプリケーションの開発言語
- Argo Workflows : アプリケーションを定期実行できる環境
自動補正アプリケーションの機能説明
このアプリケーションは、awsdms_validation_failures_v1テーブルを参照し、データ不整合が発生したレコードの原因や状況を確認します。その後、アプリケーションがこれらのレコードを解析し、ソーステーブル（SourceTable）とターゲットテーブル（TargetTable）の内容を比較して、適切にターゲットテーブルのレコードを修復します。
修復が完了すると、DMSの検証処理によって再度レコードが確認され、問題が解消されたことを確認できます。
重要なポイント
- データ補正後も
awsdms_validation_failures_v1のレコードは削除されないため、アプリケーションが同じレコードを再処理しないようにする必要があります。 - 修復済みのレコードを記録する「ログテーブル」を設けることで、同じレコードを繰り返し修正することを防止します。
DMS検証の詳細はAWSドキュメントの「AWS DMS データ検証」で確認できます
所感
AWS DMSには、データの検証機能と、その結果をawsdms_validation_failures_v1に記録する機能が提供されています。しかし、不正データを再同期するための機能は用意されていないため、独自のアプリケーションを作成し、補正処理を実装する必要があります。
補正処理の実装形式は複数考えられますが、今回の実装では処理がある程度複雑になることを見越して、AWS Lambdaのような簡易的な環境は利用せず、複雑な処理に対応可能な開発環境と言語を選択しました。
また、補正処理が単一テーブルに対する処理であったため、アルゴリズムを確定させた後は、SourceTableとTargetTableのDDLをもとに、アプリケーションのソースコードを自動生成する仕組みも構築することができました。