19.4.7 Improving Replication Performance

19.4.7 Improving Replication Performance

소스에 연결되는 replica의 수가 증가하면, 부하는 최소한이긴 하지만 역시 증가합니다. 각 replica가 소스에 대한 클라이언트 커넥션을 사용하기 때문입니다. 또한 각 replica는 소스의 바이너리 로그 전체 복사본을 수신해야 하므로, 소스에 대한 네트워크 부하도 증가하여 병목 현상을 일으킬 수 있습니다.

하나의 소스에 많은 수의 replica가 연결되어 있고, 그 소스가 (예를 들어 스케일 아웃 솔루션의 일부로서) 요청 처리로도 바쁘다면, 복제 프로세스의 성능을 향상시키고자 할 수 있습니다.

복제 프로세스의 성능을 향상시키는 한 가지 방법은, 소스가 단 하나의 replica에만 복제하도록 하고, 나머지 replica들은 자신들의 개별 복제 요구 사항을 위해 이 primary replica에 연결하도록 하는 더 깊은 복제 구조를 생성하는 것입니다. 이 구조의 예시는
Figure 19.3, “Using an Additional Replication Source to Improve Performance”에 나와 있습니다.

Figure 19.3 Using an Additional Replication Source to Improve Performance

이 방식이 동작하려면, MySQL 인스턴스들을 다음과 같이 구성해야 합니다:

• Source 1은 모든 변경 및 업데이트가 데이터베이스에 기록되는 primary source입니다. 바이너리 로깅은 두 소스 서버에서 활성화되어 있으며, 이는 기본값입니다.

• Source 2는 복제 구조의 나머지 replica들에게 복제 기능을 제공하는, 서버 Source 1의 replica입니다. Source 2만이 Source 1에 연결하는 것이 허용됩니다. Source 2에는 --log-replica-updates 옵션이 활성화되어 있습니다(기본값). 이 옵션을 사용하면, Source 1로부터의 복제 지시사항도 Source 2의 바이너리 로그에 기록되어, 실제 replica들로 다시 복제될 수 있습니다.

• Replica 1, Replica 2, Replica 3은 Source 2에 대한 replica로 동작하며, Source 2에서 정보를 복제합니다. 이 정보는 실제로 Source 1에 기록된 업그레이드들로 구성됩니다.

위의 솔루션은 primary source에 대한 클라이언트 부하와 네트워크 인터페이스 부하를 줄여 주며, 이를 통해 primary source를 직접적인 데이터베이스 솔루션으로 사용할 때 전반적인 성능을 향상시킬 수 있습니다.

replica들이 소스에서의 복제 프로세스를 따라가는 데 어려움을 겪고 있다면, 사용할 수 있는 여러 가지 옵션이 있습니다:

• 가능하다면 relay 로그와 데이터 파일을 서로 다른 물리 디스크에 두십시오. 이를 위해서는 relay_log 시스템 변수를 설정하여 relay 로그의 위치를 지정합니다.

• 바이너리 로그 파일과 relay 로그 파일을 읽기 위한 디스크 읽기 I/O 작업이 심각한 문제라면, rpl_read_size 시스템 변수 값을 증가시키는 것을 고려하십시오. 이 시스템 변수는 로그 파일에서 읽는 최소 데이터 양을 제어하며, 값을 증가시키면 파일 데이터가 현재 운영 체제에 의해 캐시되지 않은 경우의 파일 읽기와 I/O 정지를 줄이는 데 도움이 될 수 있습니다. 이 값의 크기만큼의 버퍼가 바이너리 로그 및 relay 로그 파일을 읽는 각 스레드에 대해 할당된다는 점에 유의하십시오. 여기에는 소스의 덤프 스레드와 replica의 코디네이터 스레드가 포함됩니다. 큰 값을 설정하면 서버의 메모리 사용량에 영향을 줄 수 있습니다.

• replica가 source보다 상당히 느리다면, 서로 다른 데이터베이스에 대한 복제 책임을 여러 replica로 나누는 것이 좋을 수 있습니다. Section 19.4.6, “Replicating Different Databases to Different Replicas”를 참조하십시오.

• source가 트랜잭션을 사용하고, replica에서의 트랜잭션 지원이 중요하지 않다면, replica에서는 MyISAM 또는 다른 비트랜잭션 엔진을 사용하십시오. Section 19.4.4, “Using Replication with Different Source and Replica Storage Engines”를 참조하십시오.

• replica가 source로 동작하지 않고, 장애 발생 시 source를 기동할 수 있는 솔루션을 이미 보유하고 있다면, log_replica_updates를 비활성화할 수 있습니다. 이렇게 하면 “dumb” replica가 자신이 실행한 이벤트를 자체 바이너리 로그에 기록하는 것을 방지할 수 있습니다.