3. Monitoring Group Replication

Performance Schema 의 테이블을 이용하면 Group Replication을 모니터링을 할 수 있다. 모니터링을 하기 위해 다음과 같은 테이블들이 생성된다. 

-- performance_schema.replication_group_member_stats

-- performance_schema.replication_group_members

기존에 존재하던 리플리케이션 관련 테이블에도 Group Replication을 위한 모니터링에 사용할 수 있다. 

-- performance_schema.replication_connection_status

-- performance_schema.replication_applier_status

Group Replication에서 사용하는 Replication channel은 다음과 같은 이름으로 생성된다. 

-- group_replication_recovery : 이 채널은 분산 복구 프로세스를 진행할때 사용하는 채널이다. 

-- group_replication_applier : 그룹안에서 변경내역을 받아 올때 사용하는 채널이다. 이 채널은 그룹안에서 실행된 트랜잭션의 정보를 바로 받아오는 채널이다. 

1. Replication_group_member_stats

리플리케이션안의 각 멤버들은 그룹에 의해 커밋된 트랜잭션을 인증하고 적용한다. 이때 사용하는 certifier , applier 프로스듀어들이 생성해 내는 통계자료들은 각각의 작업이 얼마나 일어났고, 얼만큼 진행되었는지 확인하기에 유용하다. 해당 테이블들 중 performance_schema.replication_group_member_stats 는 certification 프로세스가 얼만큼 작업했고, 어떻게 작업했는지 중요한 정보들을 제공한다. 

performance_schema.replication_group_member_stats의 각 컬럼별 정보는 다음과 같다. 

컬럼	설명
Channel_name	Group Replication 채널의 이름
Member_id	현재 연결된 멤버 서버의 UUID를 의미한다. 그룹안에서 해당 값은 멤버서버들이 모두 다른 값을 가진다. 해당 값이 각 멤버를 가리키는 키가 된다.
Count_Transactions_in_queue	충돌이 감지되어 중지 중인 큐에 저장된 트랜잭션의 수. 한번 충돌이 감지되면, 그리고 체크되어 한번 패스 하게 되면 그 트랜잭션은 큐에 쌓여서 적용되기를 기다린다.
Count_transactions_checked	충돌이 확인된 트랜잭션의 수
Count_conflicts_detected	충돌 감지 체크를 통과하지 못한 트랜잭션의 수.
Count_transactions_validating	충돌 감지 데이터 베이스의 현재 사이즈(각 트랜잭션들은 인증까지는 완료된 상태에서)
Transactions_committed_all_members	현재 view에서 모든 멤버 서버들에서 성공적으로 커밋된 트랜잭션을 보여준다. 해당 정보는 주기적으로 갱신된다.
Last_conflict_free_transaction	가장 최근에 확인된 충돌없이 처리된 트랜잭션의 식별자 정보

해당 정보들은 MySQL Group 안의 멤버들의 실행 성능을 확인하기에 좋은 정보들이다. 예를 들어, 하나의 멤버가 최신 상태를 유지할 수 없다고 한다면, 대기열에 많은 수의 트랜잭션이 표시될 것이다. 이 정보를 기반으로 그룹에서 구성원을 제거하거나 그룹의 다른 구성원에 대한 트랜잭션 처리를 지연하여 대기 중인 트랜잭션 수를 줄일 수 있다. 또한 이 정보를 사용하여 Group Replication 플러그인의 흐름 제어를 조정하는 방법을 결정하는데 도움을 줄 수 있다. 

2. Replication_group_members

해당 테이블은 Current View에서 추적되는 다른 서버 인스턴스의 상태를 모니터링 하는데 사용된다. 

컬럼	설명
Channel_name	Group Replication channel 의 이름.
Member_id	멤버 서버의 UUID
Member_host	각 멤버의 Network 주소
Member_port	각 멤버들이 사용하는 포트
Member_state	각 멤버들의 현재 상태 ( ONLINE, ERROR, RECOVERING, OFFLINE, UNREACHABLE 중 하나의 값이 보여지게 된다. )

3. Replication_connection_status

Group에 연결되어 있을 때, 이 테이블의 몇몇 컬럼들은 Group Replication과 관련된 정보를 보여준다. 예를 들어, Group에서 수신되어 Applier Queue에 대기중인 트랜잭션 정보를 확인할 수 있다. 

컬럼	설명
Channel_name	Group Replication channel 의 이름.
Group_name	그룹의 이름을 보여준다. 이 값은 항상 유효한 UUID이다.
Source_UUID	그룹의 식별자를 보여준다. 그룹 이름과 유사하며 그룹 복제중에 생성된 모든 트랜잭션의 UUID로 사용된다.
Service_state	구성원이 그룹에 속해있는지를 보여준다. 가능한 값으로는 ON, OFF CONNECTING이 있다.
Received_transaction_set	그룹안의 멤버에 의해 받아진 GTID set 안의 트랜잭션 정보를 보여준다.

4. Replication_applier_status

이 테이블을 사용하여 Group Replication 에 관련된 채널 및 스레드의 상태를 확인할 수 있다. 트랜잭션을 적용하는 worker 스레드가 많으면 worker 테이블을 사용하여 각 worker 스레드가 수행중인 작업을 모니터링 할 수 있다. 

컬럼	설명
Channel_name	Group Replication channel 의 이름.
Service_state	Applier 서비스의 상태를 보여준다. ( ON, OFF)
Remaining_delay	Applier가 지연되고 있는지 정보를 확인할 수 있다.
Count_transactions_retries	트랜잭션을 적용하는 동안 수행된 재시도 횟수
Received_transaction_set	그룹안의 멤버에 의해 받아진 GTID set 안의 트랜잭션 정보를 보여준다.

5. Group Replication Server States

Replication_group_members 테이블은 View 변경이 있을때 마다 수정된다. ( 예를 들어, 그룹 구성이 동적으로 변경되는경우 그러하다.) 이 시점에서 서버는 일부 메터 정보를 교환하여 동기화를 계속하고 협력을 계속한다. 

각 서버들은 운영중에 다양한 상태를 가질 수 있다. 서버가 제대로 통신 중인 경우에는 모든 서버가 모든 서버에 대해 동일한 상태를 보여준다. 그러나, 네트워크 파티션이 있거나 서버가 그룹을 뗘날 경우에는 서버에 따라 각 서버의 정보가 다르게 될 수도 있다. 서버가 그룹에서 떠난 경우에는 해당 정보를 정확히 변경할 수 있게 전달해 줄 수가 없다. 그래서 서버가 서로 서로 조정할 수 없다. 따라서 다른 서버들의 상태를 추측할 수도 있다. 따라서 상태를 추측하지 않고 대신 일부 서버에 도달 할 수 없다고 보고한다. 

상태 정보	설명	그룹 동기화
ONLINE	각 구성원은 그룹내에서 구성원으로 충분히 작업할 준비가 되어있는 상태이다. 즉 각자 트랜잭션을 실행할 수 있는 상태이다.	YES
RECOVERING	서버가 멤버가 되기위해 복구 작업을 진행하고 있는 상태이다.	NO
OFFLINE	플러그인은 로드 되었지만, 어디에도 속하지 않은 상태이다.	NO
ERROR	복구 단계에서 오류가 발생했거나 변경 사항 적용중에 문제가 발생한 상태를 말한다.	NO
UNREACHABLE	로컬 장애 감지기가 특정 서버에 도달할 수 없다고 의심할 때 이와 같이 표시된다. 서버가 비정상적이거나 연결이 자주 끊어질 때에도 해당 정보로 표시된다.	NO

Group Replication은 동기식은 아니지만 어찌보면 동기식이다. 정확하게 설명하면, 트랜잭션이 모두 동일한 순서대로 실행되는 것은 보장되지만, 항상  모든 멤버에 동시에 실행되는 것은 아니다. 실행 시간은 각 서버들의 리소스 상태에 따라 결정된다.