MySQL 쌍 활 동기 복제 네 가지 해결 방안

데이터 의 실시 간 동기 화 에 있어 그 핵심 은 로 그 를 바탕 으로 이 루어 져 야 한 다 는 것 이다.정확 한 실시 간 데이터 동기 화 를 실현 할 수 있 고 로 그 를 바탕 으로 데이터베이스 자체 가 디자인 과 실현 에 어떠한 추가 적 인 제약 도 요구 하지 않 는 다.
MySQL 기반 주 동기 화 프로젝트 

이것 은 흔히 볼 수 있 는 방안 이다.일반적으로 중 소형 규모 일 때 이런 구 조 를 사용 하 는 것 이 가장 편리 하 다.
두 노드 는 간단 한 더 블 메 인 모드 를 사용 할 수 있 고 전용 회선 으로 연결 할 수 있 습 니 다.masterA 노드 가 고장 난 후,연결 을 사용 하여 master 로 빠르게 전환B 노드,반대로 도 마찬가지다.몇 가지 주의해 야 할 부분 이 있 습 니 다.뇌 가 갈 라 지 는 상황 에서 두 노드 가 같은 데 이 터 를 기록 하여 충돌 을 일 으 키 는 동시에 두 노드 의 autoincrement_increment(자가 성장)와 autoincrement_offset(시작 값 증가)을 다른 값 으로 설정 합 니 다.그 목적 은 master 노드 가 예상 치 못 하 게 지연 되 는 것 을 피하 기 위해 일부 binlog 가 slave 에 제때에 복사 되 지 못 해 slave 가 새로 기록 한 데이터 의 자체 부가 가치 와 원래 master 에서 충돌 할 수 있 기 때문에 처음부터 잘못 되 었 다.물론,만약 에 적당 한 잘못 사용 체제 가 주종 의 자체 증가 ID 충돌 을 해결 할 수 있다 면 이렇게 하지 않 아 도 됩 니 다.업 데 이 트 된 데이터 버 전 5.7+를 사용 하면 다 중 스 레 드 복사 방식 으로 복사 지연 을 어느 정도 낮 출 수 있 습 니 다.또한 복사 지연 에 특히 민감 한 또 다른 예비 방안 은 semi-sync 반 동기 복사 입 니 다.기본적으로 지연 이 없습니다.그러나 업무 병행 성능 은 어느 정도 손실 이 있 을 수 있 으 며,특히 양 방향 으로 쓸 때 는 종합 적 으로 평가 해 결정 해 야 한다.

Galera 복제 방안 기반 
Galera 는 Codership 이 제공 하 는 다 중 메 인 데이터 동기 화 복제 메커니즘 으로 여러 노드 간 의 데이터 동기 화 복제 와 읽 기와 쓰 기 를 실현 할 수 있 으 며 데이터베이스 서비스의 높 은 사용 가능 성과 데이터 일치 성 을 보장 할 수 있다.Galera 를 바탕 으로 하 는 높 은 사용 가능 방안 은 주로 MariaDB Galera Cluster 와 Percona XtraDB Cluster(PXC 로 약칭)가 있다.



현재 PXC 는 비교적 많이 사용 되 고 데이터 가 엄격 하고 일치 하 며 특히 전자상거래 류 응용 에 적합 합 니 다.그러나 PXC 도 한계 가 있 습 니 다.만약 에 병행 사 무 량 이 많 으 면 InfiniBand 네트워크 를 사용 하여 네트워크 지연 을 낮 추 는 것 을 권장 합 니 다.PXC 는 쓰기 확대 와 짧 은 효과 가 존재 하기 때문에 병행 효율 에 큰 손실 이 있 습 니 다.semi-sync 반 동기 복제 와 같 습 니 다.Gelera 는 실제 적 으로 세 개의 노드 만 사용 할 수 있 고 네트워크 디 더 링 으로 인 한 성능 과 안정성 습관 적 인 문제 이다.
그룹 복제 기반 방안 

Paxos 프로 토 콜 을 통 해 데이터베이스 클 러 스 터 노드 데이터 의 강력 한 일치 보증 을 제공 합 니 다.MGR 은 정확히 말 하면 MySQL 이 공식 적 으로 내 놓 은 사용 가능 한 해결 방안 입 니 다.네 이 티 브 복제 기술 을 바탕 으로 플러그 인의 방식 으로 제공 하고 클 러 스 터 간 의 모든 노드 를 기록 할 수 있 으 며 하나의 클 러 스 터 의 쓰기 성능 을 해결 합 니 다.모든 노드 는 읽 고 쓸 수 있 으 며 네트워크 파 티 션 으로 인 한 뇌 균열 문 제 를 해결 할 수 있 습 니 다.복사 데이터 의 신뢰성 을 향상 시 키 지만 현실 은 잔혹 합 니 다.현재 맛 보 는 것 이 많 지 않 습 니 다.또한 InnoDB 표 만 지원 합 니 다.또한 표 마다 반드시 메 인 키 가 있어 야 합 니 다.write set 의 충돌 검 사 를 할 때 GTID 특성 을 열 어야 합 니 다.바 이 너 리 로그 형식 은 ROW 로 설정 하여 주 와 write set 을 선택해 야 합 니 다.
COMMIT 는 실 패 를 초래 할 수 있 습 니 다.스냅 샷 트 랜 잭 션 격 리 단계 와 같은 실패 장면 입 니 다.현재 MGR 클 러 스 터 는 최대 9 개의 노드 를 지원 합 니 다.save point 특성 에 외부 키 가 지원 되 지 않 아 전체 적 인 제약 검사 와 일부 스크롤 백 을 할 수 없습니다.바 이 너 리 로 그 는 binlog event checksum 을 지원 하지 않 습 니 다.
canal 기반 프로젝트
데이터 뱅 크 의 실시 간 동기 화 에 대해 알 리 바 바 는 전문 적 으로 오픈 소스 프로젝트,즉 otter 를 통 해 분포 식 데이터 뱅 크 의 동기 화 복 제 를 실현 하 는데 그 핵심 사상 은 데이터 뱅 크 의 증분 데이터 로 그 를 얻어 실시 간 동기 화 복 제 를 하 는 것 이다.따라서 otter 자 체 는 또 다른 오픈 소스 프로젝트 인 canal 에 의존 하고 이 프로젝트 의 중점 은 증분 데이터베이스 동기 화 로그 정 보 를 얻 는 것 입 니 다.
현재 otter 의 중점 은 mysql 간 의 데이터베이스 동기 복 제 를 실현 하 는 것 이다.기본적으로 유사 한 기술 을 이용 하여 두 mysql 데이터베이스 간 의 양 방향 동기 데이터베이스 복 제 를 실현 하 는 것 이다.이 양 방향 자 체 는 A->B 도 되 고 B->A 도 되 며 특정한 시간 에 노드 자체 가 단 방향 이라는 것 을 주의해 야 한다.
주종 복 제 는 세 단계 로 나 뉜 다.

master 는 바 이 너 리 로그(binary log)에 기록 합 니 다.(이 기록 들 은 바 이 너 리 로그 이벤트 라 고 합 니 다.binary log events 는 show binlog events 를 통 해 볼 수 있 습 니 다)
slave 는 master 의 binary log events 를 중계 로그(relay log)로 복사 합 니 다.
slave 는 중계 로그 의 이 벤트 를 다시 만 들 고 자신의 데 이 터 를 반영 합 니 다.
canal 원 리 는 상대 적 으로 간단 하 다.

canal 시 뮬 레이 션 mysql slave 의 상호작용 프로 토 콜,mysql slave 로 위장,mysql master 에 dump 프로 토 콜 보 내기
my sql master 는 dump 요청 을 받 고 binary log 를 slave(즉,canal)에 전송 하기 시 작 했 습 니 다.
canal 분석 binary log 대상(원본 byte 흐름)
참고
총결산
위 에서 말 한 것 은 편집장 님 께 서 소개 해 주신 MySQL 쌍 활 동시 복제 네 가지 솔 루 션 입 니 다.여러분 께 도움 이 되 셨 으 면 합 니 다.궁금 한 점 이 있 으 시 면 메 시 지 를 남 겨 주세요.편집장 님 께 서 바로 답 해 드 리 겠 습 니 다.여기 서도 저희 사이트 에 대한 여러분 의 지지 에 감 사 드 립 니 다!