Amazon RDS for MySQL을 사용하여 긴 복제 지연 문제를 해결하려면 어떻게 해야 합니까?

최종 업데이트 날짜: 2020년 8월 21일

Amazon Relational Database Service(Amazon RDS) for MySQL을 사용할 때 복제 지연의 원인을 어떻게 찾을 수 있습니까?

간략한 설명

Amazon RDS for MySQL은 비동기 복제를 사용하며 복제본이 기본 DB 인스턴스를 따라갈 수 없는 경우가 있습니다. 이로 인해 복제 지연이 발생할 수 있습니다.

이진 로그 파일 위치 기반 복제와 함께 Amazon RDS for MySQL 읽기 전용 복제본을 사용하는 경우, Amazon RDS ReplicaLag 지표를 보고 Amazon CloudWatch의 복제 지연을 모니터링 할 수 있습니다. ReplicaLag 지표는 SHOW SLAVE STATUS 명령의 Seconds_Behind_Master 필드 값을 보고합니다.

Seconds_Behind_Master는 복제본 DB 인스턴스의 현재 타임스탬프와 복제본 DB 인스턴스에서 처리 중인 이벤트의 기본 DB 인스턴스에 기록된 원본 타임스탬프의 차이를 보여줍니다.

MySQL 복제는 Binlog Dump 스레드, IO_THREADSQL_THREAD의 세 가지 스레드로 작동합니다. 이러한 스레드가 작동하는 방식에 대한 자세한 내용은 MySQL 설명서의 Replication Implementation Details를 참조하십시오. 복제가 지연되면 우선 해당 지연이 복제본 IO_THREAD 또는 복제본 SQL_THREAD에 의해 발생하는지 확인하십시오. 그러면 지연의 근본 원인을 파악할 수 있습니다.

해결 방법

지연되는 복제 스레드를 식별하려면 다음 예제를 참조하십시오.

1.    기본 DB 인스턴스에서 MASTER STATUS 명령을 실행하고 출력을 검토합니다.

mysql> SHOW MASTER STATUS;
+----------------------------+----------+--------------+------------------+-------------------+
| File                       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.066552|      521 |              |                  |                   |
+----------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

참고: 예제 출력에서 마스터 DB 인스턴스는 mysql-bin.066552 파일에 이진 로그를 작성합니다.

2.    복제본 DB 인스턴스에서 SHOW SLAVE STATUS 명령을 실행하고 출력을 검토합니다.

예제 출력 A:

mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Master_Log_File: mysql-bin.066548
Read_Master_Log_Pos: 10050480
Relay_Master_Log_File: mysql-bin.066548
Exec_Master_Log_Pos: 10050300
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

예제 출력 A에서 Master_Log_File: mysql-bin.066548은 복제본 IO_THREAD가 이진 로그 파일 mysql-bin.066548에서 읽고 있음을 나타냅니다. 이는 기본 DB 인스턴스가 mysql-bin.066552 파일에 이진 로그를 작성하고 있기 때문입니다. 이 출력은 복제본 IO_THREAD4개의 binlog 뒤에 있음을 나타냅니다. 그러나 Relay_Master_Log_Filemysql-bin.066548이며, 이는 복제본 SQL_THREADIO_THREAD와 동일한 파일에서 읽고 있음을 나타냅니다. 즉, 복제본 SQL_THREAD는 속도를 따라가지만, 복제본 IO_THREAD는 뒤처지고 있음을 의미합니다.

예제 출력 B:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Master_Log_File: mysql-bin.066552
Read_Master_Log_Pos: 430
Relay_Master_Log_File: mysql-bin.066530
Exec_Master_Log_Pos: 50360
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

예제 출력 B는 마스터 로그 파일이 mysql-bin-changelog.066552임을 보여 줍니다. 이는 마스터 상태의 파일 파라미터이기도 합니다. 이는 IO_THREAD가 기본 DB 인스턴스를 따라가며 있음을 의미합니다. 복제본 출력에서 SQL 스레드는 Relay_Master_Log_File: mysql-bin-changelog.066530을 수행 중입니다. 이것은 SQL_THREAD12개의 이진 로그만큼 뒤처져 있음을 의미합니다.

IO_THREAD는 마스터에서만 이진 로그를 읽으므로 일반적으로 IO_THREAD는 대규모의 복제 지연을 발생시키지 않습니다. 그러나 네트워크 연결 및 네트워크 지연 시간은 서버 간 읽기 속도에 영향을 미칠 수 있습니다. 복제본 IO_THREAD는 높은 대역폭 사용량 때문에 속도가 느려질 수 있습니다.

복제본 SQL_THREAD가 복제 지연의 원인인 경우 지연은 다음과 같은 이유로 발생할 수 있습니다.

  • 기본 DB 인스턴스에 대한 장기 실행 쿼리
  • DB 인스턴스 클래스 크기 또는 스토리지 부족
  • 기본 DB 인스턴스에서 실행된 병렬 쿼리
  • 복제본 DB 인스턴스의 디스크에 동기화된 이진 로그
  • 복제본의 Binlog_format을 ROW로 설정
  • 복제본 생성 지연

기본 인스턴스에 대한 장기 실행 쿼리

복제본 DB 인스턴스에서 실행하는 데 동일한 시간이 걸리는 기본 DB 인스턴스에 대한 장기 실행 쿼리는 seconds_behind_master를 늘릴 수 있습니다. 예를 들어, 기본 DB 인스턴스에 변경을 시작하는 데 1시간이 걸리면 변경 사항이 복제본에서 실행을 시작할 때 지연은 이미 1시간입니다. 변경 사항이 복제본에서 완료되는 데에도 1시간이 걸릴 수 있으므로 변경이 완료될 때까지의 전체 지연은 약 2시간이 됩니다. 이것은 예상된 지연이지만, 마스터에서 느린 쿼리 로그를 모니터링하여 이 지연을 최소화할 수 있습니다. 또한 장기 실행 명령문을 식별하여 지연을 줄일 수도 있습니다. 그런 다음 장기 실행 명령문을 작은 문이나 트랜잭션으로 분할합니다. 자세한 내용은 MySQL 느린 쿼리 및 일반 로그 액세스를 참조하십시오.

DB 인스턴스 클래스 크기 또는 스토리지 부족

복제본 DB 인스턴스 클래스 또는 스토리지 구성이 기본 인스턴스보다 작으면 복제본이 제한되어 기본 인스턴스의 변경 내용을 따라갈 수 없습니다. 해당 복제본의 DB 인스턴스 유형이 기본 DB 인스턴스와 같거나 이보다 상위인지 확인하십시오. 복제가 효과적으로 작동하려면 각 읽기 전용 복제본에 소스 DB 인스턴스와 동일한 양의 컴퓨팅 및 스토리지 리소스가 필요합니다. 자세한 내용은 DB 인스턴스 클래스를 참조하십시오.

기본 DB 인스턴스에서 실행된 병렬 쿼리

기본 인스턴스에서 쿼리를 병렬로 실행하면 복제본에서 순차적으로 커밋됩니다. 이는 MySQL 복제가 기본적으로 단일 스레드(SQL_THREAD) 방식이기 때문입니다. 소스 DB 인스턴스에 많은 양의 쓰기가 병렬로 발생하는 경우, 읽기 전용 복제본에 대한 쓰기가 단일 SQL_THREAD를 사용하여 직렬화됩니다. 이로 인해 소스 DB 인스턴스와 읽기 전용 복제본 간에 지연이 발생할 수 있습니다.

다중 스레드(병렬) 복제는 MySQL 5.6, MySQL 5.7 및 상위 버전에서 사용할 수 있습니다. 다중 스레드 복제에 대한 자세한 내용은 MySQL 설명서의 Binary Logging Options and Variables를 참조하십시오.

다중 스레드 복제는 복제 간의 차이를 발생시킬 수 있습니다. 예를 들어, 복제 오류를 건너뛸 때는 다중 스레드 복제를 권장하지 않습니다. 건너뛰는 트랜잭션을 식별하기가 어렵기 때문입니다. 이로 인해 기본 DB 인스턴스와 복제본 DB 인스턴스 간의 데이터 일관성이 떨어질 수 있습니다.

복제본 DB 인스턴스의 디스크에 동기화된 이진 로그

복제본에 자동 백업을 활성화한 경우, 이진 로그를 복제본의 디스크에 동기화하려면 추가 작업이 필요할 수 있습니다. 파라미터 sync_binlog의 기본값이 1로 설정됩니다. 이 값을 0으로 변경한 경우에는 MySQL 서버가 이진 로그를 디스크에 동기화하는 것도 비활성화합니다. OS(운영 체제)는 디스크에 로깅하는 대신 이진 로그를 디스크에 수시로 플러시합니다.

이진 로그 동기화를 비활성화하면 매번 커밋할 때마다 이진 로그를 디스크에 동기화하는 데 필요한 성능 오버헤드를 줄일 수 있습니다. 그러나 정전 또는 OS 충돌이 발생하면 커밋 중 일부가 이진 로그와 동기화되지 않을 수 있습니다. 이는 PITR(특정 시점 복원) 기능에 영향을 미칠 수 있습니다. 자세한 내용은 MySQL 설명서의 sync_binlog를 참조하십시오.

복제본의 Binlog_format을 ROW로 설정

복제본의 binlog_formatROW로 설정하고 업데이트가 이루어진 테이블에 기본 키가 누락된 경우 기본적으로 slave-rows-search-algorithms=TABLE_SCAN,INDEX_SCAN이 기본에서 수정된 모든 행에서 실행됩니다. 또한 이 파라미터는 복제본에 대한 전체 테이블 스캔을 수행합니다. 이 경우 단기적인 솔루션은 검색 알고리즘을 INDEX_SCAN,HASH_SCAN으로 변경하여 전체 테이블 스캔의 오버헤드를 줄이는 것입니다. 영구적인 솔루션을 원하는 경우, 각 테이블에 명시적 기본 키를 추가합니다.

slave-rows-search-algorithms 파라미터에 대한 자세한 내용은 MySQL 설명서의 slave-rows-search-algorithms를 참조하십시오.

복제본 생성 지연

Amazon RDS는 마스터의 DB 스냅샷을 작성하여 MySQL 마스터의 읽기 전용 복제본을 만듭니다. 그런 다음, Amazon RDS는 스냅샷을 복원하여 새로운 DB 인스턴스(복제본)를 생성하고 둘 사이의 복제를 설정합니다.

Amazon RDS가 새로운 읽기 전용 복제본을 생성하는 데 시간이 걸립니다. 복제가 설정되면 기본 백업을 생성하는 데 걸리는 시간 동안 지연이 발생합니다. 이러한 지연을 최소화하기 위해 복제본 생성을 호출하기 전에 수동 백업을 생성합니다. 그러면 복제본 생성 프로세스에서 수행한 스냅샷은 증분 백업이므로 더 빠릅니다.

읽기 전용 복제본을 스냅샷에서 복원하면 복제본은 모든 데이터가 Amazon S3(Amazon Simple Storage Service)에서 복제본 DB 인스턴스와 연결된 Amazon EBS(Amazon Elastic Block Store) 볼륨으로 전송될 때까지 기다리지 않습니다. DB 작업을 수행하는 데 복제본 DB 인스턴스를 사용할 수 있으며 기존 Amazon EBS 스냅샷에서 생성된 새 볼륨은 백그라운드에서 로드됩니다(느린 로딩).

Amazon RDS for MySQL 복제본(EBS 기반 볼륨)의 경우, 로딩 효과가 복제 성능에 영향을 미칠 수 있으므로 처음에는 복제 지연이 증가할 수 있습니다. 자세한 내용은 Amazon EBS 볼륨 초기화를 참조하십시오.

마스터 DB 인스턴스 버퍼 풀의 현재 상태를 저장한 다음 복원된 읽기 전용 복제본에 버퍼 풀을 다시 로드하여 성능 향상을 제공할 수 있도록 InnoDB 캐시 워밍 기능을 활성화하는 것을 고려해 보십시오. InnoDB 캐시 워밍에 대한 자세한 내용은 Amazon RDS의 MySQL을 참조하십시오.


이 문서가 도움이 되었습니까?


결제 또는 기술 지원이 필요합니까?