MySQL 5.7 심층 분석: 반동기 복제 기술

MySQL 5.7 심층 분석: 반동기 복제 기술

복제 아키텍처 파생의 역사

이 기능에 대해 이야기하기 전에 먼저 MySQL 복제 아키텍처의 파생 역사를 살펴보겠습니다. MySQL 복제는

1. 일반 복제, 비동기식 및 동기식의 네 가지 유형으로 나뉩니다. 구축이 간단하고 널리 사용되는 아키텍처입니다. 이 아키텍처는 mysql이 탄생할 때부터 만들어졌으며 성능이 매우 뛰어나며 매우 성숙하다고 할 수 있습니다. 그러나 이 아키텍처의 데이터는 비동기식이므로 데이터베이스가 손실될 위험이 있습니다.

2. 반동기화 복제, 반동기화. 성능과 기능은 비동기식과 완전 동기식 사이에 있습니다. 위의 두 아키텍처의 성능과 장점, 단점을 절충하기 위해 mysql5.5에서 탄생했습니다.

3. 동기화 복제, 전체 동기화. 현재 그룹 복제 기반의 공식 5.7 전체 동기화 기술은 랩 버전에 있으며 정식 통합이 멀지 않습니다. 전체 동기화 기술은 더 많은 데이터 일관성을 보장합니다. 이는 미래 동기화 기술의 중요한 방향이며 기대해볼만한 가치가 있다고 생각합니다.

4. mysql 클러스터. NDB 엔진을 기반으로 구축이 간단하고 상대적으로 안정적입니다. 이는 MySQL에서 데이터 보호를 위한 가장 안정적인 아키텍처이며 현재 완벽한 데이터 동기화 및 데이터 손실이 없는 유일한 아키텍처입니다. 하지만 저는 사업에 있어서 까다롭고 제약이 많습니다.

반동기 복제

오늘은 두 번째 아키텍처에 대해 이야기하고 있습니다. 우리는 일반적인 복제, 즉 mysql의 비동기 복제가 데이터 복제를 위해 mysql 바이너리 로그, 즉 바이너리 로그에 의존한다는 것을 알고 있다. 예를 들어 두 대의 머신이 있는데, 하나는 마스터이고 다른 하나는 슬레이브입니다.

1. 일반적인 복제는 다음과 같습니다. 트랜잭션 1(t1)이 binlog 버퍼에 기록되고, 덤퍼 스레드가 슬레이브에 새 트랜잭션 t1이 있음을 알리고, binlog 버퍼가 체크포인트를 수행하여 t1에 씁니다. 자체 릴레이 로그; 슬레이브의 SQL 스레드가 로컬 데이터베이스에 씁니다. 이때 마스터와 슬레이브 모두 이 새로운 트랜잭션을 볼 수 있습니다. 마스터가 죽더라도 슬레이브는 새로운 마스터로 승격될 수 있습니다.

2. 비정상적인 복사본은 다음과 같습니다. 트랜잭션 1(t1)이 binlog 버퍼에 기록되었습니다. 덤퍼 스레드가 슬레이브에 새 트랜잭션 t1이 있음을 알립니다. binlog 버퍼는 불안정하여 슬레이브가 t1을 수신하지 못했습니다. 네트워크가 끊어지고 슬레이브가 새 마스터로 승격되고 t1이 손실됩니다.

3. 큰 문제는 마스터와 슬레이브 트랜잭션 업데이트가 동기화되지 않는다는 점입니다. 네트워크나 기타 시스템 이상이 없더라도 업무가 동시 진행되는 경우 슬레이브가 마스터 배치 트랜잭션을 순차적으로 실행해야 하므로 엄청난 비용이 발생합니다. 지연. .

위 시나리오의 단점을 보완하기 위해 mysql은 5.5부터 반동기화를 출시했습니다. 즉, 마스터의 덤퍼 스레드가 슬레이브에게 이를 통보한 후, t1의 플래그 코드가 성공적으로 수신되었는지 여부를 나타내는 ack가 추가됩니다. 즉, t1을 슬레이브에게 보내는 것 외에도 덤퍼 스레드는 슬레이브의 ack를 수신하는 역할도 담당합니다. 예외가 발생하고 ack가 수신되지 않으면 예외가 복구될 때까지 자동으로 일반 복제로 다운그레이드됩니다.

반동기화로 인해 발생하는 새로운 문제를 볼 수 있습니다:

1. 예외가 발생하면 일반 복제로 다운그레이드됩니다. 그러면 슬레이브 시스템의 데이터 불일치 가능성이 줄어들지만 완전히 제거되지는 않습니다.

2. 호스트 덤퍼 스레드는 더 많은 작업을 수행하므로 전체 데이터베이스의 성능이 확실히 저하됩니다.

3. MySQL 5.5, 5.6에서 사용하는 MySQL 5.7 심층 분석: 반동기 복제 기술 모드에서는 슬레이브가 트랜잭션을 수신하지 못하는 경우, 즉 릴레이 로그에 기록되기 전에 네트워크가 비정상적이거나 불안정해져서 마스터에 문제가 발생하는 경우를 말한다. 이때 전화를 끊고 시스템이 슬레이브 시스템으로 전환되면 양쪽의 데이터가 일치하지 않게 됩니다. 이 경우 슬레이브는 트랜잭션 데이터를 하나 적게 갖게 됩니다.

MySQL 5.7이 출시되면서 반동기 복제 기술이 새로운 무손실 반동기 복제 아키텍처로 업그레이드되었으며 성숙도, 데이터 일관성 및 실행 효율성이 크게 향상되었습니다.

MySQL 5.7의 데이터 복제 효율성 향상

마스터-슬레이브 일관성이 향상되어 트랜잭션 커밋 전 ACK 대기를 지원합니다.

새 버전의 세미 동기화에는 rpl_semi_sync_master_wait_point 매개변수가 추가되어 세미 동기화 모드에서 마스터 데이터베이스를 제어합니다. 세션 트랜잭션이 성공하기 전에 트랜잭션을 커밋하는 방법으로 돌아갈 때.

이 매개변수에는 두 가지 값이 있습니다.

1. AFTER_COMMIT(5.6 기본값)

   마스터는 각 트랜잭션을 binlog에 기록하고 이를 슬레이브에 전달한 후 디스크(릴레이 로그)에 플러시하는 동시에 메인 라이브러리가 트랜잭션을 커밋합니다. 마스터는 슬레이브 피드백이 릴레이 로그를 받기를 기다립니다. 마스터는 ACK를 받은 후에만 커밋 OK 결과를 클라이언트에 피드백합니다.

   

2. AFTER_SYNC(5.7 기본값이지만 이 모드는 5.6에서는 사용할 수 없음)

   마스터는 각 트랜잭션을 binlog에 기록하고 이를 디스크에 플러시하기 위해 슬레이브에 전달합니다(릴레이 로그). 마스터는 슬레이브 피드백이 릴레이 로그 승인을 받기를 기다린 후 트랜잭션을 제출하고 커밋 OK 결과를 클라이언트에 반환합니다. 메인 라이브러리가 충돌하더라도 메인 라이브러리에서 커밋된 모든 트랜잭션은 슬레이브의 릴레이 로그와 동기화되도록 보장됩니다.

   

   따라서 5.7에서는 MySQL 5.7 심층 분석: 반동기 복제 기술 모드를 도입했습니다. 주요 이점은 MySQL 5.7 심층 분석: 반동기 복제 기술으로 인한 마스터 크래시 간의 데이터 불일치 문제를 해결하는 것입니다. 따라서 MySQL 5.7 심층 분석: 반동기 복제 기술 모드 도입 후 제출된 모든 데이터가 복사되었습니다. 장애 조치 중 데이터 일관성이 향상됩니다.

성능 개선, 비동기식 binlog 전송 및 ack 수신 지원

오래된 버전의 세미 동기화는 덤프 스레드가 두 가지 서로 다른 매우 빈번한 작업을 수행하기 때문에 덤프 스레드로 제한됩니다. 즉, binlog를 슬레이브에 전송하고 기다려야 하기 때문입니다. 슬레이브 피드백 정보의 경우 덤프 스레드는 다음 이벤트 트랜잭션을 전송하기 전에 슬레이브가 반환될 때까지 기다려야 합니다. 덤프 스레드는 전체 반동기화 성능 향상의 병목 현상이 되었습니다. 동시성이 높은 비즈니스 시나리오에서 이러한 메커니즘은 데이터베이스의 전체 TPS에 영향을 미칩니다.

위 문제를 해결하기 위해 세미 동기화 프레임워크 5.7 버전에서는 슬레이브로부터 피드백 정보를 수신하기 위해 특별히 독립된 ack 수집기 스레드를 사용합니다. 이러한 방식으로 마스터에는 독립적으로 작동하는 두 개의 스레드가 있으며, 이는 binlog를 슬레이브에 보내고 동시에 슬레이브로부터 피드백을 받을 수 있습니다.

성능 개선, 메인 라이브러리가 수신하는 슬레이브 쓰기 트랜잭션 성공 피드백 수 제어

MySQL 5.7에는 rpl_semi_sync_MySQL 5.7 심층 분석: 반동기 복제 기술 매개변수가 추가되어 메인 라이브러리가 허용하는 슬레이브 쓰기 트랜잭션 성공 피드백 수를 제어하는 ​​데 사용할 수 있습니다. , 고가용성 아키텍처로 전환하여 유연성을 제공합니다.
그림과 같이 count 값이 2일 때 마스터는 두 슬레이브의 ack를 기다려야 합니다.

성능 개선, Binlog 뮤텍스 개선

이전 버전의 반 동기 복제에서는 기본 제출 binlog 쓰기 세션과 binlog를 읽는 덤프 스레드의 binlog에 뮤텍스 잠금을 추가하여 binlog 파일 읽기 및 쓰기를 유발합니다. to be serialized 예, 동시성 문제가 있습니다.

MySQL 5.7은 다음 두 가지 측면에서 binlog 잠금을 최적화했습니다.
1. binlog에서 덤프 스레드의 뮤텍스 잠금을 제거했습니다.
2 binlog의 읽기 안전을 보장하기 위해 안전 여백을 추가했습니다.

성능 향상, 그룹 제출

MySQL 5.7에는 구성 가능한 값이 다음과 같은 새로운 변수 Slave-Parallel-type이 도입되었습니다.

1. DATABASE(5.7 이전의 기본값), 라이브러리 기반 병렬 복제 방법 2. (5.7 새 값), 그룹 제출 기반 병렬 복제 방식

MySQL 버전 5.6도 소위 ​​병렬 복제를 지원하지만 병렬성은 DATABASE, 즉 라이브러리 기반만 지원합니다. 사용자의 MySQL 데이터베이스 인스턴스에 여러 개의 DATABASE가 있는 경우 실제로 슬레이브 복제 속도에 큰 도움이 될 수 있습니다. 사용자 인스턴스에 데이터베이스가 하나만 있는 경우 병렬 재생을 달성할 수 없으며 성능은 훨씬 더 나빠집니다. 원래 단일 스레드의 차이점.

MySQL 5.7에 새로운 병렬 모드가 추가되었습니다. 동시에 COMMIT 단계에 진입하는 트랜잭션에는 동일한 시퀀스 번호가 할당됩니다. 동일한 시퀀스 번호를 가진 이러한 트랜잭션은 대기 데이터베이스에서 동시에 실행될 수 있습니다.

MySQL 5.7은 실제로 병렬 복제를 구현합니다. 그 주된 이유는 슬레이브 서버의 재생이 호스트의 재생과 일치하기 때문입니다. 즉, 마스터 서버에서의 병렬 실행은 슬레이브에서의 병렬 재생과 동일합니다. 라이브러리 기반 병렬 복제에는 더 이상 제한이 없으며 바이너리 로그 형식에 대한 특별한 요구 사항도 없습니다(라이브러리 기반 병렬 복제에 대한 요구 사항도 없습니다).

따라서 다음 시퀀스에서 동시에 발생할 수 있는 시퀀스는 다음과 같습니다(첫 번째 숫자는 last_committed이고 다음 숫자는 시퀀스_번호입니다).

trx1 1…..2
trx2 1………….3
trx3 1…………………….4
trx4        2……………………….5
trx5               3…………………………..6
trx6                     3………………………………7
trx7                            6………………………………..8

대기 데이터베이스 병렬 규칙: 트랜잭션이 분산될 때 last_committed 시퀀스 번호는 다음보다 큽니다. 현재 실행 중인 트랜잭션의 최소 시퀀스 번호가 1시간 미만인 경우 실행이 허용됩니다. 따라서

1.trx1이 실행되면 last_commit2. trx1이 실행된 후 last_commit3. trx2가 실행된 후 last_commit 4. trx3, trx4, trx5가 완료되면 last_commit

개요

우리는 MySQL 버전 5.7이 반동기 복제라고 믿습니다. 기술 최적화를 통해 성숙도와 실행 효율성이 질적으로 향상되었습니다. MySQL 5.7을 프로덕션 환경 배포로 사용하는 경우 고가용성 및 읽기-쓰기 분리를 위한 데이터 복제 솔루션으로 반동기화 기술을 사용할 것을 권장합니다.

위 내용은 MySQL 5.7 심층 분석: 반동기 복제 기술의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!