MySQL 의 병렬 복 제 를 쉽게 설명 합 니 다.

1.병렬 복사 배경
우선,왜 병행 복제 라 는 개념 이 있 을 까?
1.DBA 는 MySQL 의 복 제 는 binlog 에 기반 한 것 임 을 알 아야 한다. 
2.MySQL 복 제 는 두 부분,IO 스 레 드 와 SQL 스 레 드 를 포함한다. 
3.IO 스 레 드 는 주로 Master 가 전달 한 binlog 를 끌 어 다가 relay log 에 기록 하 는 데 사 용 됩 니 다. 
4.SQL 스 레 드 는 주로 relay log 를 분석 하고 slave 에 적용 합 니 다. 
5.아무래도 IO 와 SQL 스 레 드 는 단일 스 레 드 이 고 master 는 다 중 스 레 드 이기 때문에 지연 이 있 을 수 밖 에 없습니다.이 문 제 를 해결 하기 위해 다 중 스 레 드 가 생 겨 났 습 니 다. 
6.IO 다 중 스 레 드?  
 6.1 IO 는 다 중 스 레 드 가 필요 없습니다.IO 스 레 드 는 병목 이 아니 기 때 문 입 니 다. 
7.SQL 다 중 스 레 드?
 7.1 맞습니다.현재 최신 5.6,5.7,8.0 은 모두 SQL 스 레 드 에서 다 중 스 레 드 를 실현 하여 slave 의 병행 도 를 향상 시 켰 습 니 다.  
다음은 MySQL 의 병행 복제 노력 과 성 과 를 살 펴 보 자.
중점
병행 할 수 있 느 냐 없 느 냐 는 여러 사무 간 에 자물쇠 충돌 이 있 느 냐 가 관건 이다.아래 의 병렬 복제 원 리 는 자물쇠 충돌 을 피 하 는 방법 을 보 는 것 이다.
3.MySQL 5.6 schema 기반 병렬 복사
slave-parallel-type=DATABASE(라 이브 러 리 별 트 랜 잭 션,잠 금 충돌 없 음)
앞서 말 했 듯 이 병렬 복 제 는 slave 가 가능 한 한 다 중 스 레 드 를 달 리 는 것 이 목적 입 니 다.물론 라 이브 러 리 등급 을 바탕 으로 하 는 다 중 스 레 드 도 방식 입 니 다.(라 이브 러 리 의 업무 에 따라 잠 금 충돌 이 없습니다)
먼저 장점:실현 은 상대 적 으로 간단 하고 사용자 에 게 도 간단 하 다.
그리고 단점:라 이브 러 리 를 기반 으로 하기 때문에 병행 하 는 입도 가 매우 굵 습 니 다.현재 많은 회사 의 구 조 는 라 이브 러 리 인 스 턴 스 입 니 다.이런 구조 에 대해 5.6 의 병행 복 제 는 어 쩔 수 없습니다.물론 주 된 일의 우선 순위 도 있 고 5.6 에 도 큰 문제 다.
말 이 많 지 않 으 니 그림 을 한 장 찍 어 라

4.MySQL 5.7 group commt 기반 병렬 복사
slave-parallel-type=LOGICAL_CLOCK:Commit-Parent-Based 모드(같은 그룹의 업무[last-commt 동일],잠 금 충돌 이 없습니다.같은 그룹,충돌 이 없 을 것 입 니 다.그렇지 않 으 면 같은 그룹 이 될 수 없습니다)
slave-parallel-type=LOGICAL_CLOCK:Lock-Based 모드(같은 그룹의 업무 가 아니 더 라 도 업무 간 에 잠 금 충돌[prepare 단계]이 없 으 면 동시 다발 할 수 있 습 니 다.같은 그룹 이 아 닙 니 다.N 개의 사무 prepare 단계 만 겹 칠 수 있다 면 잠 금 충돌 이 없 음 을 의미 합 니 다)
group commt,이전 글 에 대한 상세 한 설명 이 있 습 니 다.여 기 는 설명 이 많 지 않 습 니 다.MySQL 5.7 은 그룹 에서 제출 할 때 각 그룹의 업무 에 표 시 를 하기 도 했 는데 지금 생각해 보면 MTS 를 편리 하 게 진행 하기 위 한 것 이 아 닐 까 합 니 다.
저희 가 먼저 binlog 를 보 겠 습 니 다.

last_committed=0 sequence_number=1
last_committed=1 sequence_number=2
last_committed=2 sequence_number=3
last_committed=3 sequence_number=4
last_committed=4 sequence_number=5
last_committed=4 sequence_number=6
last_committed=4 sequence_number=7
last_committed=6 sequence_number=8
last_committed=6 sequence_number=9
last_committed=9 sequence_number=10

4.1 Commit-Parent-Based 모드

4.2 잠 금 기반 모드

5.MySQL 8.0 write-set 기반 병렬 복사
메 인 키 기반 충돌 검출(binlogtransaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION,수 정 된 row 의 메 인 키 나 비어 있 지 않 은 키 만 충돌 하지 않 으 면 병행 할 수 있 습 니 다)
5.7.22 도 write-set 메커니즘 을 지원 했다.
사무 의존 관계:
COMMIT_ORDERE:그룹 기반 제출 방식 계속
WRITESET:쓰기 집합 기반 사무 의존 결정
WRITESET_SESSION:쓰기 집합 을 기반 으로 하지만 같은 session 의 사 무 는 같은 last 가 없습니다.committed
사무 검출 알고리즘:binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSIONMySQL 은 제출 한 트 랜 잭 션 HASH 값 을 저장 하 는 변수 가 있 습 니 다.제출 한 모든 사무소 에서 수정 한 메 인 키(또는 유일한 키)의 값 은 hash 를 거 친 후에 그 변수의 집합 과 비교 하여 줄 이 충돌 하 는 지 판단 하고 이 를 통 해 의존 관 계 를 확인 합 니 다.
여기 서 말 하 는 변 수 는 이 설정 을 통 해 크기 를 설정 할 수 있 습 니 다:binlogtransaction_dependency_history_size
이러한 입 도 는 row 단계 에 이 르 렀 습 니 다.이때 병행 하 는 입도 가 더욱 정교 하고 병행 하 는 속도 가 빠 를 것 입 니 다.어떤 경우 에는 slave 의 병행 도가 master 를 뛰 어 넘 는 것 도 지나 치지 않 습 니 다(master 는 단일 스 레 드 의 쓰기 이 고 slave 도 병행 재생 할 수 있 습 니 다)
6.어떻게 슬 레이 브 의 병행 복사 와 master 의 업무 수행 순서 가 일치 합 니까?
5.7.19 이후 설치 가능transaction_write_set_extraction = OFF| XXHASH64 | MURMUR32공식 설명: 
For multithreaded slaves, enabling this variable ensures that transactions are externalized on the slave in the same order as they appear in the slave's relay log.  
Setting this variable has no effect on slaves for which multithreading is not enabled.  
All replication threads (for all replication channels if you are using multiple replication channels) must be stopped before changing this variable.  
--log-bin and --log-slave-updates must be enabled on the slave.  
In addition --slave-parallel-type must be set to LOGICAL_CLOCK. 
Once a multithreaded slave has been started, transactions can begin to execute in parallel.  
With slave_preserve_commit_order enabled, the executing thread waits until all previous transactions are committed before committing.  
While the slave thread is waiting for other workers to commit their transactions it reports its status as Waiting for preceding transaction to commit.
대체적으로 실현 원 리 는 excecution 단계 에서 병행 할 수 있 고 binlog flush 일 때 순서대로 진행 하 는 것 이다.엔진 층 제출 시 binlogorder_commt 도 줄 서기 순서 완성. 
이 인 자 를 설정 하면 master 가 어떻게 병행 하 는 지,slave 는 어떻게 병행 하 는 지 하 는 것 이다.
총결산
이상 은 이 글 의 전체 내용 입 니 다.본 논문 의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 참고 학습 가치 가 있 기 를 바 랍 니 다.궁금 한 점 이 있 으 시 면 댓 글 을 남 겨 주 셔 서 저희 에 대한 지지 에 감 사 드 립 니 다.