

# 누락된 레코드로 인한 복제 실패 문제 해결
<a name="USER_ReadRepl.Troubleshooting.MissingRecords"></a>

이진 로그 복제와 함께 Amazon RDS for MySQL 또는 MariaDB를 사용하는 경우 읽기 복제본의 레코드 누락으로 인해 프로세스가 중지되는 복제 실패가 발생할 수 있습니다. 이 섹션에서는 이러한 문제를 진단하고 해결하는 방법을 설명합니다.

## 일반적인 원인
<a name="USER_ReadRepl.Troubleshooting.MissingRecords.Causes"></a>

소스와 복제본 간의 데이터 불일치는 다음 시나리오 중 하나로 인해 발생할 수 있습니다.
+ 복제본의 수동 데이터 수정
+ `sql_replica_skip_counter`를 사용하여 건너뛴 트랜잭션(MySQL 8.0.26 이전의 `sql_slave_skip_counter`)
+ 마이그레이션 도구를 사용한 초기 데이터 동기화 중에 복제본의 행 누락

## 문제 식별
<a name="USER_ReadRepl.Troubleshooting.MissingRecords.Identifying"></a>

이 문제의 일반적인 지표는 메시지 `Can't find record`가 포함된 `Error 1032`입니다. 복제본의 오류 로그에 다음 오류 메시지가 나타납니다.

```
2025-11-04T21:24:11.038899Z 566 [ERROR] [MY-010584] [Repl] Replica SQL for channel '': 
Worker 1 failed executing transaction 'ANONYMOUS' at source log 
mysql-bin-changelog.031523, end_log_pos 899; Could not execute Update_rows event on 
table test_replication.users; Can't find record in 'users', Error_code: 1032; handler 
error HA_ERR_KEY_NOT_FOUND; the event's source log mysql-bin-changelog.031523, 
end_log_pos 899, Error_code: MY-001032
```

**참고**  
오류 로그 형식은 MySQL 엔진과 MariaDB 엔진에 따라 다릅니다. 로그를 검색하는 방법에 대한 자세한 내용은 [데이터베이스 로그 파일 보기 및 나열](USER_LogAccess.Procedural.Viewing.md) 섹션을 참조하세요.

## 문제 진단
<a name="USER_ReadRepl.Troubleshooting.MissingRecords.Diagnosing"></a>

복제 실패를 진단하려면:
+ 복제본 오류 로그를 검토하여 복제가 중지된 위치를 식별합니다. `MY-010584`를 검색 키워드로 사용할 수 있습니다.
+ 복제본에서 `SHOW REPLICA STATUS\G`(MySQL 8.0.22 이전의 `SHOW SLAVE STATUS\G`)를 실행하고 `Last_Error` 열을 검토합니다.

  ```
  Last_Error: Coordinator stopped because there were error(s) in the worker(s). 
  The most recent failure being: Worker 1 failed executing transaction 'ANONYMOUS' 
  at source log mysql-bin-changelog.031523, end_log_pos 899. See error log and/or 
  performance_schema.replication_applier_status_by_worker table for more details 
  about this failure or others, if any.
  ```
+ 복제본 인스턴스에서 복제 프로세스가 중지된 바이너리 로그 파일 이름과 위치를 확인합니다. 이 정보는 복제본 인스턴스의 오류 로그에서 찾을 수 있습니다.

## 바이너리 로그 분석
<a name="USER_ReadRepl.Troubleshooting.MissingRecords.BinlogAnalysis"></a>

특정 트랜잭션에서 복제 실패를 조사하려면 [`mysqlbinlog`](https://dev.mysql.com/doc/refman/en/mysqlbinlog.html) 유틸리티를 사용하여 이진 로그 파일을 검사할 수 있습니다. 예를 들어 이진 로그 파일 `mysql-bin-changelog.031523`에 있는 `end_log_pos` 위치 `899`에서 복제가 실패한 경우 이 특정 위치를 분석하여 실패 원인을 식별할 수 있습니다.

**참고**  
`end_log_pos` 값은 실패 이벤트의 종료 위치를 나타냅니다. 디코딩된 이진 로그 출력에서 `end_log_pos`가 이 값과 일치하는 이벤트를 찾습니다.

`mysqlbinlog` 유틸리티를 사용하여 관련 바이너리 로그를 다운로드하고 검사합니다. 기본 인스턴스의 엔드포인트를 사용하세요.

```
$ mysqlbinlog --read-from-remote-server \
--host=<rds-endpoint> \
--port=3306 \
--user=<username> \
--password=<password> \
--base64-output=DECODE-ROWS -vv \
mysql-bin-changelog.031523 > decoded-binlog-file-name
```

**참고**  
`mysqlbinlog` 유틸리티는 바이너리 로그 콘텐츠를 읽고 해석하는 데 도움이 되는 기본 MySQL 도구입니다. Amazon RDS에서 바이너리 로그에 액세스하는 방법에 대한 자세한 내용은 [MySQL 이진 로그 액세스](USER_LogAccess.MySQL.Binarylog.md) 섹션을 참조하세요.

라이터 인스턴스의 바이너리 로그는 라이터 인스턴스가 `test_replication.users` 테이블에서 `id=1`로 레코드를 업데이트하려고 시도했음을 보여 줍니다.

```
#251104 21:13:13 server id 680788197  end_log_pos 899 CRC32 0x89b1e255     Update_rows: table id 101 flags: STMT_END_F
### UPDATE `test_replication`.`users`
### WHERE
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='Test User' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @3='updated4@example.com' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @4=1762288260 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
### SET
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='Test User' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @3='updated5@example.com' /* VARSTRING(400) meta=400 nullable=1 is_null=0 */
###   @4=1762288260 /* TIMESTAMP(0) meta=0 nullable=1 is_null=0 */
# at 899
```

복제본의 오류 로그는 대상 레코드가 존재하지 않기 때문에 복제본이 `UPDATE` 문을 실행할 수 없음을 보여 줍니다.

```
Can't find record in 'users', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND
```

행이 누락되었는지 확인하려면 복제본에 특정 행이 있는지 확인합니다.

```
SELECT 1 FROM test_replication.users WHERE id=1;
Empty set (0.00 sec)
```

이 출력은 대상 행이 복제본에 존재하지 않기 때문에 소스 DB 인스턴스의 `UPDATE` 작업이 복제에 실패했음을 확인합니다.

## 복제 실패 방지
<a name="USER_ReadRepl.Troubleshooting.MissingRecords.Prevention"></a>

복제 불일치를 방지하려면 다음 모범 사례를 따르는 것이 좋습니다.
+ GTID 기반 복제를 사용합니다. 자세한 내용은 [GTID 기반 복제 사용](mysql-replication-gtid.md) 섹션을 참조하세요.
+ 기본 인스턴스에서 `binlog_format`을 `ROW`로 사용합니다. `binlog_format`을 `MIXED`로 사용하면 복제 시 불일치를 자동으로 숨길 수 있습니다.
+ 의도하지 않은 행 수정을 방지하기 위해 복제본 인스턴스에서 `read_only`를 `1`로 구성합니다.
+ 복제본 인스턴스에서 `innodb_flush_log_at_trx_commit`을 `1`로 설정합니다.
+ 기본 인스턴스에서 `sync_binlog`를 `1`로 설정합니다.
+ 기본 복제본과 복제본 간의 테이블 스키마 패리티를 확인합니다.
+ 복제된 테이블에 프라이머리 키가 있는지 확인합니다.