데브러너 (DevRunner)

19.4.10 Semisynchronous Replication

19.4.10.1 Installing Semisynchronous Replication 19.4.10.2 Configuring Semisynchronous Replication 19.4.10.3 Semisynchronous Replication Monitoring

내장된 비동기식 복제 외에도, MySQL 9.5는 플러그인에 의해 구현되는 세미싱크(semisynchronous) 복제에 대한 인터페이스를 지원합니다. 이 섹션에서는 세미싱크 복제가 무엇인지와 그것이 어떻게 동작하는지를 다룹니다.

다음 섹션에서는 세미싱크 복제에 대한 관리 인터페이스와 이를 설치, 구성, 모니터링하는 방법을 다룹니다.

MySQL 복제는 기본적으로 비동기식입니다. 소스는 이벤트를 바이너리 로그에 기록하고, 레플리카는 준비가 되면 이를 요청합니다. 소스는 레플리카가 언제 또는 레플리카가 트랜잭션을 검색하고 처리했는지 알지 못하며, 어떤 이벤트라도 레플리카에 도달한다는 보장이 없습니다.

비동기식 복제에서 소스가 크래시하면, 그가 커밋한 트랜잭션이 어떤 레플리카에도 전송되지 않았을 수 있습니다. 이 경우 소스에서 레플리카로의 페일오버는 소스에 비해 트랜잭션이 누락된 서버로의 페일오버를 초래할 수 있습니다.

완전한 동기식 복제에서는, 소스가 트랜잭션을 커밋할 때, 소스가 트랜잭션을 수행한 세션으로 돌아가기 전에 모든 레플리카도 그 트랜잭션을 커밋한 상태가 됩니다. 완전한 동기식 복제는 언제든지 소스에서 어떤 레플리카로든 페일오버가 가능함을 의미합니다.

완전한 동기식 복제의 단점은, 트랜잭션을 완료하는 데 많은 지연이 발생할 수 있다는 점입니다.

세미싱크 복제는 비동기식과 완전한 동기식 복제의 중간에 위치합니다. 소스는 적어도 하나의 레플리카가 이벤트를 수신하고 로그에 기록할 때까지(필요한 레플리카 수는 설정 가능) 기다린 다음 트랜잭션을 커밋합니다.

소스는 모든 레플리카가 수신을 확인할 때까지 기다리지 않으며, 레플리카 측에서 이벤트가 완전히 실행되고 커밋되었음을 요구하지 않고 레플리카로부터의 수신 확인(acknowledgement)만을 요구합니다. 따라서 세미싱크 복제는 소스가 크래시하더라도, 소스가 커밋한 모든 트랜잭션이 적어도 하나의 레플리카로 전송되었음을 보장합니다.

비동기식 복제와 비교했을 때, 세미싱크 복제는 커밋이 성공적으로 반환되면 데이터가 최소 두 곳에 존재한다는 것을 알 수 있으므로, 향상된 데이터 무결성을 제공합니다. 세미싱크 소스가 필요한 수의 레플리카로부터 확인을 받을 때까지, 해당 트랜잭션은 보류 상태이며 커밋되지 않습니다.

완전한 동기식 복제와 비교했을 때, 세미싱크 복제는 더 빠른데, 이는 데이터 무결성(해당 트랜잭션의 수신을 확인하는 레플리카 수)에 대한 요구사항과, 레플리카를 기다려야 하기 때문에 느려지는 커밋 속도 간의 균형을 맞추도록 구성할 수 있기 때문입니다.

주의

세미싱크 복제에서, 소스가 크래시하고 레플리카로의 페일오버가 수행되면, 실패한 소스는 복제 소스로 재사용해서는 안 되며, 폐기해야 합니다. 해당 소스에는 어떤 레플리카에서도 확인되지 않은 트랜잭션이 있을 수 있고, 따라서 페일오버 이전에 커밋되지 않았을 수 있습니다.

목표가 모든 서버가 동일한 트랜잭션을 동일한 순서로 수신하고, 크래시한 서버가 그룹에 다시 합류해 자동으로 최신 상태로 동기화될 수 있는 장애 내성(fault-tolerant) 복제 토폴로지를 구현하는 것이라면, 이를 위해 Group Replication을 사용할 수 있습니다. 자세한 내용은
Chapter 20, Group Replication을 참조하십시오.

세미싱크 복제가 비동기식 복제에 비해 갖는 성능 영향은 증가된 데이터 무결성을 위한 트레이드오프입니다. 성능 저하는 최소한, 커밋을 레플리카에 전송하고 레플리카의 수신 확인을 기다리는 TCP/IP 왕복 시간만큼 발생합니다.

이는 세미싱크 복제가 빠른 네트워크로 통신하는 가까운 서버 간에 가장 잘 동작하고, 느린 네트워크로 통신하는 먼 서버 간에는 가장 나쁘게 동작함을 의미합니다. 세미싱크 복제는 또한 소스에서 레플리카로 바이너리 로그 이벤트를 보낼 수 있는 속도를 제한함으로써, 바쁜 세션에 대해 전송 속도 제한(rate limit)을 가합니다. 한 사용자가 너무 바쁘면, 이것이 해당 세션을 느려지게 하며, 이는 일부 배포 환경에서는 유용할 수 있습니다.

소스와 그 레플리카들 간의 세미싱크 복제는 다음과 같이 동작합니다:

레플리카는 소스에 연결할 때 자신이 세미싱크를 지원할 수 있는지 여부를 나타냅니다.
소스 측에서 세미싱크 복제가 활성화되어 있고 적어도 하나의 세미싱크 레플리카가 있는 경우, 소스에서 트랜잭션 커밋을 수행하는 스레드는 최소 하나의 세미싱크 레플리카가 해당 트랜잭션에 대한 모든 이벤트를 수신했다고 확인하거나, 타임아웃이 발생할 때까지 블록되고 기다립니다.
레플리카는 이벤트가 릴레이 로그에 기록되고 디스크에 플러시된 이후에만 트랜잭션 이벤트의 수신을 확인합니다.
어떤 레플리카도 해당 트랜잭션을 확인하지 않은 채 타임아웃이 발생하면, 소스는 비동기식 복제로 되돌아갑니다. 적어도 하나의 세미싱크 레플리카가 따라잡으면, 소스는 다시 세미싱크 복제로 복귀합니다.
세미싱크 복제는 소스와 레플리카 양쪽에서 모두 활성화되어야 합니다. 소스에서 세미싱크 복제가 비활성화되어 있거나, 소스에서 활성화되어 있지만 어떤 레플리카에서도 활성화되어 있지 않으면, 소스는 비동기식 복제를 사용합니다.

소스가 블록 상태일 때(레플리카로부터 확인을 기다리는 동안), 소스는 트랜잭션을 수행한 세션으로 돌아가지 않습니다. 블록이 종료되면, 소스는 세션으로 돌아가고, 해당 세션은 이후 다른 문(statement)을 실행할 수 있습니다.

이 시점에서 트랜잭션은 소스 측에서 커밋되었고, 그 이벤트의 수신이 최소 하나의 레플리카에 의해 확인되었습니다. 소스가 세션으로 돌아가기 전에 트랜잭션당 수신해야 하는 레플리카 확인 횟수는 설정 가능하며, 기본값은 한 번의 확인입니다(자세한 내용은
Section 19.4.10.2, “Configuring Semisynchronous Replication”을 참조하십시오).

바이너리 로그에 기록되는 롤백 이후에도 블로킹이 발생하며, 이는 비트랜잭션 테이블을 수정하는 트랜잭션이 롤백될 때 발생합니다. 비트랜잭션 테이블에 대한 수정은 롤백할 수 없고 레플리카로 전송되어야 하므로, 이 롤백된 트랜잭션은 트랜잭션 테이블에 영향이 없더라도 로그에 기록됩니다.

트랜잭션 컨텍스트에서 발생하지 않는 문(즉, START TRANSACTION 또는 SET autocommit = 0으로 트랜잭션이 시작되지 않은 경우)에 대해서는, autocommit이 활성화되어 있고 각 문은 암시적으로 커밋됩니다. 세미싱크 복제에서는, 소스가 명시적인 트랜잭션 커밋에 대해 블록하는 것과 마찬가지로, 이러한 각 문에 대해서도 블록합니다.

기본적으로, 소스는 바이너리 로그를 디스크에 동기화한 후, 트랜잭션을 스토리지 엔진에 커밋하기 전에 해당 트랜잭션 수신에 대한 레플리카 확인을 기다립니다. 대안으로, rpl_semi_sync_source_wait_point 시스템 변수를 사용하여, 소스가 트랜잭션을 스토리지 엔진에 커밋한 후에 레플리카 확인을 기다리도록 소스를 구성할 수 있습니다.

이 설정은 복제 특성과 소스에서 클라이언트가 볼 수 있는 데이터에 영향을 줍니다. 자세한 내용은
Section 19.4.10.2, “Configuring Semisynchronous Replication”을 참조하십시오.

다음 시스템 변수를 활성화하여 세미싱크 복제의 성능을 향상시킬 수 있습니다:
replication_sender_observe_commit_only (콜백을 제한)와
replication_optimize_for_static_plugin_config (공유 잠금을 추가하고 불필요한 잠금 획득을 방지). 레플리카 수가 증가함에 따라 잠금 경합이 성능 저하를 일으킬 수 있으므로 이 설정들이 도움이 됩니다.

세미싱크 복제 소스 서버 역시 레플리카와 동일한 잠금 메커니즘을 사용하므로, 이들 시스템 변수를 활성화하면 성능상의 이점을 얻을 수 있습니다.