MySQL을 위한 멀티 마스터 업데이트 솔루션이 여기 있습니다. MySQL 그룹 복제는 충돌 처리 및 실패 감지를 통해 MySQL 서버 그룹의 모든 멤버에 대한 가상 동기 업데이트를 보장합니다. 분산 복구도 패키지에 포함되어 있어 새 멤버를 추가하는 과정을 용이하게 합니다.
MySQL 5.7.2부터 복제 팀은 성능 스키마 테이블에서 복제 성능을 모니터링하기 위한 더 많은 필드를 제공하기 위해 끊임없이 노력해 왔습니다. 이 게시물은 MySQL 그룹 복제에 도입된 성능 스키마 테이블에 대한 간략한 개요를 제공합니다.
참고: 최근 변경 사항 및 업데이트는 다음을 확인하세요.
소개된 표
MySQL 그룹 복제 모니터링의 일부로 두 개의 새로운 테이블이 도입되었습니다.
- 성능 스키마.복제 그룹 멤버 통계
- 성능 스키마.복제 그룹 멤버
각 표를 자세히 살펴보겠습니다.
복제 그룹 멤버 통계
복제 그룹의 각 멤버는 Certifier와 Applier 와 연관됩니다 . 이러한 모듈에 대한 통계는 P_S 테이블 인터페이스를 통해 내보내는 데 유용합니다.
이 표에 포함된 필드와 관련하여 이 표를 논의하고 아래에서 어떻게 업데이트되는지 살펴보겠습니다.
- Channel_name – 그룹 복제 채널의 이름입니다.
- Member_id – 현재 연결된 멤버 서버 UUID를 제공합니다. 이는 그룹의 각 멤버에 대해 다른 값을 갖습니다. 또한 이는 각 멤버에 고유하고 인증/Applier 프로세스와 관련이 없기 때문에 키 역할을 합니다.
- Count_Transactions_in_queue – 인증 및 적용을 기다리는 대기 중인 거래 수. 간단한 실행의 경우 이 필드는 값 0을 표시하지만 부하가 높으면 대기 중인 거래가 발생합니다.
- Count_transactions_checked – 이 필드는 인증된 거래 수(긍정적 인증과 부정적 인증 모두)를 나타냅니다.
- Count_conflicts_detected – 이 필드는 부정적으로 인증된 거래의 수를 나타냅니다.
- Count_transactions_validating – 이 필드는 인증 데이터베이스(각 거래가 인증되는 데이터베이스)의 크기를 나타냅니다.
- Transactions_committed_all_members – 이것은 그룹의 모든 멤버에서 성공적으로 커밋된 트랜잭션 세트를 나타내는 gtid_set입니다(즉, 그룹의 모든 멤버의 gtid_executed 세트의 교집합입니다). 이 값은 인증 모듈에 의해 고정된 시간 간격으로 업데이트됩니다.
- Last_conflict_free_transaction – 이는 마지막으로 긍정적으로 인증된 거래의 GTID를 나타냅니다.
이러한 필드는 DBA가 그룹에 연결된 멤버의 성능을 모니터링하는 데 중요합니다. 그룹 멤버 중 한 명이 지연되어 그룹의 다른 멤버와 보조를 맞출 수 없다고 가정해 보겠습니다. 이 경우 DBA는 대기열에 많은 수의 트랜잭션이 있는 것을 보게 됩니다. 이에 대응하여 그룹에서 멤버를 제거하거나 그룹의 다른 멤버에서 트랜잭션 처리를 지연시켜 대기 중인 트랜잭션 수를 줄일 수 있습니다.
이제 MySQL 그룹 복제가 적용되어 이 테이블이 어떻게 업데이트되는지 살펴보겠습니다.
그룹에 가입하기 전 performance_schema.replication_group_member_stats의 초기 상태는 모든 필드가 비어 있는 것으로 표시됩니다.
> SELECT * FROM performance_schema.replication_group_member_stats\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID:
MEMBER_ID:
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 0
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS:
그룹에 대한 그룹 이름을 설정하고 그룹 복제를 시작한 후 트랜잭션이 시작되기 전에 이 테이블에는 Channel_name 값만 나열됩니다.
> SET GLOBAL group_replication_group_name='8a84f397-aaa4-18df-89ab-c70aa9823561';
Query OK, 0 rows affected (0.00 sec)> START GROUP_REPLICATION;
Query OK, 0 rows affected (0.14 sec)> SELECT * FROM performance_schema.replication_group_member_stats\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 1428497631:1
MEMBER_ID: e38fdea8-dded-11e4-b211-e8b1fc3848de
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 0
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS:
LAST_CONFLICT_FREE_TRANSACTION: 8a94f357-aab4-11df-86ab-c80aa9429562:1> CREATE TABLE t1 (c1 INT NOT NULL PRIMARY KEY) ENGINE=InnoDB;
Query OK, 0 rows affected (0.09 sec)이제 그룹의 서로 다른 멤버에 대해 일부 거래 집합을 병렬로 실행하여 부정적인 인증으로 이어질 수 있는 충돌이 발생하지 않도록 합니다.
> INSERT INTO t1 VALUES (1);
Query OK, 1 row affected (0.02 sec)> INSERT INTO t1 VALUES (2);
ERROR 1181 (HY000): Got error 149 during ROLLBACK> INSERT INTO t1 VALUES (2);
Query OK, 1 row affected (0.03 sec)member1과 member2가 병렬로 트랜잭션을 실행하기 때문에 두 번째 삽입 중에 member1에서 충돌이 발생합니다.
참고 – 1에서도 트랜잭션이 실패할 가능성은 동일합니다. 하지만 두 번째 삽입이 member1에서 실패하는 현재 사례를 고려해 보겠습니다.
또한 동시 트랜잭션 세트를 실행하고 상태를 살펴보겠습니다. (여기서는 블로그 길이가 늘어나는 것을 방지하기 위해 표시하지 않음). 거래가 수행된 후 테이블의 상태는 다음과 같습니다.
> SELECT * FROM t1;
+------+
| c1 |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
+------+
멤버 중 하나의 테이블 상태는 다음과 같습니다.
> SELECT * FROM performance_schema.replication_group_member_stats\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 1428497631:1
MEMBER_ID: e38fdea8-dded-11e4-b211-e8b1fc3848de
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 12
COUNT_CONFLICTS_DETECTED: 5
COUNT_TRANSACTIONS_VALIDATING: 6
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 8a84f397-aaa4-18df-89ab-c70aa9823561:1-7
LAST_CONFLICT_FREE_TRANSACTION: 8a84f397-aaa4-18df-89ab-c70aa9823561:7
이제 최종 표에서 개별 필드의 값을 분석해 보겠습니다.
COUNT_TRANSACTIONS_IN_QUEUE 값이 0이면 적용 대기열에 아직 적용될 트랜잭션이 없음을 나타냅니다.
COUNT_TRANSACTIONS_CHECKED count 12는 거래 처리 중에 인증을 위해 처리된 거래가 12개였음을 의미합니다.
COUNT_CONFLICTS_DETECTED 수가 5인 것은 인증을 거친 12개 거래 중 5개는 부정적으로 인증되었고 7개는 긍정적으로 인증되었다는 것을 의미합니다.
COUNT_TRANSACTIONS_VALIDATING – 인증 정보에 있는 거래 수로, 해당 거래로 인증을 실행할 수 있지만 아직 가비지 수집되지 않았습니다.
“ 8a94f357-aab4-11df-86ab-c80aa9429563:1-7 ”의 TRANSACTIONS_COMMITTED_ALL_MEMBERS는 이 GTID 세트의 트랜잭션이 그룹의 모든 멤버에 존재한다는 것을 의미합니다. 즉, 마지막으로 인증의 가비지 수집 프로세스가 실행되었을 때 이 GTID 그룹이 모든 멤버에 존재했음을 의미합니다.
값이 “8a94f357-aab4-11df-86ab-c80aa9429563:7”인 LAST_CONFLICT_FREE_TRANSACTION은 충돌 없이 인증된 마지막 거래에 이 GTID가 있었음을 의미합니다.
복제 그룹 멤버
이 표는 그룹 내 다양한 멤버의 상태와 연결 세부 정보를 파악하는 데 사용됩니다.
이 표의 개별 필드를 살펴보면 더 잘 이해할 수 있을 것입니다.
- Channel_name – 그룹 복제 채널의 이름입니다.
- Member_id – 현재 연결된 멤버 서버 UUID를 제공합니다. 이는 그룹의 각 멤버에 대해 다른 값을 갖습니다.
- Member_host – 멤버의 네트워크 주소입니다.
- Member_port – 멤버가 수신 중인 포트입니다.
- Member_state – 이것은 그룹 멤버의 상태(ONLINE, RECOVERING 또는 OFFLINE)를 제공합니다.
- 온라인: 이는 회원이 완전한 기능을 갖춘 그룹 회원으로서 서비스할 준비가 되었다는 것을 의미합니다. 즉, 클라이언트가 연결하여 거래를 실행할 수 있습니다.
- 회복 중: 이는 회원이 그룹의 활동 회원이 되는 과정에 있으며, 기부자로부터 상태를 받으며 실제로 회복 과정을 거치고 있음을 의미합니다.
- 오프라인: 플러그인이 로드되었지만 멤버가 어느 그룹에도 속하지 않음을 의미합니다.
이제 MySQL 그룹 복제가 적용되어 이 테이블이 어떻게 업데이트되는지 살펴보겠습니다.
세 명의 멤버를 연결하여 MySQL 그룹을 형성하고 모든 그룹에서 그룹 복제를 시작하겠습니다. 이 테이블의 상태는 다음과 같습니다.
> SELECT * FROM performance_schema.replication_group_members\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 597dbb72-3e2c-11e4-9d9d-ecf4bb227f3b
MEMBER_HOST: nightfury
MEMBER_PORT: 13000
MEMBER_STATE: ONLINE
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 59efb8a1-3e2c-11e4-9d9d-ecf4bb227f3b
MEMBER_HOST: nightfury
MEMBER_PORT: 13001
MEMBER_STATE: ONLINE
*************************** 3. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 5a706f6b-3e2c-11e4-9d9d-ecf4bb227f3b
MEMBER_HOST: nightfury
MEMBER_PORT: 13002
MEMBER_STATE: RECOVERING
이제 최종 표에서 개별 필드의 값을 분석해 보겠습니다.
이 표는 세 개의 행으로 구성되며, 각 행은 그룹 내 특정 구성원의 지위에 대한 세부 정보를 나타냅니다.
값이 " group_replication_applier "인 CHANNEL_NAME은 채널의 이름을 제공합니다.
값이 “ 597dbb72-3e2c-11e4-9d9d-ecf4bb227f3b ”인 MEMBER_ID는 특정 멤버를 식별합니다.
“nightfury”의 MEMBER_HOST는 그러한 멤버 중 하나의 호스트 이름 값을 제공합니다.
MEMBER_PORT는 특정 멤버의 포트 번호를 제공합니다. 연결된 모든 멤버의 포트 번호 값을 갖게 됩니다.
MEMBER_STATE – 특정 멤버의 상태를 제공합니다. 연결된 모든 멤버에 대해 member_state에 대한 값이 하나 있습니다. 위 표에는 ONLINE인 멤버가 두 명 있고 RECOVERING인 멤버가 한 명 있습니다.
수정된 테이블
위에서 사용한 두 개의 새 테이블 외에도 기존 테이블 performance_schema.replication_connection_status를 그룹 복제에 유용한 필드로 확장했습니다. 이 수정된 테이블을 살펴보겠습니다.
복제 연결 상태
이 테이블은 MySQL-5.7.2에서 복제를 위한 성능 스키마 의 일부로 도입된 기존 테이블의 확장입니다 . "MySQL 그룹 복제"를 통해 그룹 연결 상태에 대한 세부 정보를 제공하는 행으로 이 테이블을 확장했습니다.
이제 MySQL 그룹 복제와 관련된 새로운 필드에 대해 알아보겠습니다.
- Channel_name – 그룹 복제 채널의 이름입니다.
- Group_name – 이 필드는 그룹 이름의 값을 보여줍니다. 항상 유효한 UUID입니다.
- 소스 UUID – 이것은 그룹의 식별자를 보여줍니다. 그룹 이름과 유사하며 그룹 복제 중에 생성되는 모든 트랜잭션의 UUID로 사용됩니다.
- Service_state – 이는 멤버가 그룹의 일부인지 여부를 보여줍니다. 서비스 상태의 가능한 값은 {ON, OFF 및 CONNECTING}입니다.
- ON : 멤버가 그룹에 연결되었습니다(복구 중 또는 온라인).
- OFF: 멤버가 연결 해제됨(OFFLINE)
- Received_transaction_set – 이 필드는 이 GTID 세트의 거래가 그룹의 이 멤버에게 수신되었음을 표시합니다.
그룹에 한 명의 멤버가 있는 테이블의 초기 상태부터 시작해 보겠습니다.
> SET GLOBAL group_replication_group_name='8a84f397-aaa4-18df-89ab-c70aa9823561';
Query OK, 0 rows affected (0.00 sec)> START GROUP_REPLICATION;
Query OK, 0 rows affected (0.14 sec)
> SELECT * FROM performance_schema.replication_connection_status\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
GROUP_NAME: 8a94f357-aab4-11df-86ab-c80aa9429563
SOURCE_UUID: 8a94f357-aab4-11df-86ab-c80aa9429563
THREAD_ID: NULL
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET: 8a94f357-aab4-11df-86ab-c80aa9429563:1-5
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
테이블의 필드 값을 살펴보겠습니다.
값이 " group_replication_applier "인 CHANNEL_NAME은 채널의 이름을 제공합니다.
값이 “8a94f357-aab4-11df-86ab-c80aa9429563”인 GROUP_NAME은 그룹의 이름을 제공합니다.
값이 “8a94f357-aab4-11df-86ab-c80aa9429563”인 SOURCE_UUID는 그룹에 식별자를 제공합니다. 이는 그룹 이름과 동일하다는 점에 유의하세요.
SERVICE_STATE 값이 " ON "이면 멤버가 그룹에 연결되었음을 의미합니다.
RECEIVED_TRANSACTION_SET의 값이 “ 8a94f357-aab4-11df-86ab-c80aa9429563:1-5 ”인 경우 이 gtid 세트의 트랜잭션이 그룹의 이 멤버에게 수신되었음을 의미합니다.
이 표는 회원 한 명당 하나씩 있으며, 해당 회원의 연결 상태에 대한 세부 정보를 제공합니다.
SELECT
(SELECT service_state FROM performance_schema.replication_connection_status WHERE CHANNEL_NAME='group_replication_applier') AS svrState1
,(SELECT member_state FROM performance_schema.replication_group_members WHERE member_id=@@server_uuid) AS svrState2;
# 리턴값 확인으로 모니터링
svrState1 = "ON"
svrState2 = "ONLINE"
원본 : https://dev.mysql.com/blog-archive/mysql-group-replication-monitoring/
