19.4.11 Delayed Replication

19.4.11 Delayed Replication

MySQL은 레플리카 서버가 소스보다 의도적으로 최소 지정한 시간만큼 늦게 트랜잭션을 실행하도록 하는 지연 복제를 지원합니다. 이 섹션에서는 레플리카에서 복제 지연을 구성하는 방법과 복제 지연을 모니터링하는 방법을 설명합니다.

MySQL 9.5에서 복제를 지연시키는 방법은 두 개의 타임스탬프인 immediate_commit_timestamp와 original_commit_timestamp에 따라 달라집니다(참조: Replication Delay Timestamps). 지연 복제는 이 타임스탬프들을 사용하여 측정됩니다. 즉시 소스 또는 레플리카 중 하나라도 이 타임스탬프들을 사용하지 않는 경우, MySQL 5.7의 지연 복제 구현이 사용됩니다(참조: Delayed Replication). 이 섹션에서는 이 타임스탬프들을 모두 사용하는 서버 간의 지연 복제에 대해 설명합니다.

기본 복제 지연은 0초입니다. CHANGE REPLICATION SOURCE TO SOURCE_DELAY=N 문을 사용하여 지연을 _N_초로 설정합니다. 소스로부터 수신한 트랜잭션은 즉시 소스에서 커밋된 시점보다 최소 _N_초가 지난 후에야 실행됩니다. 지연은 트랜잭션 단위(이전 MySQL 버전처럼 이벤트 단위가 아님)로 발생하며, 실제 지연은 gtid_log_event 또는 anonymous_gtid_log_event에만 부과됩니다. 트랜잭션의 다른 이벤트들은 이 이벤트들을 따라가면서 추가적인 대기 시간을 부과받지 않습니다.

참고

START REPLICA와 STOP REPLICA는 지연을 무시하고 즉시 효과를 발휘합니다. RESET REPLICA는 지연을 0으로 재설정합니다.

replication_applier_configuration Performance Schema 테이블에는 DESIRED_DELAY 컬럼이 포함되어 있으며, 여기에는 SOURCE_DELAY 옵션을 사용하여 구성한 지연이 표시됩니다. replication_applier_status Performance Schema 테이블에는 REMAINING_DELAY 컬럼이 포함되어 있으며, 여기에는 남아 있는 지연 초 수가 표시됩니다.

지연 복제는 다음과 같은 여러 목적에 사용할 수 있습니다:

• 소스에서의 사용자 실수로부터 보호하기 위해. 지연을 사용하면 실수가 발생하기 직전 시점으로 지연 레플리카를 롤백할 수 있습니다.

• 시스템에 랙이 있을 때 어떻게 동작하는지 테스트하기 위해. 예를 들어, 어떤 애플리케이션에서 랙은 레플리카에 걸린 고부하 때문에 발생할 수 있습니다. 그러나 이러한 부하 수준을 생성하기는 어려울 수 있습니다. 지연 복제는 부하를 시뮬레이션하지 않고도 랙을 시뮬레이트할 수 있습니다. 또한 랙이 발생한 레플리카와 관련된 조건을 디버그하는 데 사용할 수 있습니다.

• 백업을 다시 로드하지 않고 과거의 데이터베이스 상태를 확인하기 위해. 예를 들어, 레플리카를 1주일 지연으로 구성해 두면, 최근 며칠 동안의 개발 작업 이전의 데이터베이스 상태를 확인해야 할 때 지연 레플리카를 검사하면 됩니다.

Replication Delay Timestamps

MySQL 9.5는 복제 토폴로지에서 지연(또는 복제 랙이라고도 함)을 측정하기 위한 새로운 방법을 제공합니다. 이 방법은 바이너리 로그에 기록되는 각 이벤트가 아닌 각 트랜잭션의 GTID에 연관된 다음 타임스탬프들에 의존합니다.

• original_commit_timestamp: 트랜잭션이 오리지널 소스의 바이너리 로그에 기록(커밋)된 시점의 에포크 이후 마이크로초 수입니다.

• immediate_commit_timestamp: 트랜잭션이 즉시 소스의 바이너리 로그에 기록(커밋)된 시점의 에포크 이후 마이크로초 수입니다.

mysqlbinlog의 출력은 이 타임스탬프들을 에포크 이후 마이크로초와, 가독성을 높이기 위해 사용자 정의 시간대(time zone)를 기반으로 하는 TIMESTAMP 포맷 두 가지 형식으로 표시합니다. 예를 들면 다음과 같습니다:

1#170404 10:48:05 server id 1  end_log_pos 233 CRC32 0x016ce647     GTID    last_committed=0 sequence_number=1    original_committed_timestamp=1491299285661130    immediate_commit_timestamp=1491299285843771
2# original_commit_timestamp=1491299285661130 (2017-04-04 10:48:05.661130 WEST)
3# immediate_commit_timestamp=1491299285843771 (2017-04-04 10:48:05.843771 WEST)
4 /*!80001 SET @@SESSION.original_commit_timestamp=1491299285661130*//*!*/;
5   SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1'/*!*/;
6# at 233

일반적으로 original_commit_timestamp는 트랜잭션이 적용되는 모든 레플리카에서 항상 같습니다. 소스-레플리카 복제에서, (오리지널) 소스의 바이너리 로그에 있는 트랜잭션의 original_commit_timestamp는 항상 그 트랜잭션의 immediate_commit_timestamp와 같습니다. 레플리카의 릴레이 로그에서는 트랜잭션의 original_commit_timestamp와 immediate_commit_timestamp가 소스의 바이너리 로그에 있는 것과 동일합니다. 반면 레플리카 자신의 바이너리 로그에서는 트랜잭션의 immediate_commit_timestamp가 레플리카가 해당 트랜잭션을 커밋한 시점을 나타냅니다.

Group Replication 구성에서 오리지널 소스가 그룹의 멤버인 경우, original_commit_timestamp는 트랜잭션이 커밋 준비가 되었을 때 생성됩니다. 즉, 오리지널 소스에서 실행이 완료되고 그 라이트 세트가 그룹의 모든 멤버에게 인증을 위해 전송할 준비가 되었을 때입니다. 오리지널 소스가 그룹 외부의 서버인 경우, original_commit_timestamp는 유지됩니다. 특정 트랜잭션에 대한 동일한 original_commit_timestamp가 그룹 내의 모든 서버와, 멤버로부터 복제를 수행하는 그룹 외부의 모든 레플리카에 복제됩니다. 트랜잭션의 각 수신자는 또한 자신의 바이너리 로그에 immediate_commit_timestamp를 사용하여 로컬 커밋 시각을 저장합니다.

Group Replication에만 독점적으로 존재하는 뷰 변경 이벤트는 특수한 경우입니다. 이러한 이벤트를 포함하는 트랜잭션은 각 그룹 멤버에 의해 생성되지만 동일한 GTID를 공유합니다(따라서, 이들은 먼저 소스에서 실행되고 나서 그룹으로 복제되는 것이 아니라, 그룹의 모든 멤버가 동일한 트랜잭션을 실행하고 적용합니다). 그룹 멤버는 뷰 변경 이벤트와 연관된 트랜잭션에 대해 로컬 타임스탬프 값을 설정합니다.

Monitoring Replication Delay

이전 MySQL 버전에서 복제 지연(랙)을 모니터링하는 가장 일반적인 방법 중 하나는 SHOW REPLICA STATUS 출력의 Seconds_Behind_Master 필드에 의존하는 것이었습니다. 그러나 이 메트릭은 Group Replication과 같이 전통적인 소스-레플리카 구성을 넘어서는 복잡한 복제 토폴로지를 사용할 때에는 적합하지 않습니다. immediate_commit_timestamp와 original_commit_timestamp가 MySQL 8에 추가되면서 복제 지연에 대한 훨씬 더 정밀한 정보를 제공하게 되었습니다. 이러한 타임스탬프들을 지원하는 토폴로지에서 복제 지연을 모니터링하는 권장 방법은 다음 Performance Schema 테이블들을 사용하는 것입니다.

• replication_connection_status: 소스에 대한 커넥션의 현재 상태로, 커넥션 스레드가 릴레이 로그에 큐한 마지막 트랜잭션과 현재 트랜잭션에 대한 정보를 제공합니다.

• replication_applier_status_by_coordinator: 멀티스레드 레플리카를 사용할 때에만 정보를 표시하는 코디네이터 스레드의 현재 상태로, 코디네이터 스레드가 워커의 큐에 버퍼한 마지막 트랜잭션과 현재 버퍼 중인 트랜잭션에 대한 정보를 제공합니다.

• replication_applier_status_by_worker: 소스로부터 수신한 트랜잭션을 적용하는 스레드(들)의 현재 상태로, 복제 SQL 스레드 또는 멀티스레드 레플리카를 사용하는 경우 각 워커 스레드가 적용한 트랜잭션에 대한 정보를 제공합니다.

이 테이블들을 사용하면 해당 스레드가 마지막으로 처리한 트랜잭션과 현재 처리 중인 트랜잭션에 대한 정보를 모니터링할 수 있습니다. 이 정보는 다음을 포함합니다:

• 트랜잭션의 GTID

• 레플리카의 릴레이 로그에서 가져온 트랜잭션의 original_commit_timestamp와 immediate_commit_timestamp

• 스레드가 트랜잭션을 처리하기 시작한 시점

• 마지막으로 처리한 트랜잭션에 대해, 스레드가 이를 처리 완료한 시점

Performance Schema 테이블들 외에도, SHOW REPLICA STATUS의 출력에는 다음을 표시하는 세 개의 필드가 있습니다:

• SQL_Delay: CHANGE REPLICATION SOURCE TO SOURCE_DELAY=N를 사용하여 구성한 복제 지연을 나타내는 음이 아닌 정수이며, 여기서 _N_은 초 단위로 측정됩니다.

• SQL_Remaining_Delay: Replica_SQL_Running_State가 Waiting until SOURCE_DELAY seconds after master executed event일 때, 이 필드에는 남아 있는 지연 초 수를 나타내는 정수가 들어 있습니다. 다른 때에는 이 필드는 NULL입니다.

• Replica_SQL_Running_State: SQL 스레드의 상태를 나타내는 문자열로( Replica_IO_State와 유사), 값은 SHOW PROCESSLIST에서 표시되는 SQL 스레드의 State 값과 동일합니다.

복제 SQL 스레드가 이벤트를 실행하기 전에 지연이 경과하기를 기다리는 경우, SHOW PROCESSLIST는 해당 스레드의 State 값을 Waiting until SOURCE_DELAY seconds after master executed event로 표시합니다.