Why AWS DMS Reports Error 1032 and How to Investigate It

この文書の適用条件

そのまま実行できるコマンド

-- 対象: Aurora MySQL / RDS for MySQL（DMSターゲット）
-- 権限: ターゲットDBへの接続権限
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_ROWS
FROM information_schema.TABLES
WHERE TABLE_NAME IN (
    'awsdms_apply_exceptions',
    'awsdms_validation_failures_v1',
    'awsdms_status',
    'awsdms_suspended_tables',
    'awsdms_history'
)
ORDER BY TABLE_SCHEMA, TABLE_NAME;

-- 対象: DMSターゲット上の制御スキーマ（既定名は ControlSchema 設定に依存）
-- 権限: 制御スキーマへの SELECT
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
SELECT
    TASK_NAME,
    TABLE_OWNER,
    TABLE_NAME,
    ERROR_TIME,
    LEFT(STATEMENT, 500) AS statement_head,
    LEFT(ERROR, 500)     AS error_head
FROM awsdms_control.awsdms_apply_exceptions
ORDER BY ERROR_TIME DESC
LIMIT 50;

-- 対象: DMSターゲット上の制御スキーマ（EnableValidation 有効時のみ生成）
-- 権限: 制御スキーマへの SELECT
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
SELECT
    TASK_NAME,
    TABLE_OWNER,
    TABLE_NAME,
    FAILURE_TIME,
    KEY_TYPE,
    `KEY`            AS row_key,
    FAILURE_TYPE,
    LEFT(DETAILS, 500) AS details_head
FROM awsdms_control.awsdms_validation_failures_v1
ORDER BY FAILURE_TIME DESC
LIMIT 50;

-- 対象: ソース・ターゲット双方で同じSQLを実行して結果を比較する
-- 権限: 対象スキーマのメタデータ参照権限
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
SELECT
    t.TABLE_SCHEMA,
    t.TABLE_NAME,
    (SELECT GROUP_CONCAT(k.COLUMN_NAME ORDER BY k.ORDINAL_POSITION)
       FROM information_schema.KEY_COLUMN_USAGE k
      WHERE k.TABLE_SCHEMA    = t.TABLE_SCHEMA
        AND k.TABLE_NAME      = t.TABLE_NAME
        AND k.CONSTRAINT_NAME = 'PRIMARY')            AS pk_columns,
    (SELECT COUNT(DISTINCT s.INDEX_NAME)
       FROM information_schema.STATISTICS s
      WHERE s.TABLE_SCHEMA = t.TABLE_SCHEMA
        AND s.TABLE_NAME   = t.TABLE_NAME
        AND s.NON_UNIQUE   = 0)                        AS unique_index_count
FROM information_schema.TABLES t
WHERE t.TABLE_SCHEMA = 'SampleDB'
  AND t.TABLE_TYPE   = 'BASE TABLE'
ORDER BY t.TABLE_NAME;

-- 対象: DMSターゲットのAurora MySQL
-- 権限: 対象テーブルへの SELECT
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
-- awsdms_apply_exceptions の STATEMENT に出ていたキー値をそのまま当てる
SELECT COUNT(*) AS target_row_count
FROM SampleDB.sample_table
WHERE id = 1001;

-- 併せてソース側でも同じ条件で確認し、片方にしか無いのかを判定する
SELECT COUNT(*) AS source_row_count
FROM SampleDB.sample_table
WHERE id = 1001;

# 対象: AWS DMS レプリケーションタスク
# 権限: IAM dms:DescribeReplicationTasks
# 変更作業: なし（参照のみ）
# Production 実行: 可能

# 1) タスク一覧と状態
aws dms describe-replication-tasks \
  --query 'ReplicationTasks[].{Id:ReplicationTaskIdentifier,Type:MigrationType,Status:Status}' \
  --output table

# 2) 対象タスクの設定JSONをそのまま取り出す（設定名の実体はここで確認する）
aws dms describe-replication-tasks \
  --filters Name=replication-task-id,Values=example-dms-task \
  --query 'ReplicationTasks[0].ReplicationTaskSettings' \
  --output text

// 対象: AWS DMS レプリケーションタスク設定（抜粋）
// 権限: IAM dms:ModifyReplicationTask（変更にはタスク停止が必要）
// 変更作業: あり（適用エラー時の挙動が変わる）
// Production 実行: 影響を理解したうえでのみ。IGNORE_RECORD は変更を黙って捨てる
{
  "TargetMetadata": {
    "TargetTablePrepMode": "DO_NOTHING"
  },
  "ErrorBehavior": {
    "ApplyErrorInsertPolicy": "LOG_ERROR",
    "ApplyErrorUpdatePolicy": "LOG_ERROR",
    "ApplyErrorDeletePolicy": "IGNORE_RECORD",
    "ApplyErrorEscalationPolicy": "LOG_ERROR",
    "ApplyErrorEscalationCount": 0,
    "TableErrorPolicy": "SUSPEND_TABLE"
  },
  "ValidationSettings": {
    "EnableValidation": true,
    "ValidationMode": "ROW_LEVEL",
    "ThreadCount": 5
  }
}

結果の読み方

こういう状況で使います

• The DMS task log repeatedly shows `Error 1032` or `ER_KEY_NOT_FOUND`
• Errors increase right after entering the CDC phase, and only a specific table is stuck
• The task status stays `Running`, but the target's row count never catches up with the source
• The DMS console's table statistics show a specific table as `Table error` / suspended
• After enabling validation, a large number of rows appeared in `awsdms_validation_failures_v1`

考えられる原因（可能性の高い順）

1. 01

   The target row was never loaded at the full-load/CDC boundary

   A row inserted after the full-load snapshot and later updated or deleted may not exist on the target even if the CDC update arrives first. Check the relationship between the task start position and the full-load completion time.

2. 02

   The primary key / unique key doesn't match between source and target

   If the target's primary key column differs, or the primary key has been redefined, the WHERE clause DMS generates won't match the target row. Cross-check `KEY_COLUMN_USAGE` on both sides.

3. 03

   The target table has no primary key

   Without a primary key, DMS looks up the target row by matching all columns. Differences in floating-point representation, character encoding, or LOB handling can cause a mismatch, resulting in 1032. Tables targeted for CDC are expected to have a primary key or unique key.

4. 04

   Rows or columns are excluded by selection/transformation rules

   If table mapping filters migrate only some rows, a CDC update for an excluded row arrives but doesn't exist on the target, causing an error. Column renaming or exclusion has the same effect.

5. 05

   Another process is writing to the target

   If the application, another DMS task, or a batch job writes to the target, it breaks the row state DMS assumes. As a rule, writes to a migrating target should be limited to DMS alone.

6. 06

   The binlog was purged sooner than needed, causing a gap in changes

   If the source's binlog retention period is too short, CDC can miss reads, and applying changes can start from an inconsistent state upon resume. See the related article for checking retention time.

確認手順

1. 1

   Check the substance of the error via the control tables

   参照のみ

   Read `awsdms_apply_exceptions` in descending time order to identify the target table, statement, and key value. This is read-only and safe.

2. 2

   Check the task log in CloudWatch Logs

   参照のみ

   In the `dms-tasks-<replication-instance-name>` log group, check what happened around the error (resume, table suspension, connection drop).

3. 3

   Cross-check the primary key definitions between source and target

   参照のみ

   Run the metadata SQL above on both sides and check whether `pk_columns` match and whether any table shows NULL.

4. 4

   Check whether the row for the given key exists on both source and target

   参照のみ

   Which side it exists on determines whether this is a load gap or an ordering issue.

5. 5

   Check the task's table mapping and settings JSON

   参照のみ

   Pull the actual settings with `describe-replication-tasks` and check the current values of filters, transformation rules, and `ErrorBehavior`.

6. 6

   Enable validation to measure the extent of the divergence

   中

   Enabling `EnableValidation` puts comparison load on both source and target. Run it during a window that can tolerate the load.

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• Check the source's binlog retention period

  If retention is too short and CDC is missing reads, a setting change will not fix it.

• Check the DMS replication instance's resources

  If CPU, memory, or storage is under pressure, apply delays and task resumes increase, making boundary issues more likely.

• Check for cascading updates from triggers or foreign keys on the source

  Rows that cascade-update on the source may not be reproduced on the target.

• Check whether errors other than 1032 are mixed in

  If duplicate key (1062) and others occur at the same time, the cause is a separate issue.

• Cross-check the list of migrated tables against the application's write paths

  Confirm via actual connection sources — not just the design — that DMS is the only thing writing to the target.

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• DMS CDC cannot apply an UPDATE and the task stops
• How to read awsdms_apply_exceptions
• Can a table with no primary key be migrated via DMS CDC
• How to investigate a mismatch reported by DMS validation

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

Tracking down a single Error 1032 is as simple as reading the control tables. What's difficult operationally is having to keep watching the task state and divergence status throughout the entire migration period. GIIP periodically collects the trend of DMS task status, error counts, and validation results, and also preserves the control table contents at the moment an error occurs. An AI agent handles the day-to-day isolation and initial reporting, and for decisions that involve data divergence, such as `IGNORE_RECORD`, human approval is always required.

関連サービス

• 障害対応・火消し支援
• AWSマネージド運用の範囲を確認する