AWS DMS에서 Error 1032가 발생하는 원인과 확인 방법
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
MySQL의 Error 1032는 `ER_KEY_NOT_FOUND`로, DMS의 CDC 작업에서는 "변경을 적용하려는 대상 쪽 행이 존재하지 않는다"는 의미입니다. 원인은 대부분 풀 로드와 CDC 경계에서의 누락, 소스와 타겟의 기본 키 불일치, 타겟 테이블에 기본 키가 없음, 필터나 변환 규칙에 의한 행 제외, 타겟에 대한 다른 프로세스의 쓰기 중 하나입니다. 먼저 타겟의 `awsdms_apply_exceptions`를 읽어 실패한 문장과 대상 키를 특정하십시오.
この文書の適用条件
| 対象製品 | AWS DMS(타겟: Aurora MySQL / RDS for MySQL) |
|---|---|
| 確認バージョン | MySQL 5.7 호환 / 8.0 호환 타겟. DMS의 작업 설정 항목명은 복제 인스턴스의 엔진 버전에 따라 다르므로 실제 작업의 JSON으로 확인 |
| 適用環境 | AWS(DMS 복제 인스턴스 + Aurora MySQL 타겟) |
| 必要権限 | 제어 테이블 조회는 타겟 DB에 대한 `SELECT` 권한. 작업 설정 변경은 IAM의 `dms:ModifyReplicationTask` |
| 実行影響 | 제어 테이블 조회는 영향 없음. 작업 설정 변경은 작업의 중지·재개를 수반함 |
| 再起動 | DB 재시작은 불필요. 작업 설정 변경에는 DMS 작업의 중지와 재개가 필요 |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- Aurora MySQL / RDS for MySQL(DMS 타겟)
- 権限
- 타겟 DB 접속 권한
- 変更作業
- 없음(조회만)
- Production実行
- 가능
-- 対象: 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;제어 테이블이 생성되는 스키마는 작업 설정의 `ControlSchema`로 결정됩니다. 기본값 그대로면 타겟 쪽 어느 스키마에 배치되는지가 환경마다 달라지므로, 먼저 이 SQL로 실제 배치를 확인한 뒤 다음 쿼리의 스키마명을 바꿔 넣으십시오.
- 対象
- DMS 타겟의 제어 스키마
- 権限
- 제어 스키마에 대한 `SELECT` 권한
- 変更作業
- 없음(조회만)
- Production実行
- 가능
-- 対象: 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;`STATEMENT`에는 실패한 UPDATE/DELETE 문이, `ERROR`에는 엔진이 반환한 오류 본문(1032 포함)이 들어갑니다. `STATEMENT`의 WHERE 절에 나오는 값이 타겟에 존재하지 않았던 키입니다.
- 対象
- DMS 타겟의 제어 스키마(`EnableValidation`이 활성화된 경우에만 생성됨)
- 権限
- 제어 스키마에 대한 `SELECT` 권한
- 変更作業
- 없음(조회만)
- Production実行
- 가능
-- 対象: 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;`KEY`는 MySQL의 예약어이므로 백틱으로 감쌌습니다. 1032가 발생한 테이블이 여기에도 나타난다면, 단발성 적용 실패가 아니라 데이터 자체가 어긋나 있는 것입니다.
- 対象
- 소스·타겟 양쪽의 MySQL 호환 DB
- 権限
- 대상 스키마의 메타데이터 조회 권한
- 変更作業
- 없음(조회만)
- Production実行
- 가능
-- 対象: ソース・ターゲット双方で同じ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;`pk_columns`가 NULL인 테이블은 기본 키가 없습니다. 기본 키가 없는 테이블에 대한 CDC의 UPDATE/DELETE는 DMS가 전체 열 일치로 대상 행을 찾기 때문에 1032가 발생하기 쉽습니다. 소스와 타겟의 `pk_columns`가 다른 경우도 마찬가지입니다.
- 対象
- DMS 타겟의 Aurora MySQL
- 権限
- 대상 테이블에 대한 `SELECT` 권한
- 変更作業
- 없음(조회만)
- Production実行
- 가능
-- 対象: 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実行
- 가능
# 対象: 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 textDMS의 작업 설정은 버전에 따라 사용할 수 있는 항목이 다릅니다. 문서의 설정 항목명을 그대로 믿지 말고, 이 명령으로 실제 작업의 JSON을 출력해 존재하는 항목만 편집하십시오. 작업 로그는 CloudWatch Logs의 `dms-tasks-<복제 인스턴스명>` 로그 그룹에 출력됩니다.
- 対象
- AWS DMS 복제 작업 설정
- 権限
- IAM: `dms:ModifyReplicationTask`(작업 중지 필요)
- 変更作業
- 있음(오류 발생 시 동작이 바뀜. IGNORE_RECORD는 변경을 폐기함)
- Production実行
- 영향을 이해한 경우에만. `IGNORE_RECORD`는 데이터 불일치를 발생시킴
// 対象: 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
}
}`ApplyErrorDeletePolicy`를 `IGNORE_RECORD`로 설정하면, 삭제할 수 없었던 변경을 기록하지 않고 폐기합니다. 오류는 멈추지만 소스와 타겟의 데이터가 어긋나게 됩니다. 원인 파악이 끝나기 전까지는 `LOG_ERROR`를 유지하고, `IGNORE_RECORD`로 설정할 경우에는 "어느 테이블의 어느 기간 변경을 버렸는지"를 검증(validation)으로 추적할 수 있는 상태로 만든 뒤 진행하십시오. `TargetTablePrepMode`를 `DROP_AND_CREATE`로 설정하면 풀 로드 시 타겟 테이블이 재생성되어 기존 데이터가 사라집니다.
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| TASK_NAME | 오류를 기록한 DMS 작업명 | 여러 작업이 같은 타겟에 쓰고 있지 않은지 확인 |
| TABLE_OWNER | 대상 테이블의 스키마(소유자) | 예상한 마이그레이션 대상 스키마인지 여부 |
| TABLE_NAME | 대상 테이블명 | 특정 테이블에 편중되어 있다면 그 테이블의 기본 키 정의와 필터를 의심 |
| ERROR_TIME | 오류 발생 시각 | 풀 로드 완료 시각이나 작업 재개 시각 직후에 집중되어 있지 않은지 |
| statement_head | 실패한 문장의 앞부분 | UPDATE인지 DELETE인지, WHERE 절에 어떤 키 값이 사용되었는지 |
| error_head | 엔진이 반환한 오류 본문 | 1032 이외(1062 중복 키 등)가 섞여 있지 않은지 |
| row_key(validation 쪽) | 불일치로 판정된 행의 키 값 | 소스 쪽에서 동일한 키의 행을 조회해 실제로 어느 쪽에 존재하는지 확인 |
| FAILURE_TYPE(validation 쪽) | 불일치 종류 | 누락인지 값의 차이인지에 따라 대응이 달라짐 |
こういう状況で使います
- DMS 작업 로그에 `Error 1032` 또는 `ER_KEY_NOT_FOUND`가 반복적으로 출력됨
- CDC 단계에 들어간 직후부터 오류가 늘고, 특정 테이블만 멈춰 있음
- 작업 상태가 `Running`인데도 타겟의 행 수가 소스를 따라가지 못함
- DMS 콘솔의 테이블 통계에서 특정 테이블이 `Table error` / 일시 중지 상태임
- 검증을 활성화하니 `awsdms_validation_failures_v1`에 대량의 행이 들어감
考えられる原因(可能性の高い順)
01
풀 로드와 CDC 경계에서 대상 행이 타겟에 들어가지 않음
풀 로드 시작 시점의 스냅샷 이후에 삽입되고 이후 갱신·삭제된 행은, CDC로 갱신이 먼저 도착해도 타겟에 존재하지 않을 수 있습니다. 작업 시작 위치와 풀 로드 완료 시각의 관계를 확인하십시오.
02
소스와 타겟의 기본 키·고유 키가 일치하지 않음
타겟 쪽만 기본 키 열이 다르거나 기본 키를 재설정한 경우, DMS가 생성하는 WHERE 절이 대상 행과 일치하지 않습니다. 양쪽의 `KEY_COLUMN_USAGE`를 대조하십시오.
03
타겟 테이블에 기본 키가 없음
기본 키가 없으면 DMS는 전체 열 일치로 대상 행을 찾습니다. 부동소수점이나 문자 코드의 차이, LOB 열 처리 방식에 따라 일치하지 않아 1032가 발생합니다. CDC 대상 테이블에는 기본 키 또는 고유 키를 준비하는 것이 전제입니다.
04
선택 규칙·변환 규칙으로 행이나 열이 제외됨
테이블 매핑 필터로 일부 행만 이전하는 경우, 대상 외 행에 대한 갱신이 CDC로 도착해 타겟에 존재하지 않아 오류가 됩니다. 열 이름 변경이나 제외도 같은 영향을 줍니다.
05
타겟 쪽을 다른 프로세스가 갱신하고 있음
애플리케이션이나 다른 DMS 작업, 배치가 타겟에 쓰고 있으면 DMS가 전제하는 행 상태가 깨집니다. 이전 중인 타겟은 쓰기를 DMS로 한정하는 것이 원칙입니다.
06
binlog가 필요한 기간보다 일찍 삭제되어 변경이 누락됨
소스 쪽 binlog 보존 시간이 짧으면 CDC가 읽지 못하고, 재개 시 정합하지 않는 상태에서 적용이 시작될 수 있습니다. 보존 시간 확인은 관련 문서를 참조하십시오.
確認手順
- 1
오류의 실체를 제어 테이블로 확인하기
参照のみ`awsdms_apply_exceptions`를 시각 내림차순으로 읽어 대상 테이블·문장·키 값을 특정합니다. 조회만 하므로 안전합니다.
- 2
CloudWatch Logs에서 작업 로그 확인하기
参照のみ`dms-tasks-<복제 인스턴스명>` 로그 그룹에서 오류 전후로 무슨 일이 있었는지(재개, 테이블 일시 중지, 연결 끊김)를 확인합니다.
- 3
소스와 타겟의 기본 키 정의 대조하기
参照のみ위의 메타데이터 SQL을 양쪽에서 실행해 `pk_columns`가 일치하는지, NULL인 테이블이 없는지 확인합니다.
- 4
해당 키의 행 존재 여부를 소스·타겟 양쪽에서 확인하기
参照のみ어느 쪽에 존재하는지에 따라 누락인지 순서 문제인지가 결정됩니다.
- 5
작업의 테이블 매핑과 설정 JSON 확인하기
参照のみ`describe-replication-tasks`로 실제 설정을 가져와 필터·변환 규칙·`ErrorBehavior`의 현재 값을 확인합니다.
- 6
검증(validation)을 활성화해 불일치 범위 측정하기
中`EnableValidation`을 활성화하면 비교 부하가 소스·타겟 양쪽에 걸립니다. 부하를 감당할 수 있는 시간대에 실시하십시오.
対応方法
すぐに実施できる低リスクの対応
오류가 발생한 테이블을 특정해 분리하기
参照のみ전체를 멈추기 전에 `awsdms_apply_exceptions`로 테이블 단위로 좁힙니다. 1개 테이블뿐이라면 그 테이블의 재로드로 해결되는 경우가 많습니다.
타겟에 대한 다른 프로세스의 쓰기 중단하기
中DMS 이외의 쓰기가 있으면 설정을 바꿔도 재발합니다. 먼저 쓰기 경로를 하나로 만듭니다.
事前検討が必要な変更
해당 테이블에 기본 키 또는 고유 키 추가하기
高CDC 대상 테이블에 기본 키가 없는 것이 원인이라면, 타겟(필요하면 소스도)에 키를 정의합니다. 스키마 변경에 해당하므로 검증 환경에서의 확인과 실행 시간대 조정이 필요합니다.
해당 테이블만 재로드하기
高DMS의 "테이블 재로드" 기능으로 대상 테이블만 풀 로드를 다시 실행합니다. 대상 테이블은 일시적으로 불일치 상태를 거치므로 조회 측 영향을 확인한 뒤 실시하십시오.
테이블 매핑 필터 재검토하기
中행 필터로 일부만 이전하는 경우, CDC로 도착하는 갱신 범위와 일치시킵니다. 일치시킬 수 없다면 그 테이블은 필터 없이 이전 대상으로 합니다.
再起動・サービス影響を伴う変更
`ApplyErrorDeletePolicy`를 `IGNORE_RECORD`로 설정하기
中오류는 멈추지만, 적용하지 못한 삭제를 기록하지 않고 버리므로 데이터가 어긋납니다. 원인 조사를 마치기 전의 "임시 대응"으로는 사용하지 마십시오.
작업을 다시 만들어 CDC를 재설정하기
高풀 로드부터 다시 시작하는 경우, 타겟의 기존 데이터 처리 방식(`TargetTablePrepMode`)과 전환 시간을 먼저 결정하십시오. CDC 재설정은 영향 범위가 큰 작업입니다.
!注意事項
- `ApplyErrorDeletePolicy = IGNORE_RECORD`는 적용하지 못한 변경을 조용히 버립니다. 오류 표시는 사라지지만 소스와 타겟의 데이터가 어긋납니다. 이 설정을 적용하는 판단은 불일치를 검증으로 추적할 수 있는 상태로 만든 뒤에 하십시오.
- `TargetTablePrepMode`를 `DROP_AND_CREATE`로 설정하면 풀 로드 시 타겟 테이블이 삭제·재생성됩니다. 기존 데이터는 사라집니다.
- 검증(validation)은 소스와 타겟 양쪽에 읽기 부하를 줍니다. 운영 시간대에 갑자기 활성화하지 마십시오.
- 제어 테이블의 내용은 이전 대상 데이터의 일부(키 값이나 문장)를 포함합니다. 공유·내보내기 시 취급에 주의하십시오.
- DMS의 작업 설정 항목명은 버전에 따라 차이가 있습니다. 본 문서에 없는 항목이나 이름이 다른 항목이 있으므로 반드시 실제 작업의 JSON을 확인한 뒤 편집하십시오.
バージョン・環境による違い
これで解決しない場合に確認すること
소스 쪽 binlog 보존 시간 확인하기
보존 시간이 짧아 CDC가 읽지 못하고 있다면 설정 변경으로는 해결되지 않습니다.
DMS 복제 인스턴스의 리소스 확인하기
CPU·메모리·스토리지가 부족하면 적용 지연이나 작업 재개가 늘어 경계 문제가 발생하기 쉬워집니다.
소스 쪽 트리거나 외래 키에 의한 연쇄 갱신 확인하기
소스에서 연쇄적으로 갱신되는 행이 타겟에서는 재현되지 않는 경우가 있습니다.
1032 이외의 오류가 섞여 있지 않은지 확인하기
중복 키(1062) 등이 동시에 발생하는 경우 원인은 별개입니다.
이전 대상 테이블 목록과 애플리케이션의 쓰기 경로 대조하기
타겟에 쓰고 있는 것이 DMS뿐인지를 설계가 아니라 실제 연결원으로 확인합니다.
この文書の根拠と限界
製品の公式ドキュメントに基づく説明
MySQL 오류 코드 `1032`(`ER_KEY_NOT_FOUND`)의 정의, AWS DMS의 제어 테이블(`awsdms_apply_exceptions`, `awsdms_validation_failures_v1` 등)과 작업 설정(`ErrorBehavior`, `TargetMetadata`, `ValidationSettings`)의 공개 사양에 기반합니다. 설정 항목의 유무는 DMS 버전에 따라 달라지므로 실제 작업의 JSON 확인을 전제로 합니다. 특정 고객사의 이전 사례는 포함하지 않습니다.
よくある質問
Error 1032의 원인은 무엇입니까?
MySQL의 `ER_KEY_NOT_FOUND`로, UPDATE나 DELETE를 적용하려던 행이 타겟에 존재하지 않는다는 의미입니다. DMS의 CDC에서는 풀 로드와 CDC 경계에서의 누락, 기본 키 불일치, 기본 키가 없는 테이블, 필터에 의한 행 제외, 타겟에 대한 다른 프로세스의 쓰기가 주요 원인입니다.
Production에서 실행할 수 있습니까?
제어 테이블과 메타데이터 조회 SQL은 모두 조회 전용이므로 운영 환경에서도 실행할 수 있습니다. 작업 설정 변경은 작업의 중지·재개를 수반하고, `IGNORE_RECORD`는 데이터 불일치를 발생시키므로 영향을 확인한 뒤 실시하십시오.
어떤 권한이 필요합니까?
제어 테이블 조회는 타겟 DB의 `SELECT` 권한, 작업 설정 조회·변경은 IAM의 `dms:DescribeReplicationTasks` / `dms:ModifyReplicationTask`가 필요합니다.
ApplyErrorDeletePolicy를 IGNORE_RECORD로 설정하면 해결됩니까?
오류는 멈추지만 해결은 아닙니다. 적용하지 못한 삭제를 버리기 때문에 소스와 타겟의 데이터가 어긋납니다. 원인을 특정한 뒤 불일치를 허용할 수 있는지 판단하고 나서 설정하십시오.
결과를 어떻게 판단합니까?
`awsdms_apply_exceptions`의 오류가 특정 테이블에 편중되어 있다면 그 테이블의 기본 키 정의와 매핑을 의심합니다. 전체 테이블에 분산되어 있고 시각이 작업 재개에 집중되어 있다면 CDC 시작 위치나 binlog 누락을 의심합니다. 소스 쪽에만 행이 존재한다면 풀 로드 누락입니다.
기본 키가 없는 테이블은 어떻게 해야 합니까?
CDC 대상으로 삼으려면 기본 키 또는 고유 키를 준비하는 것이 원칙입니다. 준비할 수 없다면 그 테이블만 풀 로드를 반복해 동기화하거나, 이전 대상에서 제외하고 다른 방법으로 처리하는 등의 설계 변경을 검토하십시오.
この文書がカバーする質問
- DMS의 CDC에서 UPDATE가 적용되지 않고 작업이 멈춤
- awsdms_apply_exceptions 읽는 방법을 알고 싶다
- 기본 키가 없는 테이블을 DMS로 CDC 이전할 수 있는가
- DMS의 검증(validation)에서 불일치가 발생했을 때 조사 방법
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
Error 1032 한 건을 추적하는 것만이라면 제어 테이블을 읽는 것으로 충분합니다. 운영상 어려운 점은 이전 기간 내내 작업 상태와 불일치 여부를 계속 지켜봐야 한다는 것입니다. GIIP에서는 DMS 작업 상태·오류 건수·검증 결과의 추이를 정기적으로 수집하고, 오류가 발생한 시점의 제어 테이블 내용을 함께 보존하고 있습니다. 원인 파악과 1차 보고까지는 AI 에이전트가 수행하며, `IGNORE_RECORD`처럼 데이터 불일치를 수반하는 판단이 필요한 상황에서는 반드시 사람의 승인을 거치는 운영 방식을 취하고 있습니다.
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
Aurora MySQL에서 binlog 보존 시간을 확인·설정하는 방법
binlog 보존 시간은 `mysql.rds_show_configuration`으로 확인하고 `mysql.rds_set_configuration`에 시간 단위로 설정합니다. binlog_format은 클러스터 파라미터이며 변경에는 재시작이 필요합니다.
database-migration3TB 규모 데이터베이스를 마이그레이션할 때 계획을 세우는 방법
3TB급 마이그레이션 계획은 크기 실측, 전환 방식 선택, 시험 실행을 통한 소요 시간 실측, 검증과 롤백 설계의 순서로 구성합니다. 기준값이 아니라 실측값으로 일정을 잡기 위한 절차입니다.
sql-serverSQL Server의 CDC에서 로그 스캔이 멈추지 않았는지 확인하는 방법
sys.dm_cdc_log_scan_sessions와 cdc.lsn_time_mapping, 캡처 작업의 상태로부터 CDC의 로그 스캔이 진행되고 있는지 확인하는 절차입니다.
tidbTiDB에서 Aurora MySQL로 마이그레이션할 때 확인할 항목
TiDB는 MySQL과 호환되지만 동일하지 않습니다. 기본 키·번호 부여·트랜잭션·통계·용량의 각 차이를 확인용 SQL과 함께 마이그레이션 전 체크리스트로 정리합니다.
関連サービス
DMS 작업 오류 조사를 요청하기
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
DMS 작업 오류 조사를 요청하기