20.7.2 Flow Control

20.7.2 Flow Control

20.7.2.1 Probes and Statistics
20.7.2.2 Group Replication Throttling

MySQL Group Replication은 그룹의 다수(멤버의 과반수)가 어떤 트랜잭션을 수신하고, 동시에 전송된 모든 트랜잭션 사이의 상대적인 순서에 합의한 이후에만 그 트랜잭션이 커밋되도록 보장합니다. 이런 방식은 그룹 전체로 들어오는 쓰기의 양이 그룹 내 어떤 멤버의 쓰기 처리량을 초과하지 않을 때는 잘 동작합니다.

하지만 이를 초과하고, 어떤 멤버들이 다른 멤버들보다—특히 라이터 멤버들보다—쓰기 처리량이 낮은 경우, 이런 멤버들은 라이터들보다 뒤처지기 시작할 수 있습니다.

어떤 멤버들이 그룹의 나머지 멤버들보다 뒤처지면, 그러한 멤버에서의 읽기는 매우 오래된 데이터를 외부로 노출할 수 있습니다. 해당 멤버가 왜 뒤처졌는지에 따라, 그룹의 다른 멤버들은 느린 멤버로부터의 잠재적인 데이터 전송 요청을 처리할 수 있도록 복제 컨텍스트를 더 많이 혹은 더 적게 저장해야 할 수 있습니다.

복제 프로토콜은, 적용된 트랜잭션의 관점에서 빠른 멤버와 느린 멤버 사이에 너무 큰 거리가 생기는 것을 피하기 위한 메커니즘을 제공합니다. 이것을 플로우 컨트롤 메커니즘이라고 하며, 다음과 같은 목표를 갖습니다:

1. 멤버들 간의 거리를 가깝게 유지하여, 서로 간의 버퍼링 및 비동기화(desynchronization)를 최소화한다.

2. 서로 다른 워크로드나 그룹 내 라이터 수 증가와 같은 변화하는 조건에 빠르게 적응한다.

3. 각 멤버에게 사용 가능한 쓰기 처리량의 일부를 할당한다.

4. 자원을 낭비하지 않도록, 필요한 최소 수준 이상으로 처리량을 감소시키지 않는다.

Group Replication의 설계상, 스로틀링을 할지 말지를 결정할 때 두 개의 작업 대기열, 즉 인증 큐(certification queue)와 바이너리 로그 적용기 큐(binary log applier queue)를 고려할 수 있습니다. 이 큐들 중 하나의 크기가 사용자가 정의한 임계값을 초과하면, 스로틀링 메커니즘이 트리거됩니다.

플로우 컨트롤은 두 가지 기본 메커니즘에 의존합니다:

1. 멤버들을 모니터링하여 처리량과 모든 그룹 멤버의 대기열 크기에 대한 통계를 수집하고, 각 멤버가 감당할 수 있는 최대 쓰기 압력에 대해 근거 있는 추정을 할 수 있도록 한다.

2. 매 시점에서 사용 가능한 처리량에서 자신에게 할당된 몫을 초과하여 쓰기를 시도하는 멤버를 스로틀링한다.

참고

MySQL Enterprise Edition의 일부로 제공되는 Group Replication Flow Control Statistics Component는 Group Replication 플로우 컨트롤 실행에 대한 정보를 제공하는 상태 변수를 지원합니다. 더 많은 정보는 Section 7.5.6.2, “Group Replication Flow Control Statistics Component”를 참조하십시오.