Amazon Aurora MySQL에서 지연 복제 구성
Aurora MySQL에서 지연 복제를 재해 복구를 위한 전략으로 사용할 수 있습니다. 지연된 복제를 사용하여 원본에서 읽기 전용 복제본으로의 복제를 지연할 최소 시간(초)을 지정합니다. 재해 발생 시(예: 실수로 테이블 삭제) 다음 단계를 완료하여 재해로부터 빠르게 복구할 수 있습니다.
-
소스가 재해를 초래한 변경 사항을 전송하기 이전에 읽기 복제본으로의 복제를 중지합니다. mysql.rds_stop_replication 저장 프로시저를 사용하여 복제를 중지합니다.
-
복제를 시작하고 로그 파일 위치에서 복제가 자동으로 중지되도록 지정합니다. mysql.rds_start_replication_until(Aurora MySQL 버전 3) 저장 프로시저를 사용하여 재해 직전 위치를 지정합니다.
-
Aurora MySQL의 읽기 전용 복제본을 DB 클러스터로 승격의 지침에 따라 읽기 복제본을 새 소스 DB 클러스터로 승격합니다.
참고
Aurora MySQL은 버전 8.4.8 이상에서 지연 복제를 지원합니다.
-
저장 프로시저를 사용하여 지연된 복제를 구성합니다. AWS Management Console, AWS CLI 또는 Amazon RDS API를 사용하여 지연 복제를 구성할 수 없습니다.
-
Aurora MySQL 버전 8.4.8 이상의 지연 복제 구성에서 글로벌 트랜잭션 식별자(GTID)를 기반으로 하는 복제를 사용할 수 있습니다.
-
GTID 기반 복제를 사용하는 경우 mysql.rds_start_replication_until_gtid(Aurora MySQL 버전 3) 저장 프로시저 대신 mysql.rds_start_replication_until(Aurora MySQL 버전 3) 저장 프로시저를 사용하십시오.
-
Aurora MySQL은 최대 15개 채널로 다중 소스 복제를 지원합니다.
_for_channel프로시저 변형을 사용하여 특정 채널에서 지연 복제를 구성합니다.
지연 복제 사용 사례
Aurora MySQL의 지연 복제는 바이너리 로그 기반 복제에 적용됩니다. 여기에는 Aurora MySQL 라이터 DB 클러스터에서 binlog 복제본으로의 복제, 외부 MySQL 소스에서 Aurora MySQL DB 클러스터로의 복제 또는 다중 소스 복제 채널 간 복제가 포함됩니다. 바이너리 로그가 아닌 공유 클러스터 스토리지에서 읽기 때문에 단일 DB 클러스터 내의 Aurora 복제본에는 지연 복제가 적용되지 않습니다. 일반적인 사용 사례는 다음과 같습니다.
-
운영자 오류로 인한 재해 복구 – 소스보다 설정된 간격만큼 지연되는 binlog 복제본을 유지합니다. 의도치 않게 파괴적인 명령문이 실행되는 경우(예: 테이블 삭제) 소스가 변경 사항을 적용하기 전에 지연된 복제본에서 복제를 중지합니다. 그런 다음 mysql.rds_start_replication_until(Aurora MySQL 버전 3) 또는 mysql.rds_start_replication_until_gtid(Aurora MySQL 버전 3)를 사용하여 이벤트 직전으로 롤포워드합니다. 마지막으로 복제본을 승격합니다. 이 접근 방식은 충돌 복구 및 바이너리 로그 재생이 필요한 특정 시점 복구보다 더 빠른 복구 경로를 제공합니다.
-
논리적 데이터 손상 방지 - 지연된 복제본은 데이터를 점진적으로 손상시키는 잘못된 애플리케이션 배포 또는 마이그레이션도 방지합니다. 복제본은 지연 기간 동안 손상 전 상태를 유지하므로 잘못된 트랜잭션이 적용되기 전에 복구할 수 있습니다.
-
메이저 버전 및 블루/그린 업그레이드 - 업그레이드 또는 블루/그린 배포 중에 안전망으로 지연된 binlog 복제본을 유지하여 업그레이드에 문제가 발생할 경우 정상 상태로 돌아갈 수 있습니다.
-
외부 소스에서 변경 데이터 캡처(CDC) - 외부 MySQL 소스에서 Aurora MySQL DB 클러스터로 변경 사항을 수집할 때 의도적인 지연으로 인해 변경 사항이 다운스트림에 적용되기 전에 제어 가능한 버퍼가 확보됩니다.
-
복원 없이 과거 상태 확인 - 지연된 복제본을 쿼리하여 이전 시점의 데이터 상태를 확인합니다. 이는 클론을 프로비저닝하거나 특정 시점 복원을 실행하지 않고 변경된 사항을 디버깅하거나 감사하거나 조사하는 데 유용합니다.
-
복제 지연 시 애플리케이션 동작 테스트 – 인위적으로 지연 시간을 늘려 복제본에 지연이 발생할 때 애플리케이션이 어떻게 동작하는지 검증하고, 지연을 재현하기 위해 높은 부하를 생성할 필요 없이 지연에 민감한 조건에 대한 회귀 테스트를 실행합니다.
지연을 사용하여 외부 복제 구성
지연 복제로 외부 소스를 구성하려면 mysql.rds_set_external_source_with_delay(Aurora MySQL 버전 8.4.8 이상) 저장 프로시저를 사용합니다. 모든 복제 저장 프로시저에 대한 자세한 내용은 이진수 로그(binlog) 복제 구성, 시작 및 중지 섹션을 참조하세요.
예제(기본 채널):
CALL mysql.rds_set_external_source_with_delay( 'source-host.example.com', 3306, 'repl_user', 'repl_password', 'mysql-bin-changelog.000001', 120, 0, 3600);
예제(특정 채널):
CALL mysql.rds_set_external_source_with_delay_for_channel( 'source-host.example.com', 3306, 'repl_user', 'repl_password', 'mysql-bin-changelog.000001', 120, 0, 3600, 'channel_1');
파라미터:
host_name-
외부 소스의 호스트 이름 또는 IP 주소입니다.
host_port-
외부 소스의 포트 번호입니다.
replication_user_name-
외부 소스의 복제 사용자입니다.
replication_user_password-
복제 사용자의 암호입니다.
mysql_binary_log_file_name-
외부 소스에 있는 바이너리 로그 파일의 이름입니다.
mysql_binary_log_file_location-
복제를 시작할 바이너리 로그 파일 내의 위치입니다.
ssl_encryption-
이 파라미터를
1로 설정하여 복제 연결에 대해 SSL 암호화를 활성화하거나0으로 설정하여 SSL 암호화를 비활성화합니다. delay-
초 단위의 최소 지연 시간(0~259,200)입니다.
채널-
(for_channel 변형만 해당) 다중 소스 복제의 채널 이름입니다.
제약 조건:
-
Aurora MySQL은 최대 15개의 복제 채널을 지원합니다.
-
각 채널은 서로 다른 소스(호스트:포트 조합)에서 복제해야 합니다.
-
지연은 0~259,200초(72시간) 범위여야 합니다.
-
채널 구성을 수정하기 전에 복제를 중지합니다.
기존 읽기 복제본에 대한 지연 복제 수정
기존 읽기 전용 복제본에 대한 지연된 복제를 수정하려면 mysql.rds_set_source_delay(Aurora MySQL 버전 8.4.8 이상) 저장 프로시저를 실행합니다. 모든 복제 저장 프로시저에 대한 자세한 내용은 이진수 로그(binlog) 복제 구성, 시작 및 중지 섹션을 참조하세요.
기존 읽기 복제본에 대한 지연된 복제를 수정하려면:
-
MySQL 클라이언트를 사용하여 관리 사용자로 읽기 복제본에 연결합니다.
-
mysql.rds_stop_replication 저장 프로시저를 사용하여 복제를 중지합니다.
-
mysql.rds_set_source_delay(Aurora MySQL 버전 8.4.8 이상) 저장 프로시저를 실행합니다.
-
mysql.rds_start_replication 저장 프로시저를 사용하여 복제를 시작합니다.
예제(기본 채널):
CALL mysql.rds_set_source_delay(3600);
예제(특정 채널):
CALL mysql.rds_set_source_delay_for_channel(3600, 'channel_1');
이 예제에서는 읽기 복제본으로의 복제를 1시간(3,600초) 이상 지연하도록 지정합니다. 지연 값은 0~259,200초(72시간) 범위여야 합니다.
참고
지연을 설정하기 전에 복제를 중지합니다. 복제가 실행 중인 경우 먼저 mysql.rds_stop_replication(또는 특정 채널의 경우 mysql.rds_stop_replication_for_channel)을 직접적으로 호출하라는 오류가 발생합니다.
읽기 복제본에 대한 복제를 중지할 위치 설정
읽기 전용 복제본에 대한 복제를 중단한 이후에 mysql.rds_start_replication_until(Aurora MySQL 버전 3) 저장 프로시저를 사용하여 복제를 시작한 다음 지정된 이진 로그 파일 위치에서 복제를 중지할 수 있습니다.
복제를 시작하고 특정 위치에서 중지하려면:
-
MySQL 클라이언트를 사용하여 관리 사용자로 읽기 복제본에 연결합니다.
-
mysql.rds_start_replication_until(Aurora MySQL 버전 3) 저장 프로시저를 실행합니다.
예제:
CALL mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120);
이 예제에서는 복제를 시작하고 mysql-bin-changelog.000777 바이너리 로그 파일의 위치 120에 도달할 때까지 변경 사항을 복제합니다. 재해 복구 시나리오에서 이 위치 120을 재해 직전이라고 가정합니다.
Aurora MySQL이 중지 지점에 도달하면 복제가 자동으로 중지됩니다. Aurora MySQL은 다음 이벤트를 생성합니다. Replication has been stopped since the replica reached the stop point specified by the
rds_start_replication_until stored procedure.
GTID 기반 복제를 사용하는 경우 mysql.rds_start_replication_until_gtid(Aurora MySQL 버전 3) 저장 프로시저를 대신 사용하십시오.
읽기 복제본 승격
복제가 중지된 후 재해 복구 시나리오에서 읽기 복제본을 새 원본 DB 클러스터로 승격할 수 있습니다. 읽기 전용 복제본 승격에 대한 자세한 내용은 Aurora MySQL의 읽기 전용 복제본을 DB 클러스터로 승격 단원을 참조하십시오.
관련 주제
-
모든 복제 저장 프로시저에 대한 전체 참조는 이진수 로그(binlog) 복제 구성, 시작 및 중지 섹션을 참조하세요.