View a markdown version of this page

누락된 레코드로 인한 복제 실패 문제 해결 - Amazon Relational Database Service
일반적인 원인문제 식별문제 진단바이너리 로그 분석복제 실패 방지

누락된 레코드로 인한 복제 실패 문제 해결

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

일반적인 원인

소스와 복제본 간의 데이터 불일치는 다음 시나리오 중 하나로 인해 발생할 수 있습니다.

  • 복제본의 수동 데이터 수정

  • sql_replica_skip_counter를 사용하여 건너뛴 트랜잭션(MySQL 8.0.26 이전의 sql_slave_skip_counter)

  • 마이그레이션 도구를 사용한 초기 데이터 동기화 중에 복제본의 행 누락

문제 식별

이 문제의 일반적인 지표는 메시지 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 엔진에 따라 다릅니다. 로그를 검색하는 방법에 대한 자세한 내용은 데이터베이스 로그 파일 보기 및 나열 섹션을 참조하세요.

문제 진단

복제 실패를 진단하려면:

  • 복제본 오류 로그를 검토하여 복제가 중지된 위치를 식별합니다. 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.

  • 복제본 인스턴스에서 복제 프로세스가 중지된 바이너리 로그 파일 이름과 위치를 확인합니다. 이 정보는 복제본 인스턴스의 오류 로그에서 찾을 수 있습니다.

바이너리 로그 분석

특정 트랜잭션에서 복제 실패를 조사하려면 mysqlbinlog 유틸리티를 사용하여 이진 로그 파일을 검사할 수 있습니다. 예를 들어 이진 로그 파일 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 이진 로그 액세스 섹션을 참조하세요.

라이터 인스턴스의 바이너리 로그는 라이터 인스턴스가 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 작업이 복제에 실패했음을 확인합니다.

복제 실패 방지

복제 불일치를 방지하려면 다음 모범 사례를 따르는 것이 좋습니다.

  • GTID 기반 복제를 사용합니다. 자세한 내용은 GTID 기반 복제 사용 섹션을 참조하세요.

  • 기본 인스턴스에서 binlog_format을 ROW로 사용합니다. binlog_format을 MIXED로 사용하면 복제 시 불일치를 자동으로 숨길 수 있습니다.

  • 의도하지 않은 행 수정을 방지하기 위해 복제본 인스턴스에서 read_only를 1로 구성합니다.

  • 복제본 인스턴스에서 innodb_flush_log_at_trx_commit을 1로 설정합니다.

  • 기본 인스턴스에서 sync_binlog를 1로 설정합니다.

  • 기본 복제본과 복제본 간의 테이블 스키마 패리티를 확인합니다.

  • 복제된 테이블에 프라이머리 키가 있는지 확인합니다.