MySQL 주종 복제 에 관 한 몇 가지 복제 방식 에 대한 총 결

비동기 복제
MySQL 의 복 제 는 기본적으로 비동기 입 니 다.주종 복 제 는 최소한 두 개의 MYSQL 서비스 가 필요 합 니 다.이런 MySQL 서 비 스 는 서로 다른 서버 에 분포 할 수도 있 고 같은 서버 에 분포 할 수도 있 습 니 다.
MySQL 은 비동기 복제 에서 가장 흔히 볼 수 있 는 복제 장면 이다.데이터 의 완전 성 은 메 인 라 이브 러 리 BINLOG 의 분실 되 지 않 음 에 의존 합 니 다.메 인 라 이브 러 리 의 BINLOG 가 분실 되 지 않 는 다 면 메 인 라 이브 러 리 가 지연 되 더 라 도 우 리 는 BINLOG 를 통 해 잃 어 버 린 일부 데 이 터 를 수 동 으로 라 이브 러 리 에서 동기 화 할 수 있 습 니 다.
메모:메 인 라 이브 러 리 가 다운 된 경우 DBA 는 my sqlbinlog 도 구 를 통 해 메 인 라 이브 러 리 binlog 를 수 동 으로 방문 하여 부족 한 로 그 를 추출 하고 라 이브 러 리 에서 동기 화 할 수 있 습 니 다.또한 사용 가능 한 MHA 구 조 를 설정 하여 부족 한 데 이 터 를 라 이브 러 리 에서 자동 으로 추출 하거나 Global Transaction Identifiers(GTID)를 사용 하여 부족 한 binlog 를 라 이브 러 리 에서 자동 으로 추출 할 수 있 습 니 다.
MySQL 은 BINLOG 에 사무(또는 SQL 구문)를 기록 합 니 다.즉,사 무 를 지원 하 는 엔진(예 를 들 어 InnoDB)에 있어 서 모든 사 무 를 제출 할 때 BINLOG 를 써 야 합 니 다.트 랜 잭 션 이 지원 되 지 않 는 엔진(예 를 들 어 MyISAM)의 경우 SQL 구문 이 실 행 될 때마다 BINLOG 가 필요 합 니 다.Binlog 의 안전 을 위해 MySQL 은 sync 를 도입 합 니 다.binlog 인 자 는 BINLOG 가 디스크 로 새로 고침 하 는 빈 도 를 제어 합 니 다.

show variables like 'sync_binlog';

기본 적 인 상황 에서 syncbinlog=1 은 트 랜 잭 션 을 제출 하기 전에 MySQL 이 BINLOG 를 디스크 에 리 셋 해 야 한 다 는 뜻 입 니 다.그러면 데이터베이스 호스트 운영 체제 가 붕괴 되 거나 호스트 가 갑자기 전원 이 떨 어 지 는 상황 이 발생 하 더 라 도 시스템 은 prepared 상태의 트 랜 잭 션 을 가장 많이 손실 합 니 다.sync 설정binlog=1,가능 한 한 데이터 안전 을 보장 합 니 다

sync_binlog=0 은 MySQL 이 binlog 의 새로 고침 을 제어 하지 않 고 파일 시스템 에서 파일 캐 시 새로 고침 을 스스로 제어 한 다 는 뜻 입 니 다

sync_binlog=N,N 이 0 또는 1 이 아니라면 새로 고침 방식 은 syncbinlog=1 은 유사 하지만,이 때 는 N 차 binlog 제출 그룹 으로 갱신 빈 도 를 연장 합 니 다.

이상 은 전통 적 인 비동기 복제 입 니 다.MySQL 5.7 의 병렬 복제 기술(다 중 스 레 드 복제 라 고도 함)이 오기 전에 가장 많은 지적 을 받 은 것 은 효율 문제 입 니 다.slave 지연 은 고질병 입 니 다.이전에 schema 급 의 병렬 복제 가 나 타 났 지만 실제 효 과 는 좋 지 않 습 니 다.
다 중 루틴 복제
MySQL 5.7 에서 새로운 다 중 스 레 드 복제 기술 을 가 져 와 master 와 같은 schema 에서 의 데이터 가 변경 되 었 고 라 이브 러 리 에서 동시 응용 할 수 없 는 문 제 를 해결 하 는 동시에 binlog 팀 이 제출 한 장점 을 충분히 발휘 하여 라 이브 러 리 에서 Relay Log 를 동시 응용 하 는 능력 을 보장 했다.
MySQL 8.0 에서 다 중 스 레 드 복 제 는 기술 업 데 이 트 를 진행 하여 writeset 의 개념 을 도입 하 였 으 며,이전 버 전에 서 메 인 라 이브 러 리 의 같은 세 션 순서 로 여러 개의 서로 다른 대상 의 업 무 를 수행 하 였 다 면,예 를 들 어 Update A 표 의 데 이 터 를 먼저 실행 하고 Update B 표 의 데 이 터 를 실행 하 였 다 면 BINLOG 는 라 이브 러 리 에서 라 이브 러 리 로 복사 한 후에 이 두 업 무 를 병행 할 수 없다.writeset 의 도래 로 이 한 계 를 돌파 했다.
증강 반 동기 복제
앞에서 소개 한 복 제 는 비동기 작업 으로 메 인 라 이브 러 리 와 라 이브 러 리 의 데이터 사이 에 일정한 지연 이 존재 할 수 있 습 니 다.이러한 위험 이 존재 합 니 다.메 인 라 이브 러 리 에 하나의 사 무 를 기록 하고 제출 에 성 공 했 을 때 라 이브 러 리 에서 메 인 라 이브 러 리 의 BINLOG 로 그 를 받 지 못 했 을 때 메 인 라 이브 러 리 는 디스크 손상,메모리 고장,단전 등 으로 인해 의외로 지연 되 어 메 인 라 이브 러 리 에서 이 사 무 를 BINLOG 가 잃 어 버 렸 습 니 다.이때 창고 에서 이 일 을 손실 시 켜 주종 이 일치 하지 않 게 할 것 이다.
이 문 제 를 해결 하기 위해 MySQL 5.5 부터 반 동기 복 제 를 도입 했다.이때 의 기술 은 전통 적 인 반 동기 복제 라 고 부 르 는데 이 기술 이 MySQL 5.7 로 발전 한 후에 반 동기 복 제 를 강화 하 는 것 으로 발전 되 었 다.비동기 복사 시 홈 라 이브 러 리 에서 Commit 가 작업 을 제출 하고 BINLOG 로 그 를 기록 하면 클 라 이언 트 로 돌아 갈 수 있 습 니 다.그림 과 같이 BINLOG 로그 가 라 이브 러 리 로 전송 되 기 를 기다 리 지 않 아 도 됩 니 다.

한편,반 동기 복사 시 메 인 라 이브 러 리 의 모든 BINLOG 업무 가 라 이브 러 리 에서 신뢰 할 수 있 도록 복사 할 수 있 습 니 다.메 인 라 이브 러 리 는 모든 업무 가 성공 적 으로 제출 될 때마다 전단 응용 사용자 에 게 신속하게 피드백 하지 않 고 최소한 하나의 라 이브 러 리(상세 한 매개 변수 rpl 참조)를 기다 리 고 있 습 니 다.semi_sync_master_wait_for_slave_count)또한 BINLOG 사 무 를 수신 하고 중계 로 그 를 성공 적 으로 기록 한 후에 야 메 인 라 이브 러 리 는 Commit 작업 으로 클 라 이언 트 에 게 성공 적 으로 되 돌 아 왔 습 니 다.
반 동기 복 제 는 업무 가 성공 적 으로 제출 된 후에 적어도 두 개의 로그 기록 이 있 고 하 나 는 메 인 라 이브 러 리 의 BINLOG 로그 에 있 으 며 다른 하 나 는 라 이브 러 리 의 중계 로그 Relay Log 에 있어 데이터 의 완전 성 을 더욱 보장 합 니 다.
전통 적 인 반 동기 복제 에서 메 인 라 이브 러 리 는 BINLOG 에 데 이 터 를 쓰 고 Commit 작업 을 수행 한 후에 라 이브 러 리 에서 의 ACK,즉 라 이브 러 리 에서 Relay Log 를 기록 한 후에 데 이 터 를 떨 어 뜨 려 메 인 라 이브 러 리 메시지 에 되 돌려 주 고 메 인 라 이브 러 리 가 전단 응용 작업 에 성공 할 수 있 음 을 알 립 니 다.그러면 문제 가 발생 할 수 있 습 니 다.즉,실제 메 인 라 이브 러 리 는 이 사무 Commit 를 사무 엔진 층 으로 옮 겼 습 니 다.응용 프로그램 은 데이터 가 변 한 것 을 볼 수 있 습 니 다.돌아 오 기 를 기다 리 고 있 을 뿐 입 니 다.만약 에 메 인 라 이브 러 리 가 지연 되면 라 이브 러 리 에서 Relay Log 를 쓰 지 못 할 수도 있 습 니 다.메 인 라 이브 러 리 가 일치 하지 않 을 수도 있 습 니 다.증강 반 동기 복 제 는 이 문 제 를 해결 하기 위해 마이크로 조정 을 한 것 이다.즉,메 인 라 이브 러 리 에서 BINLOG 에 데 이 터 를 쓴 후에 라 이브 러 리 에서 응답 하 는 ACK 를 기다 리 기 시작 했다.적어도 라 이브 러 리 에서 Relay Log 를 기록 한 후에 데 이 터 를 떨 어 뜨 린 다음 에 메 인 라 이브 러 리 에 메 시 지 를 되 돌려 주 고 메 인 라 이브 러 리 에 Commit 작업 을 수행 할 수 있다 고 알 린 다음 에 메 인 라 이브 러 리 는 사무 엔진 층 에 제출 하기 시작 했다.응용 할 때 데이터 가 변 한 것 을 볼 수 있 습 니 다.증강 반 동기 복제 의 대체적인 절 차 는 다음 그림 과 같다.

반 동기 복사 모드 에서 BINLOG 로 그 를 라 이브 러 리 에서 전송 할 때 라 이브 러 리 가 지연 되 거나 네트워크 가 지연 되 어 BINLOG 가 라 이브 러 리 에서 전송 되 지 않 는 다 면 메 인 라 이브 러 리 의 사 무 는 일정 시간 동안 기 다 립 니 다(시간 은 매개 변수 rplsemi_sync_master_timeout 설정 의 밀리초 수 결정)BINLOG 가 이 기간 동안 라 이브 러 리 에서 성공 적 으로 전송 되 지 못 하면 MySQL 은 자동 으로 비동기 모드 로 복 사 를 조정 하여 클 라 이언 트 에 제출 한 결 과 를 정상적으로 되 돌려 줍 니 다.
세 미 동기 복 제 는 어느 정도 라 이브 러 리 간 네트워크 상황 에 달 려 있 고 왕복 지연 RTT 가 작 을 수록 라 이브 러 리 의 실시 성 이 좋다 는 것 을 결정 한다.통속 적 으로 말 하면 주종 라 이브 러 리 간 의 네트워크 가 빠 를 수록 라 이브 러 리 에서 실시 간 으로 이 루어 진다.
주의:왕복 지연 RTT(Round-trip Time)는 컴퓨터 네트워크 에서 중요 한 성능 지표 입 니 다.이 는 송신 단 에서 데 이 터 를 보 내기 시작 하여 송신 단 에서 수신 단 까지 의 확인 을 표시 합 니 다.모두 겪 은 시간(여기 가 좀 어 긋 날 수 있 습 니 다.TCP 세 번 악수 하기 전 두 번 의 악수 로 이해 할 수 있 습 니 다)입 니 다.
총결산
MySQL 주종 복사 에 관 한 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 MySQL 주종 복사 방식 에 관 한 내용 은 예전 의 글 을 검색 하거나 아래 의 관련 글 을 계속 찾 아 보 세 요.앞으로 도 많은 응원 부 탁 드 리 겠 습 니 다!