MySQL 8.0.23 에서 복제 구조 가 노드 에서 자동 으로 고장 나 서 이동 하 는 문제

MGR 을 접 한 지 오래 되 었 습 니 다.MySQL 8.0.23 이 도래 했 고 MySQL Group Replication(MGR)의 높 은 사용 가능 한 구 조 를 바탕 으로 새로운 구조 방향 을 제 공 했 습 니 다.
재해 대비 기관실 의 slave 는 어떻게 호스트 룸 의 MGR 을 더욱 잘 지원 합 니까?
MGR 은 도대체 몇 개의 노드 를 망 칠 수 있 습 니까?
이번 에는 두 가지 질문 으로 MGR 의 사상 과 기능 에 대해 간단히 말씀 드 리 겠 습 니 다.
1.MySQL Group Relication 멤버 수의 용 착 력

위의 표 는 여러분 이 낯 설 지 않 을 거 라 고 믿 습 니 다.저 는 면접 에서"4 개 노드 의 MGR,최대 몇 개 나 나 빠 요?"라 고 자주 물 어 봅 니 다.대부분의 사람들 은"최대 1 개 는 나 쁘 고 2 개 는 나 쁘 면 뇌 가 갈 라 져 일 을 할 수 없다"고 대답 했다.

그럼 MGR 의 처리 방식 을 살 펴 보 겠 습 니 다.이 답 이 아 닐 까요?
1)우 리 는 4 노드 MGR 을 가지 고 있다.

질문 하나 묻 기:이 그림 은 딱 봐 도 Single 모드 인 데 화살 표 는 단 방향 이 아니 라 잘못 그린 거 아니 야?
2)이때,Second-04 가 갑자기 다운 되 었 습 니 다.그러면 MGR 군집 은 어떻게 될 까요?

클 러 스 터 이때 상태 가:

각 노드 는 고정 시간 에 각자 의 정 보 를 교환 합 니 다.

세 컨 드-04 노드 정 보 를 받 지 못 하면 다른 멤버 들 은 5 초 를 기다린다.

이 기간 에 세 컨 드-04 는 메 시 지 를 보 내지 않 았 을 것 이다.그래서 건강 한 멤버 들 은 세 컨 드-04 가 수상 한 상태 라 고 생각 하고 UNREACHABLE 상 태 를 표시 했다.

그리고 건강 한 구성원 은 매개 변수 에 따라:groupreplication_member_expel_timeout,계속 기다 리 세 요.

당 groupreplication_member_expel_timeout 시간 에 건강 한 멤버 들 은 Second-04 노드 를 군집 에서 쫓 아 냈 다.

그럼 포인트 가 왔 습 니 다.칠판 을 두 드 리 겠 습 니 다.
Second-04 에서 쫓 겨 나 지 않 았 을 때:
이때 클 러 스 터 는(4 노드-3 건강-1 나 쁨)이다.이 기간 에 1 개의 노드 를 계속 나 쁘 게 하면 클 러 스 터 는(4 노드-2 건강-2 나 쁨)로 변 하고 클 러 스 터 는 다수의 원칙 을 만족 시 키 지 않 으 며 모든 노드 는 기록 할 수 없다(인공 적 으로 관여 하지 않 고 클 러 스 터 구성원 List 를 강제로 지정 한다).

Second-04 에서 쫓 겨 난 후:
이때 클 러 스 터 는(3 노드-3 건강-0 나 쁨)이 고 4 노드 클 러 스 터 는 3 노드 건강 클 러 스 터 로 퇴화 되 었 다.이때 클 러 스 터 는 한 노드 를 계속 나 빠 뜨리 고(3 노드-2 건강-1 나 쁨)로 변 할 수 있다.

그래서 4 노드 클 러 스 터 가 1 개 를 망 가 뜨 릴 수 있 는 지 2 개 를 망 가 뜨 릴 수 있 는 지 구체 적 으로 클 러 스 터 처리 과정 이 어느 단계 인지 봐 야 합 니 다.
PS：
우리 가 방금 묻 은 문 제 를 말 해 보 자.이 그림 은 딱 봐 도 Single 모드 인 데 화살 표 는 단 방향 이 아니 라 잘못 그린 거 아니 야?
우선 Single 모드 에서 Second 노드 는 기본적으로 쓸 수 없 지만 Second 노드 의 슈퍼-read-only 가 열 렸 기 때 문 입 니 다.
Second 노드 슈퍼-read-only=0,Second 노드 를 정상적으로 기록 할 수 있 고 다른 노드(Primary 와 다른 Second)를 동기 화 할 수 있 으 며 전송 은 Paxos 프로 토 콜 을 기반 으로 합 니 다.
기차 타기:Second 노드 가 다른 노드 를 반대로 동기 화 하 는 것 은 충돌 검 측 단계(이론 효율 이 다 중 쓰기 모델 보다 높 음)를 거치 지 않 고 검증 되 지 않 으 므 로 여러분 들 이 관심 이 있 으 면 연구 할 수 있 습 니 다.
2.비동기 연결 장애
MySQL 8.0.22 는 비동기 복제 연결 고장 전 이 를 출시 했 고 많은 친구 들 이 글 을 보 내 소 개 했 습 니 다.여기 서 저 는 간단하게 설명 하 겠 습 니 다.
1)같은 기관실 1 주 1 부터 타지 기관실 에 슬 레이 브 노드 를 따로 놓는다.

2)Master 고장,Slave-01 을 Master 로 변경,Slave-02 는 원래 Master 를 연결 할 수 없습니다

3)Slave-02 에'비동기 연결 고장 이전 설정'을 설정 하면 Slave-02 는 원래 Master 고장 을 식별 한 후 미리 정 의 된 설정 에 따라 원 Slave-01(새 Master)과 복사 관 계 를 자동 으로 시도 합 니 다.

이 기능 은 매우 좋 습 니 다.3 자 도구(예 를 들 어 MHA 의 복원 주종 관계)를 참조 하면 MySQL 원생 기능 으로 대체 할 수 있 습 니 다.
그러나 나 는 테스트 를 마치 고 또 몇 가지 의심 이 생 겼 다.
1.'비동기'복사 고장 이전,반 동기 화 구조 가 지원 되 지 않 습 니까?데이터 가 분실 되 지 않도록 확보 할 수 없 습 니까?아니면 MHA 를 완전히 대체 할 수 없 습 니까?
답:사실은 증강 반 동기 화 를 지원 합 니 다.
2.고장 전 이 된 Master List 를 미리 설정 하려 면 A 기관실 구조 가 변경 되 고 기관실 B 의 노드 를 유지 해 야 합 니까?
답:네.
3.만약 에 A 기계실 이 MGR 이 라면 MGR 의 노드(master)가 이상 하지만 서비스 와 관련 이 없 기 때문에 방문 할 수 있 습 니 다.기계실 B 노드 가 계속 연결 되 어 있 지 않 습 니까?
답:네.
그리고 MySQL 8.0.23 이 발표 되 어 이 기능 의 증 가 를 가 져 왔 습 니 다.
Slave 는 MGR 군집 을 지원 할 수 있 고 MGR 구성원 을 동적 으로 식별 하여 Master-Slave 관 계 를 구축 할 수 있 습 니 다.

마지막 으로 한 바퀴 뛰 자.
1)우선 3 노드 의 MGR 클 러 스 터 가 있 습 니 다.버 전 8.0.22(비동기 연결 고장 이전 은 Slave 의 IO Thread 에 작용 하기 때문에 Slave 는 8.0.23 버 전이 면 됩 니 다)

+----------------------------+-------------+--------------+-------------+---------------------+
| now(6)           | member_host | member_state | member_role | VIEW_ID       |
+----------------------------+-------------+--------------+-------------+---------------------+
| 2021-01-22 13:41:27.902251 | mysql-01  | ONLINE    | SECONDARY | 16112906030396799:9 |
| 2021-01-22 13:41:27.902251 | mysql-02  | ONLINE    | PRIMARY   | 16112906030396799:9 |
| 2021-01-22 13:41:27.902251 | mysql-03  | ONLINE    | SECONDARY  | 16112906030396799:9 |
+----------------------------+-------------+--------------+-------------+---------------------+

2)그리고 우 리 는 독립 된 Slave 노드 에서 Slave 에"Master 연결 고장 이전 목록"을 지정 합 니 다.

SELECT asynchronous_connection_failover_add_managed('ch1', 'GroupReplication', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1', 'mysql-02', 3306, '', 80, 60);

       ：
ch1：chanel  
GroupReplication：       ，    MGR  
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1：MGR  （   group_replication_group_name）
mysql-02：MGR    
80：Primary      （0-100），                master。
60：Second      （0-100），     Single     

3)슬 레이 브 를 위 한 복사 채널 정보 지정

CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='123456', SOURCE_HOST='mysql-02',SOURCE_PORT=3306,SOURCE_RETRY_COUNT=2,SOURCE_CONNECTION_AUTO_FAILOVER=1,SOURCE_AUTO_POSITION=1 For CHANNEL 'ch1';

4)슬 레이 브 를 시작 하고'연 결 된 이동 가능 목록'보기
io thread 를 열지 않 으 면 MGR 멤버 를 자동 으로 식별 하지 못 합 니 다.사용자 복사
rpl_user 는 MGR 노드 에서 performanceschema 는 select 권한 을 가지 고 있 습 니 다.

start slave;
SELECT * FROM performance_schema.replication_asynchronous_connection_failover;
+--------------+----------+------+-------------------+--------+--------------------------------------+
| CHANNEL_NAME | HOST   | PORT | NETWORK_NAMESPACE | WEIGHT | MANAGED_NAME             |
+--------------+----------+------+-------------------+--------+--------------------------------------+
| ch1     | mysql-01 | 3306 |          |   60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |
| ch1     | mysql-02 | 3306 |          |   80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |
| ch1     | mysql-03 | 3306 |          |   60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |
+--------------+----------+------+-------------------+--------+--------------------------------------+

5)그리고 우 리 는 my sql-02 stop groupreplication(서 비 스 를 닫 는 것 이 아 닙 니 다),
Slave 목록 에서 mysql-02 를 자동 으로 탈락 시 키 고 다른 노드 와 다시 연결 합 니 다--mysql-02(Primary):

stop group_replication;

-- Slave:
SELECT * FROM performance_schema.replication_asynchronous_connection_failover;
+--------------+----------+------+-------------------+--------+--------------------------------------+
| CHANNEL_NAME | HOST   | PORT | NETWORK_NAMESPACE | WEIGHT | MANAGED_NAME             |
+--------------+----------+------+-------------------+--------+--------------------------------------+
| ch1     | mysql-01 | 3306 |          |   80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |
| ch1     | mysql-03 | 3306 |          |   60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1 |
+--------------+----------+------+-------------------+--------+--------------------------------------+

show slave status\G
*************************** 1. row ***************************
        Slave_IO_State: Waiting for master to send event
         Master_Host: mysql-01
         Master_User: rpl_user
         Master_Port: 3306
        Connect_Retry: 60
       Master_Log_File: mybinlog.000003
     Read_Master_Log_Pos: 4904
        Relay_Log_File: mysql-01-relay-bin-ch1.000065
        Relay_Log_Pos: 439
    Relay_Master_Log_File: mybinlog.000003
       Slave_IO_Running: Yes
      Slave_SQL_Running: Yes
      ...

이로써 설정 이 완료 되 었 습 니 다.뒤에 MGR 노드 가 증가 하고 감소 하 며 Slave 는 이 목록 을 자동 으로 유지 할 수 있 습 니 다.다른 용례 는 붙 이지 않 겠 습 니 다.
PS:
슬 레이 브 가 만 든 마스터 노드(Primary)를 다른 노드(Second)에 손 으로 전환 하려 면'연 결 된 이전 가능 목록 복사'를 삭제 하고 세 컨 드 우선 순 위 를 다시 조정 하면 된다.

--     
SELECT asynchronous_connection_failover_delete_managed('ch1', 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1');


--     ，  Second     Primary
SELECT asynchronous_connection_failover_add_managed('ch1', 'GroupReplication', 'aaaaaaaaaaaa-aaaa-aaaa-aaaaaaaaaaa1', 'mysql-03', 3306, '', 60, 80);

참조 연결:
https://mysqlhighavailability.com/automatic-asynchronous-replication-connection-failover/
https://my.oschina.net/u/4591256/blog/4813037
https://dev.mysql.com/doc/refman/8.0/en/replication-functions-source-list.html
이 글 은 MySQL 8.0.23 에서 복제 구조 가 노드 자동 고장 에서 전 이 된 것 에 관 한 글 을 소개 합 니 다.더 많은 MySQL 자동 고장 이전 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 바 랍 니 다!