MySQL 5.7 병행 복제 원리 및 실현

조금 만 알 아 본 데이터 의 운영 비 는 MySQL 5.5 와 이전 에는 단일 SQL 스 레 드 재생 이 었 다 는 것 을 알 수 있 습 니 다.Master QPS 가 조금 만 높 으 면 위 에서 지연 되 었 습 니 다.5.6 은 라 이브 러 리 를 바탕 으로 하 는 병렬 재생 체제 입 니 다.여러 라 이브 러 리 가 있어 야 복사 가 가능 합 니 다.5.7 은 그룹의 병렬 재생 을 바탕 으로 같은 그룹의 사 무 를 병행 하여 재생 하여 지연 문 제 를 해결 할 수 있 습 니 다.
MySQL 5.7 동시 복제 시대
모두 가 알다 시 피 MySQL 의 복제 지연 은 줄곧 비난 을 받 아 온 문제 중 하나 이다.그러나 Inside 군 이전의 두 블 로그(1,2)에서 MySQL 5.7 버 전 은'진정한'병행 복제 기능 을 지 원 했 고 공식 적 으로 enhanced multi-threaded slave(MTS 로 약칭)라 고 불 렸 기 때문에 복제 지연 문 제 는 크게 개선 되 었 다.심지어 Inside 군 이 있 는 왕 이 커 머 스 애플 리 케 이 션 에서 몇 시간 동안 지연 되 었 던 문 제 를 완전히 제거 했다.그러나 많은 동료 들 이 역사 에 기 록 될'위대 함'의 특성 을 모 르 고 나 누 는 것 으로 나 타 났 다.한 마디 로 5.7 버 전 이후 복제 지연 문 제 는 영원히 존재 하지 않 는 다.
MySQL 5.6 병렬 복제 구조
물론 MySQL 5.6 버 전도 이른바 병행 복 제 를 지원 하지만 그 병행 은 schema 기반,즉 라 이브 러 리 기반 이다.사용자 의 MySQL 데이터베이스 인 스 턴 스 에 여러 개의 schema 가 존재 한다 면 컴퓨터 에서 복사 하 는 속도 에 큰 도움 이 될 수 있 습 니 다.MySQL 5.6 병렬 복제 의 구 조 는 다음 과 같다.

위의 그림 의 빨간색 테두리 부분 은 병행 복 제 를 실현 하 는 관건 이다.MySQL 5.6 버 전에 Slave 서버 에는 두 개의 스 레 드 I/O 스 레 드 와 SQL 스 레 드 가 있 었 습 니 다.I/O 스 레 드 는 바 이 너 리 로 그 를 수신 하고 SQL 스 레 드 는 바 이 너 리 로 그 를 재생 합 니 다.MySQL 5.6 버 전에 서 병렬 복사 기능 을 켜 면 SQL 스 레 드 는 coordinator 스 레 드 로 바 뀌 고 coordinator 스 레 드 는 주로 이전 두 부분의 내용 을 책임 집 니 다.
4.567917.병행 실행 이 가능 하 다 고 판단 되면 워 커 스 레 드 에서 사 무 를 수행 하 는 바 이 너 리 로 그 를 선택 하 십시오4.567917.이 작업 이 DDL 이거 나 트 랜 잭 션 크로스 schema 작업 이 라 고 판단 되면 모든 worker 스 레 드 가 실 행 된 후에 현재 로 그 를 실행 합 니 다이 는 coordinator 스 레 드 가 워 커 스 레 드 에 만 로 그 를 보 내 는 것 이 아니 라 로 그 를 재생 할 수 있 지만 모든 병행 가능 한 작업 은 워 커 스 레 드 에 의 해 이 루어 집 니 다.coordinator 스 레 드 와 worker 는 전형 적 인 생산자 와 소비자 모델 이다.
상기 메커니즘 은 schema 를 바탕 으로 하 는 병행 복 제 를 실현 하 는 데 두 가지 문제 가 존재 합 니 다.먼저 crash safe 기능 이 쉽 지 않 습 니 다.나중에 실 행 될 수 있 는 사 무 는 병행 복사 관계 로 먼저 실 행 될 수 있 기 때문에 crash 가 발생 할 때 이 부분의 처리 논 리 는 비교적 복잡 합 니 다.코드 상 으로 는 5.6 에 Low-ater-Mark 표 시 를 도입 하여 이 문 제 를 해결 하 였 으 며,디자인 상 으로 는 로그 의 멱 등 성 을 빌려 이 문 제 를 해결 하 기 를 희망 하 였 으 나,5.6 의 바 이 너 리 로그 재생 은 아직 멱 등 성 을 실현 하지 못 하 였 다.또 하나의 가장 관건 적 인 문 제 는 이러한 디자인 의 병행 복사 효과 가 높 지 않다 는 것 이다.만약 에 사용자 인 스 턴 스 가 하나의 라 이브 러 리 만 있다 면 병행 재생 을 실현 할 수 없고 심지어 성능 이 원래 의 단일 스 레 드 보다 더욱 떨 어 질 것 이다.단일 라 이브 러 리 다 표 는 다 중 라 이브 러 리 다 표 보다 더 흔히 볼 수 있 는 상황 이다.
MySQL 5.7 그룹 기반 병렬 복사
MySQL 5.7 이 야 말로 진정한 병행 복제 라 고 할 수 있다.그 중에서 가장 중요 한 이 유 는 slave 서버 의 재생 과 호스트 가 일치 하 는 것 이다.즉,master 서버 에서 어떻게 병행 하 는 slave 에서 어떻게 병행 재생 하 는 지 하 는 것 이다.
MySQL 5.7 병행 복제 의 사상 은 간단 하고 이해 하기 쉽다.한 마디 로 하면 한 그룹 이 제출 한 업 무 는 모두 병행 재생 할 수 있다.왜냐하면 이 업 무 는 모두 업무 의 prepare 단계 에 들 어 갔 기 때문에 업무 간 에 어떠한 충돌 도 없다 는 것 을 의미한다(그렇지 않 으 면 제출 할 수 없다).

MySQL 5.6 라 이브 러 리 기반 병렬 복 제 를 호 환 하기 위해 5.7 에 새로운 변수 slave-parallel-type 을 도 입 했 습 니 다.설정 할 수 있 는 값 은 다음 과 같 습 니 다.
DATABASE:기본 값,라 이브 러 리 기반 병렬 복사 방식

LOGICAL_CLOCK:그룹 이 제출 한 병렬 복사 방식 을 기반 으로 합 니 다

병렬 복 제 를 지원 하 는 GTID
원본 MySQL 이 이러한 정 보 를 제공 하지 않 았 기 때문에 업무 가 한 그룹 에 있 는 지 아 닌 지 를 어떻게 알 아야 하 는가 가 또 하나의 문제 입 니 다.MySQL 5.7 버 전에 서 는 그룹 이 제출 한 정 보 를 GTID 에 저장 하 는 방식 으로 설계 됐다.사용자 가 GTID 기능 을 켜 지 않 으 면 인자 gtidmode 를 OFF 로 설정 할 까요?그래서 MySQL 5.7 은 Anonymous 라 고 불 린 다.Gtid 의 바 이 너 리 로그 이벤트 형식:

mysql> SHOW BINLOG EVENTS in 'mysql-bin.000006';
 +------------------+-----+----------------+-----------+-------------+-----------------------------------------------+
 | Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
 +------------------+-----+----------------+-----------+-------------+-----------------------------------------------+
 | mysql-bin.000006 | 4 | Format_desc | 88 | 123 | Server ver: 5.7.7-rc-debug-log, Binlog ver: 4 |
 | mysql-bin.000006 | 123 | Previous_gtids | 88 | 194 | f11232f7-ff07-11e4-8fbb-00ff55e152c6:1-2 |
 | mysql-bin.000006 | 194 | Anonymous_Gtid | 88 | 259 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
 | mysql-bin.000006 | 259 | Query | 88 | 330 | BEGIN |
 | mysql-bin.000006 | 330 | Table_map | 88 | 373 | table_id: 108 (aaa.t) |
 | mysql-bin.000006 | 373 | Write_rows | 88 | 413 | table_id: 108 flags: STMT_END_F |
 .....

이것 은 MySQL 5.7 버 전에 서 GTID 를 켜 지 않 아 도 모든 업무 가 시작 되 기 전에 Anonymous 가 존재 한 다 는 것 을 의미한다.Gtid,이 GTID 에는 그룹 이 제출 한 정보 가 존재 합 니 다.
LOGICAL_CLOCK
그러나 상기 SHOW BINLOG EVENTS 를 통 해 저 희 는 관련 팀 이 제출 한 어떠한 정보 도 발견 하지 못 했 습 니 다.그러나 my sqlbinlog 도 구 를 통 해 사용 자 는 그룹 이 제출 한 내부 정 보 를 발견 할 수 있 습 니 다.

# mysqlbinlog mysql-bin.0000006 | grep last_committed
#150520 14:23:11 server id 88 end_log_pos 259 CRC32 0x4ead9ad6 GTID last_committed=0 sequence_number=1
#150520 14:23:11 server id 88 end_log_pos 1483 CRC32 0xdf94bc85 GTID last_committed=0 sequence_number=2
#150520 14:23:11 server id 88 end_log_pos 2708 CRC32 0x0914697b GTID last_committed=0 sequence_number=3
#150520 14:23:11 server id 88 end_log_pos 3934 CRC32 0xd9cb4a43 GTID last_committed=0 sequence_number=4
#150520 14:23:11 server id 88 end_log_pos 5159 CRC32 0x06a6f531 GTID last_committed=0 sequence_number=5
#150520 14:23:11 server id 88 end_log_pos 6386 CRC32 0xd6cae930 GTID last_committed=0 sequence_number=6
#150520 14:23:11 server id 88 end_log_pos 7610 CRC32 0xa1ea531c GTID last_committed=6 sequence_number=7
...

원래 의 바 이 너 리 로그 보다 last 가 많은 것 을 발견 할 수 있 습 니 다.committed 와 sequencenumber，last_committed 는 트 랜 잭 션 을 제출 할 때,지난번 트 랜 잭 션 에서 제출 한 번 호 를 표시 합 니 다.만약 트 랜 잭 션 이 같은 last 를 가지 고 있다 면.committed,이 사 무 는 모두 한 그룹 내 에서 병행 재생 이 가능 하 다 는 뜻 입 니 다.예 를 들 어 상기 lastcommitted 0 의 사 무 는 6 개 로 팀 이 제출 할 때 6 개의 사 무 를 제출 했 음 을 나타 내 며,이 6 개의 사 무 는 컴퓨터 에서 병행 재생 할 수 있 습 니 다.
위의 lastcommitted 와 sequencenumber 는 소위 LOGICAL 을 대표 합 니 다.CLOCK。먼저 소스 코드 에서 LOGICAL 에 대해 서...CLOCK 의 정의:

class Logical_clock
 {
 private:
 int64 state;
 /*
 Offset is subtracted from the actual "absolute time" value at
 logging a replication event. That is the event holds logical
 timestamps in the "relative" format. They are meaningful only in
 the context of the current binlog.
 The member is updated (incremented) per binary log rotation.
 */
 int64 offset;
 ......

state 는 자체 적 으로 증가 하 는 값 입 니 다.offset 는 바 이 너 리 로그 가 rotate 가 발생 할 때마다 업데이트 되 고 rotate 가 발생 할 때의 state 값 을 기록 합 니 다.사실 state 와 offset 은 전역 의 계수 값 을 기록 하고 바 이 너 리 로그 에 존재 하 는 것 은 현재 파일 의 상대 값 입 니 다.LOGICAL 사용CLOCK 의 장면 은 다음 과 같다.

class MYSQL_BIN_LOG: public TC_LOG
 {
 ...
 public:
 /* Committed transactions timestamp */
 Logical_clock max_committed_transaction;
 /* "Prepared" transactions timestamp */
 Logical_clock transaction_counter;
 ...

클래스 MYSQL 을 볼 수 있 습 니 다.BIN_LOG 에서 두 개의 Logical 을 정 의 했 습 니 다.clock 의 변수:

max_c ommitted_transaction:마지막 그룹 이 제출 했 을 때의 logical 기록clock,상기 my sqlbinlog 의 last 를 대표 합 니 다.committed

transaction_counter:현재 그룹 이 제출 한 각 사 무 를 기록 하 는 logcialclock,상기 my sqlbinlog 의 sequence 를 대표 합 니 다.numbe

병렬 복제 테스트
아래 그림 은 MTS 를 켜 면 slave 서버 의 QPS 를 보 여 줍 니 다.테스트 도 구 는 sysbench 의 단일 표 전체 update 테스트 입 니 다.테스트 결 과 는 16 개의 스 레 드 에서 성능 이 가장 좋 은 것 으로 나 타 났 습 니 다.컴퓨터 의 QPS 에서 25000 이상 에 이 를 수 있 고 병렬 실행 스 레 드 를 32 까지 추가 하 는 것 은 더 높 은 향상 을 가 져 오지 않 았 습 니 다.한편,원래 의 단일 스 레 드 재생 QPS 는 4000 정도 에 불과 하 다.이 를 통 해 MySQL 5.7 MTS 가 가 져 온 성능 향상 을 알 수 있 고 테스트 한 것 은 단일 표 이기 때문에 MySQL 5.6 의 MTS 체 제 는 전혀 무력 하 다.
 
MySQL 5.7 병렬 복사
병렬 복사 설정 및 변조
master_info_repository
MTS 기능 오픈 후 매개 변수 masterinfo_repostitory 는 TABLE 로 설정 하여 성능 을 50%~80%향상 시 킬 수 있 습 니 다.이 는 병렬 복사 가 열 리 면 원 master.info 라 는 파일 에 대한 업데이트 가 크게 향상 되 고 자원 경쟁 도 커지 기 때문이다.이전 InnoSQL 버 전에 서 master.info 파일 을 새로 고 치 는 빈 도 를 조절 하기 위해 파 라 메 터 를 추 가 했 습 니 다.심지어 이 파일 을 새로 고치 지 않 아 도 됩 니 다.이 파일 을 새로 고 칠 필요 가 없 기 때 문 입 니 다.즉,master-info.log 에 따라 이 파일 을 복구 하 는 것 자체 가 믿 을 수 없습니다.MySQL 5.7 에서 Inside 군 은 master 를 추천 합 니 다.info_reposcory 는 이 부분의 비용 을 줄 이기 위해 TABLE 로 설정 되 어 있 습 니 다.
slave_parallel_workers
slaveparallel_workers 를 0 으로 설정 하면 MySQL 5.7 을 원 스 레 드 로 복사 하지만 slaveparallel_workers 가 1 로 설정 되면 SQL 스 레 드 기능 이 coordinator 스 레 드 로 바 뀌 지만 워 커 스 레 드 1 개 만 재생 되 고 단일 스 레 드 복사 입 니 다.그러나 이 두 가지 성능 은 또 약간의 차이 가 있 습 니 다.coordinator 스 레 드 의 퍼 가기 가 한 번 더 많아 졌 기 때문에 slaveparallel_workers=1 의 성능 은 0 보다 오히려 떨 어 졌 고 Inside 군의 테스트 에서 20%정도 의 성능 이 떨 어 졌 습 니 다.다음 그림 과 같 습 니 다.
MySQL 5.7 병렬 복제
여기 서 또 다른 문 제 를 도입 했다.호스트 의 부하 가 크 지 않 으 면 그룹 이 제출 하 는 효율 이 높 지 않 고 각 그룹 이 제출 하 는 업무 수량 이 1 개 에 불과 할 가능성 이 높다.그러면 컴퓨터 에서 재생 할 때 병렬 복 제 를 시 작 했 지만 성능 이 오히려 기 존의 단일 스 레 드 보다 더 나 쁜 현상 이 발생 할 수 있다.즉,지연 이 오히려 커진다.똑똑 한 얘 들 아,이거 최적화 할 생각 있어?
향 상 된 멀 티 스 레 드 슬 레이 브 설정
이렇게 많아

# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

병렬 복제 모니터링
복 제 된 모니터링 은 여전히 SHOW SLAVE STATUS\G 를 통과 할 수 있 지만 MySQL 5.7 은 performanceschema 구조 에서 다음 과 같은 메타 데이터 테이블 이 많아 지면 사용 자 는 더욱 세밀 하 게 모니터링 할 수 있다.

mysql> show tables like 'replication%';
 +---------------------------------------------+
 | Tables_in_performance_schema (replication%) |
 +---------------------------------------------+
 | replication_applier_configuration |
 | replication_applier_status |
 | replication_applier_status_by_coordinator |
 | replication_applier_status_by_worker |
 | replication_connection_configuration |
 | replication_connection_status |
 | replication_group_member_stats |
 | replication_group_members |
 +---------------------------------------------+
 8 rows in set (0.00 sec)

총결산
MySQL 5.7 에서 출시 한 Enhanced Multi-Threaded Slave 는 MySQL 을 수 십 년 동안 괴 롭 혔 던 복사 지연 문 제 를 해결 하고 무식 한 PostgreSQL 사용자 들 에 게 MySQL 에 대한 인상 에 머 물 지 말 라 고 다시 한 번 일 깨 워 주 었 다.물리 적 복사 도 논리 적 복제 보다 유리 한 것 은 아니 며 MySQL 5.7 의 MTS 는 지연 문 제 를 충분히 해결 할 수 있다.
Reference:
-  http://www.ttlsa.com/mysql/mysql-5-7-enhanced-multi-thread-salve/
-  http://moguhu.com/article/detail?articleId=129
-  https://www.codercto.com/a/63073.html
-  https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_preserve_commit_order
MySQL 5.7 병행 복제 원리 및 실현 에 관 한 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 관련 MySQL 5.7 병행 복제 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 바 랍 니 다!