데이터베이스 재해 복구 | MySQL MGR과 Alibaba Cloud PolarDB-X Paxos

데이터베이스 재해 복구 | MySQL MGR과 Alibaba Cloud PolarDB-X Paxos의 심층 비교

2024-07-12

오픈소스 생태계

우리 모두 알고 있듯이 MySQL 기본 및 보조 데이터베이스(2개 노드)는 일반적으로 비동기 복제 및 반동기 복제(Semi-Sync)를 통해 높은 데이터 가용성을 달성합니다. 그러나 컴퓨터실 네트워크 장애 및 호스트 중단과 같은 비정상적인 시나리오에서는 기본 및 보조 아키텍처는 HA 전환 후 심각한 문제에 직면하게 됩니다(RPO!=0이라고 함).따라서 비즈니스 데이터가 어느 정도 중요한 경우에는 MySQL 기본 및 보조 아키텍처(노드 2개)를 사용하는 데이터베이스 제품을 선택하지 않는 것이 좋습니다. RPO=0인 다중 복사 아키텍처를 선택하는 것이 좋습니다.

RPO=0을 사용한 다중 복사 기술의 발전에 관한 MySQL 커뮤니티:

MySQL은 공식적으로 오픈 소스이며 그룹 복제를 기반으로 하는 MGR(MySQL 그룹 복제) 고가용성 솔루션을 출시했습니다. Paxos 프로토콜은 데이터 일관성을 보장하기 위해 XCOM을 통해 내부적으로 캡슐화됩니다.
알리 클라우드 폴라DB-X , Alibaba의 전자 상거래 Double Eleven 및 다양한 장소에서의 다중 활동에 대한 비즈니스 연마 및 검증을 통해 파생된 이 제품은 2021년 10월 전체 코어에서 오픈 소스화되어 MySQL 오픈 소스 생태계를 완전히 수용할 예정입니다. PolarDB-X는 중앙집중형, 분산형 통합 데이터베이스로 자리잡고 있으며, 데이터 노드인 Data Node(DN)는 자체 개발한 X-Paxos 프로토콜을 채택하고 있으며 MySQL 5.7/8.0과의 호환성이 뛰어나 금융 수준의 고가용성 기능을 제공합니다. , 확장성이 뛰어난 트랜잭션 엔진, 유연한 운영 및 유지 관리 재해 복구, 저렴한 데이터 저장 등의 특징도 가지고 있습니다. 참고: "PolarDB-X 오픈 소스 Paxos 기반 MySQL 사본 3개 |》。

폴라DB-X 중앙집중형 및 분산형 통합의 개념: 데이터 노드 DN은 독립형 데이터베이스 형식과 완벽하게 호환되는 중앙집중형(표준 버전) 형식으로 독립적으로 사용될 수 있습니다. 분산 확장이 필요할 정도로 비즈니스가 성장하면 아키텍처가 분산 형태로 업그레이드되고 분산 구성 요소가 원본 데이터 노드에 원활하게 연결됩니다. 애플리케이션 측에서 데이터 마이그레이션이나 수정이 필요하지 않습니다. , 이 공식, 아키텍처 설명이 제공하는 유용성과 확장성을 누릴 수 있습니다."중앙 집중식 분산 통합"

MySQL의 MGR과 PolarDB-X의 표준 버전 DN은 모두 가장 낮은 원칙의 Paxos 프로토콜을 사용합니다. 그렇다면 실제 사용 시 구체적인 성능과 차이점은 무엇입니까? 이 문서에서는 아키텍처 비교, 주요 차이점 및 테스트 비교 측면을 자세히 설명합니다.

MGR/DN 약어 설명: MGR은 MySQL MGR의 기술 형식을 나타내고, DN은 PolarDB-X 단일 DN 중앙 집중식(표준 버전)의 기술 형식을 나타냅니다.

요약

자세한 비교분석은 비교적 길기 때문에 요약과 결론을 먼저 읽어보시고 관심이 있으신 분들은 요약을 따라가며 이어지는 글에서 단서를 찾아보시면 됩니다.

MySQL MGR을 잘 사용하려면 전문적인 기술 지식과 운영 및 유지 관리 팀이 필요하기 때문에 일반 비즈니스 및 기업에는 권장되지 않습니다. 또한 이 기사에서는 오랫동안 업계에 유통되어 온 MySQL MGR의 세 가지 "숨겨진 함정"을 재현합니다. :

Dark Pit 1: MySQL MGR 및 XCOM 프로토콜은 전체 메모리 모드를 채택합니다. 기본값은 RPO=0의 데이터 일관성 보장을 충족하지 않는 것입니다(이 기사의 뒷부분에 나오는 테스트 사례에서 데이터가 누락되는 문제가 있습니다). 이를 보장하기 위해 매개변수를 표시하고 구성합니다. 현재 MGR 설계에서는 성능과 RPO를 모두 달성할 수 없습니다.
함정 2: 네트워크 지연이 있을 때 MySQL MGR의 성능이 저하됩니다. 이 기사에서는 교차 구성 하에서 동일한 도시에 있는 3개의 컴퓨터실과 3개의 센터를 포함하여 4분간의 네트워크 시나리오를 비교 테스트했습니다. 도시 성능 매개변수는 같은 도시의 1/5에 불과합니다. RPO=0의 데이터 보장이 켜져 있으면 성능이 더욱 나빠집니다.따라서 MySQL MGR은 동일한 컴퓨터실 시나리오에서 사용하기에 더 적합하지만 컴퓨터실 간 재해 복구에는 적합하지 않습니다.
함정 3: MySQL MGR의 다중 복사 아키텍처에서 대기 노드에 장애가 발생하면 마스터 노드 리더의 트래픽이 0으로 떨어지게 되는데, 이는 상식에 맞지 않습니다. 이 기사는 MGR의 단일 리더 모드(MySQL의 이전 마스터-슬레이브 복제본 아키텍처와 비교)를 활성화하는 데 중점을 두고 슬레이브 복제본의 작동 및 유지 관리 작업으로 인해 마스터가 중단되는 다운타임 및 복구의 두 가지 작업을 시뮬레이션합니다. 노드(Leader)가 나타나 트래픽이 0으로 떨어졌고(약 10초 동안 지속) 전반적인 운용성 및 유지 관리성이 상대적으로 좋지 않았습니다.따라서 MySQL MGR은 호스트 운영 및 유지 관리에 대한 요구 사항이 상대적으로 높으며 전문 DBA 팀이 필요합니다.

MySQL MGR과 비교할 때 PolarDB-X Paxos는 데이터 일관성, 컴퓨터실 간 재해 복구, 노드 운영 및 유지 관리 측면에서 MGR과 유사한 함정이 없지만 재해 복구에는 몇 가지 사소한 단점과 장점도 있습니다.

동일한 컴퓨터실의 간단한 시나리오에서 낮은 동시성에서의 읽기 전용 성능과 높은 동시성에서의 순수 쓰기 성능은 MySQL MGR보다 약 5% 정도 낮으며 동시에 여러 복사본이 네트워크를 통해 전송됩니다. 성능을 더욱 최적화할 여지가 있습니다.
장점: MySQL 5.7/8.0의 기능과 100% 호환됩니다. 동시에 다중 복사본 대기 데이터베이스 복제 및 장애 조치 경로에서 보다 간소화된 최적화가 이루어졌습니다. 고가용성 전환 RTO <= 8초, 일반 4 업계의 분당 재해 복구 시나리오 모두 잘 수행되며 세미싱크(semi-sync), MGR 등을 대체할 수 있습니다.

1. 아키텍처 비교

용어 사전

MGR/DN 약어 설명:

MGR: MySQL MGR의 기술적 형식, 후속 내용의 약어: MGR
DN: Alibaba Cloud PolarDB-X는 중앙 집중식(표준 버전) 기술 형식입니다. 분산 데이터 노드 DN은 중앙 집중식(표준 버전) 형식으로 독립적으로 사용할 수 있으며 다음 내용은 축약됩니다. 같이: DN

관리자

MGR은 단일 마스터 및 다중 마스터 모드를 지원하고 이벤트, Binlog 및 Relaylog, Apply, Binlog Apply Recovery 및 GTID를 포함한 MySQL의 복제 시스템을 완전히 재사용합니다. DN과의 주요 차이점은 MGR 트랜잭션 로그 대다수가 합의에 도달하기 위한 진입점이 기본 데이터베이스 트랜잭션이 커밋되기 전이라는 점입니다.

지도자:

1. 트랜잭션이 커밋되기 전에 before_commit 후크 함수 group_replication_trans_before_commit가 호출되어 MGR의 다수 복제를 시작합니다.
2. MGR은 Paxos 프로토콜을 사용하여 THD에 캐시된 Binlog 이벤트를 모든 온라인 노드에 동기화합니다.
3. 다수의 응답을 받은 후 MGR은 거래가 제출될 수 있는지 결정합니다.
4. THD는 트랜잭션 그룹 제출 프로세스에 들어가고 로컬 Binlog 업데이트 Redo 응답 클라이언트 OK 메시지 작성을 시작합니다.

수행원:

1. MGR의 Paxos 엔진은 계속해서 리더의 프로토콜 메시지를 수신합니다.
2. 완전한 Paxos 합의 프로세스 후에 이 (배치) 이벤트가 클러스터에서 과반수에 도달한 것으로 확인됩니다.
3. 수신된 Event를 Relay Log에 기록, IO Thread Apply Relay Log
4. 릴레이 로그 애플리케이션은 전체 그룹 제출 프로세스를 거치며, 대기 데이터베이스는 결국 자체 binlog 파일을 생성합니다.

MGR이 위와 같은 프로세스를 채택하는 이유는 MGR이 기본적으로 다중 마스터 모드이고 각 노드가 쓰기가 가능하기 때문이다. 따라서 단일 Paxos 그룹의 Follower 노드는 수신된 로그를 먼저 RelayLog로 변환한 후 결합해야 한다. 제출할 리더로 받은 쓰기 트랜잭션과 함께 Binlog 파일이 생성되어 2단계 그룹 제출 프로세스에서 최종 트랜잭션을 제출합니다.

디엔에이

DN은 MySQL의 기본 데이터 구조와 기능 수준 코드를 재사용하지만 로그 복제, 로그 관리, 로그 재생 및 크래시 복구를 X-Paxos 프로토콜과 긴밀하게 통합하여 고유한 다수 복제 및 상태 머신 메커니즘 세트를 형성합니다. MGR과의 주요 차이점은 DN 트랜잭션 로그 대다수가 합의에 도달하기 위한 진입점이 기본 데이터베이스 트랜잭션 제출 프로세스 중에 있다는 것입니다.

지도자:

1. 트랜잭션의 그룹 제출 프로세스를 시작합니다. 그룹 제출의 플러시 단계에서 각 THD의 이벤트가 Binlog 파일에 기록된 다음 로그가 X-Paxos를 통해 모든 팔로어에게 비동기적으로 방송됩니다.
2. 그룹 제출의 동기화 단계에서는 Binlog가 먼저 유지된 다음 X-Paxos 지속성 위치가 업데이트됩니다.
3. 그룹 제출의 커밋 단계에서는 먼저 X-Paxos가 다수의 응답을 받을 때까지 기다린 다음 트랜잭션 그룹을 제출하고 마지막으로 클라이언트의 OK 메시지로 응답해야 합니다.

수행원:

1. X-Paxos는 계속해서 리더의 프로토콜 메시지를 수신합니다.
2. (그룹) 이벤트를 수신하고, 로컬 Binlog에 쓰고, 응답합니다.
3. 다수에 도달한 위치의 커밋 인덱스를 전달하는 다음 메시지가 수신됩니다.
4. SQL Apply 스레드는 수신된 Binlog 로그를 백그라운드에서 계속 적용하며 최대 다수 위치에만 적용합니다.

이렇게 설계한 이유는 DN이 현재 단일 마스터 모드만 지원하므로 X-Paxos 프로토콜 수준의 로그는 Binlog 자체이기 때문입니다. Follower도 Relay Log와 영구 로그 및 리더 로그의 데이터 내용을 생략합니다. 가격은 동일합니다.

2. 주요 차이점

2.1. 팩소스 프로토콜 효율성

관리자

MGR의 Paxos 프로토콜은 Multi-Paxos 이론에 속하는 Mencius 프로토콜을 기반으로 구현되었습니다. 차이점은 Mencius가 마스터 노드의 부하를 줄이고 처리량을 높이는 데 최적화 개선을 했다는 것입니다.
MGR의 Paxos 프로토콜은 XCOM 구성 요소로 구현되며 다중 마스터 및 단일 마스터 모드 배포를 지원합니다. 리더의 Binlog는 각 메시지 배치(트랜잭션)를 원자적으로 브로드캐스팅합니다. 표준 Multi-Paxos 프로세스.
대부분의 트랜잭션을 만족시키기 위해 XCOM은 Accept+AckAccept+Learn의 최소 세 가지 메시지 상호 작용을 거쳐야 합니다.최소 1.5 RTT 오버헤드.최대 3개의 메시지 상호 작용(Prepare+AckPrepare+Accept+AckAccept+Learn)이 필요합니다.즉, 총 최대 2.5 RTT 오버헤드입니다.
Paxos 프로토콜은 XCOM 모듈에서 높은 응집력으로 완성되고 MySQL 복제 시스템을 인식하지 못하기 때문에 리더는 Binlog 지속성 및 그룹 제출을 포함하여 트랜잭션을 로컬로 커밋하기 전에 전체 Paxos 프로세스가 완료될 때까지 기다려야 합니다.
Follower가 다수의 제출을 완료한 후 이벤트를 릴레이 로그에 비동기적으로 유지한 다음 SQL Thread 애플리케이션과 그룹이 프로덕션 Binlog를 제출합니다.
Paxos에서 동기화한 로그는 그룹 제출 프로세스에 들어가기 전에 정렬되지 않은 Binlog이므로 리더의 Binlog 이벤트 순서는 Follower 노드의 릴레이 로그의 이벤트 순서와 동일하지 않을 수 있습니다.

디엔에이

DN의 Paxos 프로토콜은 Raft 프로토콜을 기반으로 구현되었으며 Multi-Paoxs 이론에도 속합니다. 차이점은 Raft 프로토콜이 더 강력한 리더십 보장과 엔지니어링 안정성 보장을 갖는다는 것입니다.
DN의 Paxos 프로토콜은 X-Paoxs 구성 요소에 의해 완료됩니다. 기본값은 단일 마스터 모드에서 리더의 Binlog는 각 메시지 배치의 브로드캐스트가 표준 Raft 프로세스입니다. .
대부분의 트랜잭션을 만족시키기 위해 X-Paoxs는 Append+AckAppend의 두 가지 메시지 상호 작용만 거치면 됩니다.1 RTT 오버헤드
Leader가 Follower에게 로그를 보낸 후 과반수를 만족하는 한 두 번째 단계에서 Commit Index 브로드캐스트를 기다리지 않고 트랜잭션을 커밋합니다.
Follower가 다수의 제출을 완료하려면 모든 트랜잭션 로그가 지속되어야 합니다. 이는 MGR의 XCOM이 XCOM 메모리에서만 이를 수신하면 된다는 점과 크게 다릅니다.
Commit Index는 후속 메시지 및 하트비트 메시지에서 가져오며, Follower는 CommitIndex가 푸시된 후 Apply 이벤트를 수행합니다.
Leader와 Follower의 Binlog 내용은 동일한 순서이며 Raft 로그에는 구멍이 없으며 일괄 처리/파이프라인 메커니즘을 사용하여 로그 복제 처리량을 늘립니다.
MGR과 비교하여 리더는 트랜잭션이 커밋될 때 항상 한 번의 왕복 지연만 갖습니다., 지연에 민감한 분산 애플리케이션에 매우 중요

2.2. RPO

이론적으로는 Paxos와 Raft 모두 데이터 일관성을 보장할 수 있으며 Crash Recovery 이후 다수에 도달한 로그는 손실되지 않지만 특정 프로젝트에서는 여전히 차이가 있습니다.

관리자

XCOM은 Paxos 프로토콜을 완전히 캡슐화하며 모든 프로토콜 데이터는 먼저 메모리에 캐시됩니다. 기본적으로 다수에 도달하는 트랜잭션에는 로그 지속성이 필요하지 않습니다. 대부분의 파이가 다운되고 리더가 실패하는 경우 RPO != 0이라는 심각한 문제가 발생하게 됩니다.극단적인 시나리오를 가정해 보겠습니다.

MGR 클러스터는 세 개의 노드 ABC로 구성되며, 그 중 AB는 같은 도시에 있는 독립된 전산실이고 C는 도시 간 노드입니다. A는 리더, BC는 팔로어 노드입니다.
리더 A 노드에서 트랜잭션 001을 시작합니다. 리더 A는 트랜잭션 001의 로그를 BC 노드에 브로드캐스팅합니다. Paxos 프로토콜을 통해 다수가 충족되면 트랜잭션이 제출된 것으로 간주될 수 있습니다. 섹션 AB가 다수를 차지했으며 노드 C는 도시 간 네트워크 지연으로 인해 트랜잭션 001의 로그를 수신하지 못했습니다.
다음 순간에 리더 A는 트랜잭션 001을 제출하고 클라이언트 성공을 반환합니다. 이는 트랜잭션 001이 데이터베이스에 제출되었음을 의미합니다.
현재 노드 B의 Follower에서는 트랜잭션 001의 로그가 여전히 XCOM 캐시에 있고 RelayLog로 플러시될 시간이 없으며 노드 C의 Follower는 여전히 트랜잭션 001을 수신하지 못했습니다. 노드 A의 리더로부터 로그를 받습니다.
이때 노드 AB는 다운되고, 노드 A는 장애가 발생하여 오랫동안 복구할 수 없으며, 노드 B는 신속하게 재시작 및 복구되며, 노드 BC는 계속해서 읽기 및 쓰기 서비스를 제공합니다.
트랜잭션 001 로그는 다운타임 동안 노드 B의 RelayLog에 유지되지 않았고 노드 C에서도 수신되지 않았기 때문에 이 순간 BC 노드는 실제로 트랜잭션 001을 잃어서 검색할 수 없습니다.
다수당이 무너진 이 시나리오에서는 RPO!=0입니다.

커뮤니티의 기본 매개변수 하에서 대부분의 트랜잭션은 로그 지속성을 요구하지 않으며 RPO=0을 보장하지 않습니다. 이는 XCOM 프로젝트 구현 시 성능에 대한 절충으로 간주될 수 있습니다. 절대 RPO=0을 보장하려면 AFTER에 대한 읽기 및 쓰기 일관성을 제어하는 group_replication_consistency 매개변수를 구성해야 합니다. 그러나 이 경우 1.5 RTT 네트워크 오버헤드 외에도 트랜잭션에 과반수에 도달하려면 로그 IO 오버헤드가 필요합니다. 성능이 매우 저하됩니다.

디엔에이

PolarDB-X DN은 X-Paxos를 사용하여 분산 프로토콜을 구현하며 MySQL의 그룹 커밋 프로세스에 깊이 바인딩되어 있습니다. 트랜잭션이 제출되면 실제 제출이 허용되기 전에 대다수가 배치 및 지속성을 확인해야 합니다. 여기서 디스크 배치의 대부분은 기본 라이브러리의 Binlog 배치를 참조합니다. 대기 라이브러리의 IO 스레드는 기본 라이브러리의 로그를 수신하여 지속성을 위해 자체 Binlog에 씁니다. 따라서 극단적인 시나리오에서 모든 노드가 실패하더라도 데이터가 손실되지 않으며 RPO=0을 보장할 수 있습니다.

2.3. RTO

RTO 시간은 시스템 자체의 콜드 재시작 시간 오버헤드와 밀접하게 관련되어 있으며 이는 특정 기본 기능에 반영됩니다.오류 감지 메커니즘->충돌 복구 메커니즘->마스터 선택 메커니즘->로그 밸런싱

2.3.1. 오류 감지

관리자

각 노드는 정기적으로 다른 노드에 하트비트 패킷을 보내 다른 노드의 상태를 확인합니다. 하트비트 주기는 1초로 고정되어 있으며 조정할 수 없습니다.
현재 노드가 group_replication_member_expel_timeout(기본값 5초) 이후에 다른 노드가 응답하지 않은 것을 발견하면 실패한 노드로 간주되어 클러스터에서 추방됩니다.
네트워크 중단이나 비정상적인 재시작 등 예외적인 경우에는 네트워크가 복구된 후 장애가 발생한 단일 노드가 자동으로 클러스터에 참여를 시도한 후 로그를 묶습니다.

디엔에이

Leader 노드는 주기적으로 다른 노드에 하트비트 패킷을 보내 다른 노드의 상태를 확인합니다. 하트비트 기간은 선택 시간 초과의 1/5입니다. 선택 시간 제한은 합의_선거_시간 초과 매개변수에 의해 제어됩니다. 기본값은 5초이므로 리더 노드 하트비트 기간의 기본값은 1초입니다.
리더가 다른 노드가 오프라인임을 발견하면 다른 노드가 충돌 및 복구된 후 제 시간에 액세스할 수 있도록 주기적으로 다른 모든 노드에 하트비트 패킷을 계속 보냅니다.그러나 리더 노드는 더 이상 오프라인 노드에 트랜잭션 로그를 보내지 않습니다.
비리더 노드는 하트비트 감지 패킷을 보내지 않지만, 비리더 노드가 합의_선거_시간 초과 이후 리더 노드로부터 하트비트를 수신하지 못한 것을 발견하면 재선거가 트리거됩니다.
네트워크 중단 또는 비정상적인 재시작과 같은 예외의 경우 네트워크가 복원된 후 결함이 있는 노드가 자동으로 클러스터에 참여합니다.
따라서 오류 감지 측면에서 DN은 더 많은 운영 및 유지 관리 구성 인터페이스를 제공하며 도시 간 배포 시나리오에서 오류 식별이 더 정확해집니다.

2.3.2. 충돌 복구

관리자

- XCOM에 의해 구현된 Paxos 프로토콜은 메모리 상태에 있습니다. 프로토콜 상태는 살아남은 다수 노드의 메모리 상태를 기반으로 합니다.모든 노드가 중단되면 프로토콜을 복원할 수 없습니다. 클러스터를 다시 시작한 후 이를 복원하려면 수동 개입이 필요합니다.
- 단일 노드만 충돌하여 복구되었지만 Follower 노드가 더 많은 트랜잭션 로그로 Leader 노드보다 뒤처지고 Leader의 XCOM 캐시 트랜잭션 로그가 지워진 경우 유일한 옵션은 전역 복구 또는 복제 프로세스를 사용하는 것입니다.
- XCOM 캐시 크기는 group_replication_message_cache_size에 의해 제어되며 기본값은 1GB입니다.
- 전역 복구는 노드가 클러스터에 다시 참여할 때 다른 노드에서 누락된 필수 트랜잭션 로그(바이너리 로그)를 가져와 데이터를 복구하는 것을 의미합니다.이 프로세스는 필요한 모든 트랜잭션 로그를 유지하는 클러스터의 하나 이상의 노드에 의존합니다.
- Clone은 데이터의 양이 많거나 로그가 많이 누락된 경우 복구에 사용되는 Clone Plugin을 사용합니다.전체 데이터베이스의 스냅샷을 충돌이 발생한 노드에 복사한 후 최신 트랜잭션 로그와 최종 동기화하는 방식으로 작동합니다.
- 전역 복구 및 복제 프로세스는 일반적으로 자동화되지만 네트워크 문제나 다른 두 노드의 XCOM 캐시가 지워진 등 일부 특수한 경우에는 수동 개입이 필요합니다.

디엔에이

- X-Paxos 프로토콜은 Binlog 지속성을 사용합니다. 충돌 복구 시 제출된 트랜잭션이 먼저 완전히 복원됩니다. 보류 중인 트랜잭션의 경우 트랜잭션을 커밋하거나 롤백하기 전에 XPaxos 프로토콜 계층이 마스터-백업 관계를 결정하기 위한 합의에 도달할 때까지 기다려야 합니다. 전체 프로세스는 완전히 자동화되어 있습니다.모든 노드가 다운되더라도 클러스터는 재시작 후 자동으로 복구됩니다.
- 많은 트랜잭션 로그에서 Follower 노드가 Leader 노드보다 뒤처지는 시나리오의 경우 Leader의 Binlog 파일이 삭제되지 않는 한 Follower 노드는 확실히 따라잡을 것입니다.
- 따라서 충돌 복구 측면에서 DN은 수동 개입이 전혀 필요하지 않습니다.

2.3.3. 리더 선택

단일 마스터 모드에서 MGR의 XCOM과 강력한 리더 모드인 DN X-Paxos는 리더 선택에 대해 동일한 기본 원칙을 따릅니다. 즉, 클러스터에서 합의한 로그는 롤백할 수 없습니다. 하지만 합의되지 않은 로그의 경우에는 차이가 있습니다.

관리자

리더 선택은 다음번에 어떤 노드가 리더 서비스 역할을 할 것인지에 관한 것입니다.이 리더는 선출될 때 반드시 최신 합의 로그를 가지고 있는 것은 아니므로 클러스터 내 다른 노드의 최신 로그를 동기화하고 로그가 묶인 후 읽기 및 쓰기 서비스를 제공해야 합니다.
이것의 장점은 리더의 선택 자체가 무게, 순서 등 전략적인 산물이라는 점이다. MGR은 group_replication_member_weight 매개변수를 통해 각 노드의 가중치를 제어합니다.
단점은 새로 선출된 리더 자체에 큰 복제 지연이 있어 계속해서 로그를 따라잡아야 하거나, 큰 애플리케이션 지연이 있을 수 있고 로그 애플리케이션이 읽기 및 읽기 기능을 제공하기 전에 계속해서 따라잡아야 한다는 것입니다. 서비스를 작성합니다.이로 인해 RTO 시간이 길어집니다.

디엔에이

리더 선택은 프로토콜의 의미입니다. 클러스터의 모든 다수 당사자의 로그가 있는 노드는 리더로 선출될 수 있으므로 이 노드는 이전에 팔로어 또는 로거였을 수 있습니다.
로거는 읽기 및 쓰기 서비스를 제공할 수 없습니다. 로그를 다른 노드에 동기화한 후에는 리더 역할을 적극적으로 포기합니다.
지정된 노드가 리더가 되도록 DN은 낙관적 가중치 전략 + 필수 가중치 전략을 사용하여 리더가 되는 순서를 제한하고 전략적 다수 메커니즘을 사용하여 새로운 마스터가 즉시 읽기 및 쓰기를 제공할 수 있도록 보장합니다. 지연 없는 서비스.
따라서 리더 선택 측면에서 DN은 MGR과 동일한 전략적 선택을 지원할 뿐만 아니라 필수 가중치 전략도 지원합니다.

2.3.4. 로그 매칭

로그 평준화는 기본 데이터베이스와 보조 데이터베이스 간의 로그에 로그 복제 지연이 있으며, 보조 데이터베이스가 로그를 평준화해야 함을 의미합니다. 재시작 및 복구되는 노드의 경우 대개 스탠바이 데이터베이스를 이용하여 복구를 시작하는데, 메인 데이터베이스에 비해 이미 로그 복제 지연이 발생하여 메인 데이터베이스로 로그를 잡아야 한다. 리더로부터 물리적으로 멀리 떨어져 있는 노드의 경우 다수에 도달하는 것은 일반적으로 복제 로그 지연이 있으며 항상 로그를 따라잡습니다. 이러한 상황에서는 로그 복제 지연을 적시에 해결할 수 있도록 특정 엔지니어링 구현이 필요합니다.

관리자

트랜잭션 로그는 모두 XCOM 캐시에 있으며 캐시는 기본적으로 1G에 불과하므로 복제 요청 로그가 훨씬 뒤떨어진 팔로워 노드가 있으면 캐시를 쉽게 지울 수 있습니다.
이때 지연된 Follower는 자동으로 클러스터에서 쫓겨나며, 이후 Crash Recovery를 위해 위에서 언급한 Global Recovery 또는 Clone 프로세스를 사용한 후 따라잡은 후 자동으로 클러스터에 합류하게 됩니다.당신이 만난다면예를 들어, 네트워크 문제 또는 다른 두 노드의 XCOM 캐시가 지워지는 경우 문제를 해결하려면 수동 개입이 필요합니다.
왜 클러스터를 먼저 추방해야 합니까? 다중 쓰기 모드에서 결함이 있는 노드는 성능에 큰 영향을 미치며, 리더의 캐시는 비동기 타이업 후에 추가되어야 합니다.
왜 리더의 로컬 Binlog 파일을 직접 읽을 수 없나요? 앞서 언급한 XCOM 프로토콜은 전체 메모리에 저장되어 있고 Binlog 및 Relay Log에는 XCOM에 대한 프로토콜 정보가 없기 때문입니다.

디엔에이

데이터는 모두 Binlog 파일에 있습니다. Binlog를 정리하지 않는 한 요청 시 전송할 수 있으며 클러스터에서 쫓겨날 가능성이 없습니다.
Binlog 파일에서 오래된 트랜잭션 로그를 읽는 메인 라이브러리로 인해 발생하는 IO 지터를 줄이기 위해 DN은 FIFO 캐시에서 가장 최근에 캐시된 트랜잭션 로그를 읽는 데 우선 순위를 부여합니다. FIFO 캐시는 합의_log_cache_size 매개변수에 의해 제어되며 기본값입니다. 64M입니다
FIFO 캐시의 이전 트랜잭션 로그가 업데이트된 트랜잭션 로그에 의해 제거된 경우 DN은 프리페치 캐시에서 이전에 캐시된 트랜잭션 로그를 읽으려고 시도합니다. 프리페치 캐시는 합의_prefetch_cache_size 매개변수에 의해 제어되며 기본값은 64M입니다.
프리페치 캐시에 필요한 이전 트랜잭션 로그가 없으면 DN은 비동기 IO 작업을 시작하고 Binlog 파일에서 지정된 트랜잭션 로그 전후의 여러 연속 로그를 일괄적으로 읽고 프리페치 캐시에 배치한 후 기다립니다. DN의 다음 재시도 읽기를 위해 선택하세요.
따라서 DN은 로그 밸런싱과 관련하여 수동 개입이 전혀 필요하지 않습니다.

2.4. 대기 데이터베이스 재생 지연

대기 데이터베이스 재생 지연은 기본 데이터베이스에서 동일한 트랜잭션이 완료되는 시점과 대기 데이터베이스에서 해당 트랜잭션이 적용되는 시점 사이의 지연을 의미합니다. 여기서 테스트하는 것은 대기 데이터베이스 적용 애플리케이션 로그의 성능입니다. 이는 예외가 발생할 때 대기 데이터베이스가 데이터 애플리케이션을 완료하고 읽기 및 쓰기 서비스를 제공하는 데 걸리는 시간에 영향을 줍니다.

관리자

MGR 대기 데이터베이스는 메인 데이터베이스로부터 RelayLog 파일을 받아 애플리케이션을 적용할 때 다시 RelayLog를 읽어와 2단계 그룹 제출 과정을 거쳐 해당 데이터와 Binlog 파일을 생성해야 한다.
여기서 트랜잭션 애플리케이션 효율성은 기본 데이터베이스의 트랜잭션 제출 효율성과 동일합니다. 기본 이중 구성(innodb_flush_log_at_trx_commit, sync_binlog)으로 인해 대기 데이터베이스 애플리케이션의 동일한 리소스 오버헤드가 커집니다.

디엔에이

DN 백업 데이터베이스는 기본 데이터베이스로부터 Binlog 파일을 수신하며, 적용 시에는 1단계 그룹 제출 과정을 거쳐 해당 데이터를 생성하기만 하면 됩니다.
DN은 완전한 Crash Recover를 지원하므로 대기 데이터베이스 애플리케이션은 innodb_flush_log_at_trx_commit=1을 활성화할 필요가 없으므로 실제로 double-one 구성의 영향을 받지 않습니다.
따라서 대기 데이터베이스 재생 지연 측면에서 DN 대기 데이터베이스 재생 효율성은 MGR보다 훨씬 높습니다.

2.5. 주요 사건의 영향

대규모 트랜잭션은 일반 트랜잭션의 제출에 영향을 미칠 뿐만 아니라 분산 시스템의 전체 분산 프로토콜의 안정성에도 영향을 미칩니다. 심각한 경우 대규모 트랜잭션으로 인해 전체 클러스터를 오랫동안 사용할 수 없게 됩니다.

관리자

MGR에는 대규모 트랜잭션을 지원하기 위한 최적화가 없습니다. 단지 대규모 트랜잭션의 상한을 제어하기 위해 group_replication_transaction_size_limit 매개변수를 추가할 뿐입니다. 기본값은 143M이고 최대값은 2GB입니다.
트랜잭션 로그가 대규모 트랜잭션 한도를 초과하면 오류가 직접 보고되고 트랜잭션을 제출할 수 없습니다.

디엔에이

대규모 트랜잭션으로 인해 발생하는 분산 시스템의 불안정성 문제를 해결하기 위해 DN은 대규모 트랜잭션 분할 + 대규모 개체 분할 솔루션을 채택하여 대규모 트랜잭션의 트랜잭션 로그를 논리적 + 물리적으로 분할합니다. 작은 블록, 트랜잭션 로그의 각 작은 블록은 전체 Paxos 커밋 보장을 사용합니다.
DN은 대규모 트랜잭션을 분할하는 솔루션을 기반으로 대규모 트랜잭션의 크기에 제한을 두지 않으며 사용자가 자유롭게 사용할 수 있으며 RPO=0을 보장할 수도 있습니다.
자세한 지침은 다음을 참조하세요."PolarDB-X 스토리지 엔진 핵심 기술 | 대규모 트랜잭션 최적화"
따라서 DN은 대규모 업무에 영향을 받지 않고 대규모 업무를 처리할 수 있습니다.

2.6. 배포 양식

관리자

MGR은 단일 마스터 및 다중 마스터 배포 모드를 지원합니다. 단일 마스터 모드에서는 기본 데이터베이스를 읽고 쓸 수 있으며 대기 데이터베이스는 읽기만 가능합니다. 오직.
MGR 고가용성 배포에는 3개 이상의 노드 배포가 필요합니다. 즉, 3개 이상의 데이터 및 로그 복사본이 필요합니다. 로그 복사 로거 모드는 지원되지 않습니다.
MGR은 읽기 전용 노드의 확장을 지원하지 않지만 유사한 토폴로지 확장을 달성하기 위해 MGR + 마스터-슬레이브 복제 모드의 조합을 지원합니다.

디엔에이

DN은 단일 마스터 모드 배포를 지원합니다. 단일 마스터 모드에서는 기본 데이터베이스를 읽고 쓸 수 있으며 대기 데이터베이스는 읽기 전용일 수 있습니다.
DN 고가용성 배포에는 3개 이상의 노드가 필요하지만 로그 복사 Logger 형식을 지원합니다. 즉, Leader 및 Follower는 모든 기능을 갖춘 Logger와 비교할 때 로그만 있고 데이터가 없으며 권한이 없습니다. 선출. 이 경우 3노드 고가용성 배포에는 데이터 복사본 2개 + 로그 복사본 3개의 스토리지 오버헤드만 필요하므로 배포 비용이 저렴합니다.
DN은 읽기 전용 노드 배포 및 읽기 전용 복사 학습자 형식을 지원합니다. 완전한 기능을 갖춘 복사본과 비교하여 학습자 복사본을 통해서는 기본 라이브러리에 대한 다운스트림 구독 소비가 실현됩니다.

2.7. 기능 요약

		관리자	디엔에이
프로토콜 효율성	거래 제출 시간	1.5~2.5 회	1RTT
	다수의 지속성	XCOM 메모리 저장	Binlog 지속성
신뢰할 수 있음	RPO=0	기본적으로 보장되지 않음	완전 보장
	결함 감지	모든 노드가 서로를 확인하고 네트워크 부하가 높음 하트비트 주기를 조정할 수 없습니다.	마스터 노드는 주기적으로 다른 노드를 확인합니다. 하트비트 주기 매개변수는 조정 가능합니다.
	대다수 붕괴 복구	수동 개입	자동 복구
	소수 충돌 복구	대부분의 경우 자동 복구, 특수 상황에서는 수동 개입	자동 복구
	마스터를 선택하세요	선택 순서를 자유롭게 지정	선택 순서를 자유롭게 지정
	통나무 넥타이	지연 로그는 XCOM 1GB 캐시를 초과할 수 없습니다.	BInlog 파일은 삭제되지 않습니다
	대기 데이터베이스 재생 지연	2단계 + 1단계, 매우 느림	한 단계 + 더블 제로, 더 빨라짐
	대기업	기본 제한은 143MB 이하입니다.	크기 제한 없음
형태	고가용성 비용	완전한 기능을 갖춘 복사본 3개, 데이터 스토리지 오버헤드 복사본 3개	로거 로그 사본, 데이터 저장 사본 2개
	읽기 전용 노드	마스터-슬레이브 복제로 구현됨	프로토콜은 Leaner 읽기 전용 복사 구현과 함께 제공됩니다.

3. 테스트 비교

MGR은 MySQL 5.7.17에서 도입되었지만 더 많은 MGR 관련 기능은 MySQL 8.0에서만 사용할 수 있으며 MySQL 8.0.22 이상 버전에서는 전반적인 성능이 더욱 안정적이고 신뢰할 수 있습니다. 따라서 우리는 비교 테스트를 위해 양 당사자의 최신 버전 8.0.32를 선택했습니다.

PolarDB-X DN과 MySQL MGR의 비교 테스트 중 테스트 환경, 컴파일 방법, 배포 방법, 운영 매개 변수 및 테스트 방법에 차이가 있어 부정확한 테스트 비교 데이터가 발생할 수 있다는 점을 고려하여 이 기사에서는 다양한 세부 사항에 중점을 둘 것입니다. . 다음과 같이 진행하십시오.

시험 준비	PolarDB-X DN	MySQL 관리자[1]
하드웨어 환경	96C 754GB 메모리와 SSD 디스크를 갖춘 동일한 물리적 머신 사용
운영 체제	리눅스 4.9.168-019.ali3000.alios7.x86_64
커널 버전	커뮤니티 버전 8.0.32 기반 커널 기준 사용
컴파일 방법	동일한 RelWithDebInfo로 컴파일
작동 매개변수	동일한 PolarDB-X 공식 웹사이트를 사용하여 동일한 사양과 매개변수로 32C128G를 판매하세요.
배포 방법	단일 마스터 모드

메모:

MGR에는 기본적으로 흐름 제어가 활성화되어 있고 PolarDB-X DN에는 기본적으로 흐름 제어가 꺼져 있습니다.따라서 MGR의 group_replication_flow_control_mode를 별도로 구성하여 MGR의 성능이 최상이 되도록 한다.
MGR은 열거하는 동안 읽기 병목 현상이 발생하므로 MGR의 Relation_optimize_for_static_plugin_config를 별도로 구성하고 활성화하므로 MGR의 읽기 전용 성능이 가장 좋습니다.

3.1. 성능

성능 테스트는 데이터베이스를 선택할 때 모두가 가장 먼저 주목하는 것입니다. 여기에서는 공식 sysbench 도구를 사용하여 각각 천만 개의 데이터가 포함된 16개의 테이블을 구축하여 OLTP 시나리오에서 성능 테스트를 수행하고 다양한 OLTP 시나리오의 서로 다른 동시성 조건에서 두 테이블의 성능을 테스트 및 비교합니다.실제 배포의 다양한 상황을 고려하여 다음 네 가지 배포 시나리오를 각각 시뮬레이션합니다.

세 개의 노드가 동일한 컴퓨터실에 배포되어 있으며 머신이 서로 ping할 때 0.1ms의 네트워크 지연이 있습니다.
같은 도시에 있는 3개의 센터와 같은 지역에 있는 3개의 컴퓨터실에서 3개의 노드를 배포합니다. 컴퓨터실 간 ping에는 1ms의 네트워크 지연이 있습니다(예: 상하이에 있는 3개의 컴퓨터실).
2개 장소에 3개 센터, 2개 장소에 3개 컴퓨터실에 3개 노드 배포, 같은 도시에 있는 컴퓨터실 간 네트워크 핑 1ms, 같은 도시와 다른 장소 간 네트워크 지연 30ms(예: 상하이/상하이/심천)
3개 센터, 3개 장소(예: 상하이/항저우/심천) 3개 컴퓨터실에 3개 노드 배포, 항저우와 상하이 간 네트워크 지연은 약 5ms, 항저우/상하이에서 선전까지의 가장 먼 거리는 30ms입니다. .

설명하다:

a. 4개 배포 시나리오의 성능을 수평적으로 비교하면 2개 위치의 3개 센터는 모두 3개 복사본의 배포 모드를 채택합니다.

b. 고가용성 데이터베이스 제품 사용 시 RPO=0에 대한 엄격한 제한을 고려하여 MGR은 기본적으로 RPO<>0으로 구성됩니다. 여기서는 각 항목에서 MGR RPO<>0과 RPO=0 간의 비교 테스트를 계속 추가할 예정입니다. 배포 시나리오.

MGR_0은 MGR RPO = 0인 경우의 데이터를 나타냅니다.
MGR_1은 MGR RPO <> 0인 경우에 대한 데이터를 나타냅니다.
DN은 DN RPO = 0인 경우의 데이터를 나타냅니다.

3.1.1. 동일한 컴퓨터실

		1	4	16	64	256
oltp_read_only	MGR_1	688.42	2731.68	6920.54	11492.88	14561.71
	MGR_0	699.27	2778.06	7989.45	11590.28	15038.34
	디엔에이	656.69	2612.58	7657.03	11328.72	14771.12
	MGR_0 대 MGR_1	1.58%	1.70%	15.45%	0.85%	3.27%
	DN 대 MGR_1	-4.61%	-4.36%	10.64%	-1.43%	1.44%
	DN 대 MGR_0	-6.09%	-5.96%	-4.16%	-2.26%	-1.78%
oltp_읽기_쓰기	MGR_1	317.85	1322.89	3464.07	5052.58	6736.55
	MGR_0	117.91	425.25	721.45	217.11	228.24
	디엔에이	360.27	1485.99	3741.36	5460.47	7536.16
	MGR_0 대 MGR_1	-62.90%	-67.85%	-79.17%	-95.70%	-96.61%
	DN 대 MGR_1	13.35%	12.33%	8.00%	8.07%	11.87%
	DN 대 MGR_0	205.55%	249.44%	418.59%	2415.07%	3201.86%
oltp_write_only	MGR_1	761.87	2924.1	7211.97	10374.15	16092.02
	MGR_0	309.83	465.44	748.68	245.75	318.48
	디엔에이	1121.07	3787.64	7627.26	11684.37	15137.23
	MGR_0 대 MGR_1	-59.33%	-84.08%	-89.62%	-97.63%	-98.02%
	DN 대 MGR_1	47.15%	29.53%	5.76%	12.63%	-5.93%
	DN 대 MGR_0	261.83%	713.78%	918.76%	4654.58%	4652.96%

테스트 결과에서 볼 수 있습니다.

읽기 전용 시나리오에서는 MGR_1(RPO<>0)을 비교하든 MGR_0(RPO=0)을 비교하든 DN과 MGR의 차이는 -5%에서 10% 사이에서 안정적이며 이는 기본적으로 동일하다고 볼 수 있습니다. RPO가 0인지 여부는 읽기 전용 트랜잭션에 영향을 주지 않습니다.
읽기-쓰기 및 쓰기 전용 혼합 트랜잭션 시나리오에서 DN(RPO=0)의 성능은 MGR_1(RPO<>0)에 비해 5%~47% 향상되었으며, 동시성이 낮고 동시성이 높을 때 장점이 있는 것은 분명하지 않습니다. 이는 동시성이 낮을 때 DN의 프로토콜 효율성이 높아지지만 동시성이 높을 때 DN과 MGR의 성능 핫스팟이 모두 정리에 있기 때문입니다.
RPO=0이라는 동일한 전제하에 읽기-쓰기와 쓰기 전용이 혼합된 트랜잭션 시나리오에서 DN의 성능은 MGR_0에 비해 2배에서 46배까지 향상되고 동시성이 증가할수록 DN의 성능 이점이 향상됩니다. MGR이 기본적으로 성능을 위해 RPO=0을 포기하는 것도 당연합니다.

3.1.2. 같은 도시에 세 개의 센터가 있습니다.

TPS 비교		1	4	16	64	256
oltp_read_only	MGR_1	695.69	2697.91	7223.43	11699.29	14542.4
	MGR_0	691.17	2708.6	7849.98	11636.94	14670.99
	디엔에이	645.11	2611.15	7628.39	11294.36	14647.22
	MGR_0 대 MGR_1	-0.65%	0.40%	8.67%	-0.53%	0.88%
	DN 대 MGR_1	-7.27%	-3.22%	5.61%	-3.46%	0.72%
	DN 대 MGR_0	-6.66%	-3.60%	-2.82%	-2.94%	-0.16%
oltp_읽기_쓰기	MGR_1	171.37	677.77	2230	3872.87	6096.62
	MGR_0	117.11	469.17	765.64	813.85	812.46
	디엔에이	257.35	1126.07	3296.49	5135.18	7010.37
	MGR_0 대 MGR_1	-31.66%	-30.78%	-65.67%	-78.99%	-86.67%
	DN 대 MGR_1	50.17%	66.14%	47.82%	32.59%	14.99%
	DN 대 MGR_0	119.75%	140.01%	330.55%	530.97%	762.86%
oltp_write_only	MGR_1	248.37	951.88	2791.07	5989.57	11666.16
	MGR_0	162.92	603.72	791.27	828.16	866.65
	디엔에이	553.69	2173.18	5836.64	10588.9	13241.74
	MGR_0 대 MGR_1	-34.40%	-36.58%	-71.65%	-86.17%	-92.57%
	DN 대 MGR_1	122.93%	128.30%	109.12%	76.79%	13.51%
	DN 대 MGR_0	239.85%	259.96%	637.63%	1178.61%	1427.92%

테스트 결과에서 볼 수 있습니다.

읽기 전용 시나리오에서 MGR_1(RPO<>0)을 비교하든 MGR_0(RPO=0)을 비교하든 DN과 MGR의 차이는 -7%에서 5% 사이로 안정적이며 이는 기본적으로 동일하다고 볼 수 있습니다. RPO가 0인지 여부는 읽기 전용 트랜잭션에 영향을 주지 않습니다.
읽기-쓰기와 쓰기 전용이 혼합된 트랜잭션 시나리오에서 DN(RPO=0)의 성능은 MGR_1(RPO<>0)에 비해 30% ~ 120% 향상되었으며 동시성에서 DN의 성능 이점은 명백합니다. 낮고 동시성이 높을 때 성능이 더 좋아집니다. 이는 동시성이 낮을 때 DN의 프로토콜 효율성이 높아지지만 동시성이 높을 때 DN과 MGR의 성능 핫스팟이 모두 정리에 있기 때문입니다.
RPO=0이라는 동일한 전제하에 읽기-쓰기와 쓰기 전용이 혼합된 트랜잭션 시나리오에서 DN의 성능은 MGR_0에 비해 1~14배 향상되고 동시성이 증가할수록 DN의 성능 이점이 향상됩니다. MGR이 기본적으로 성능을 위해 RPO=0을 포기하는 것도 당연합니다.

3.1.3. 2개 장소와 3개 센터

TPS 비교		1	4	16	64	256
oltp_read_only	MGR_1	687.76	2703.5	7030.37	11580.36	14674.7
	MGR_0	687.17	2744.41	7908.44	11535.35	14656
	디엔에이	657.06	2610.58	7591.21	11174.94	14545.45
	MGR_0 대 MGR_1	-0.09%	1.51%	12.49%	-0.39%	-0.13%
	DN 대 MGR_1	-4.46%	-3.44%	7.98%	-3.50%	-0.88%
	DN 대 MGR_0	-4.38%	-4.88%	-4.01%	-3.12%	-0.75%
oltp_읽기_쓰기	MGR_1	29.13	118.64	572.25	997.92	2253.19
	MGR_0	26.94	90.8	313.64	419.17	426.7
	디엔에이	254.87	1146.57	3339.83	5307.85	7171.95
	MGR_0 대 MGR_1	-7.52%	-23.47%	-45.19%	-58.00%	-81.06%
	DN 대 MGR_1	774.94%	866.43%	483.63%	431.89%	218.30%
	DN 대 MGR_0	846.07%	1162.74%	964.86%	1166.28%	1580.79%
oltp_write_only	MGR_1	30.81	145.54	576.61	1387.64	3705.51
	MGR_0	28.68	108.86	387.48	470.5	476.4
	디엔에이	550.11	2171.64	5866.41	10381.72	14478.38
	MGR_0 대 MGR_1	-6.91%	-25.20%	-32.80%	-66.09%	-87.14%
	DN 대 MGR_1	1685.49%	1392.13%	917.40%	648.16%	290.73%
	DN 대 MGR_0	1818.10%	1894.89%	1413.99%	2106.53%	2939.12%

테스트 결과에서 볼 수 있습니다.

읽기 전용 시나리오에서 MGR_1(RPO<>0)을 비교하든 MGR_0(RPO=0)을 비교하든 DN과 MGR의 차이는 -4%에서 7% 사이로 안정적이며 이는 기본적으로 동일하다고 볼 수 있습니다. RPO가 0인지 여부는 읽기 전용 트랜잭션에 영향을 주지 않습니다.
읽기-쓰기와 쓰기 전용이 혼합된 트랜잭션 시나리오에서 DN(RPO=0)의 성능은 MGR_1(RPO<>0)에 비해 2~16배 향상되었으며, 동시성에서 DN의 성능 이점은 분명합니다. 낮고 동시성이 높을 때 이점이 있습니다. 이는 동시성이 낮을 때 DN의 프로토콜 효율성이 높아지지만 동시성이 높을 때 DN과 MGR의 성능 핫스팟이 모두 정리에 있기 때문입니다.
RPO=0이라는 동일한 전제 하에서 읽기-쓰기 및 쓰기 전용 혼합 트랜잭션 시나리오에서 DN의 성능은 MGR_0에 비해 8배에서 29배까지 향상되고 동시성이 증가할수록 DN의 성능 이점이 향상됩니다. MGR이 기본적으로 성능을 위해 RPO=0을 포기하는 것도 당연합니다.

3.1.4.3개 장소와 3개 센터

TPS 비교		1	4	16	64	256
oltp_read_only	MGR_1	688.49	2747.69	7853.91	11722.71	15292.73
	MGR_0	687.66	2756.3	8005.11	11567.89	15055.69
	디엔에이	656.06	2600.35	7657.85	11227.56	14562.86
	MGR_0 대 MGR_1	-0.12%	0.31%	1.93%	-1.32%	-1.55%
	DN 대 MGR_1	-4.71%	-5.36%	-2.50%	-4.22%	-4.77%
	DN 대 MGR_0	-4.60%	-5.66%	-4.34%	-2.94%	-3.27%
oltp_읽기_쓰기	MGR_1	26.01	113.98	334.95	693.34	2030.6
	MGR_0	23.93	110.17	475.68	497.92	511.99
	디엔에이	122.06	525.88	1885.7	3314.9	5889.79
	MGR_0 대 MGR_1	-8.00%	-3.34%	42.02%	-28.19%	-74.79%
	DN 대 MGR_1	369.28%	361.38%	462.98%	378.11%	190.05%
	DN 대 MGR_0	410.07%	377.34%	296.42%	565.75%	1050.37%
oltp_write_only	MGR_1	27.5	141.64	344.05	982.47	2889.85
	MGR_0	25.52	155.43	393.35	470.92	504.68
	디엔에이	171.74	535.83	1774.58	4328.44	9429.24
	MGR_0 대 MGR_1	-7.20%	9.74%	14.33%	-52.07%	-82.54%
	DN 대 MGR_1	524.51%	278.30%	415.79%	340.57%	226.29%
	DN 대 MGR_0	572.96%	244.74%	351.15%	819.15%	1768.36%

테스트 결과에서 볼 수 있습니다.

읽기 전용 시나리오에서 MGR_1(RPO<>0)을 비교하든 MGR_0(RPO=0)을 비교하든 DN과 MGR의 차이는 -5%에서 0% 사이에서 안정적이며 이는 기본적으로 동일하다고 볼 수 있습니다. RPO가 0인지 여부는 읽기 전용 트랜잭션에 영향을 주지 않습니다.
읽기-쓰기 및 쓰기 전용 혼합 트랜잭션 시나리오에서 DN(RPO=0)의 성능은 MGR_1(RPO<>0)에 비해 2~5배 향상되며, 동시성에서 DN의 성능 이점은 분명합니다. 낮고 동시성이 높을 때 이점이 있습니다. 이는 동시성이 낮을 때 DN의 프로토콜 효율성이 높아지지만 동시성이 높을 때 DN과 MGR의 성능 핫스팟이 모두 정리에 있기 때문입니다.
RPO=0이라는 동일한 전제하에 읽기-쓰기와 쓰기 전용이 혼합된 트랜잭션 시나리오에서 DN의 성능은 MGR_0에 비해 2배에서 17배까지 향상되고 동시성이 증가할수록 DN의 성능 이점이 향상됩니다. MGR이 기본적으로 성능을 위해 RPO=0을 포기하는 것도 당연합니다.

3.1.5. 배포 비교

다양한 배포 방법에 따른 성능 변화를 명확하게 비교하기 위해 위 테스트에서 oltp_write_only 시나리오 256 동시성에서 다양한 배포 방법에 따른 MGR 및 DN의 TPS 데이터를 선택하여 컴퓨터실 테스트 데이터를 기준으로 계산했습니다. 도시 간 배포 중 성능 변화의 차이를 인식하기 위해 다양한 배포 방법의 TPS 데이터를 기준 대비 비율로 비교했습니다.

	MGR_1(동시 256개)	DN(동시 256개)	MGR에 비해 DN의 성능 이점
같은 컴퓨터실	16092.02	15137.23	-5.93%
같은 도시에 세 개의 센터가 있음	11666.16 (72.50%)	13241.74 （87.48%）	+13.50%
2개 장소와 3개 센터	3705.51 (23.03%)	14478.38 (95.64%)	+290.72%
3개 장소와 3개 센터	2889.85 (17.96%)	9429.24 (62.29%)	+226.28%

테스트 결과에서 볼 수 있습니다.

배포 방법의 확장으로 인해 MGR_1(RPO<>0)의 TPS가 동일한 컴퓨터실에 배포한 것과 비교하여 동일한 도시의 컴퓨터실 간 배포 성능이 27.5% 감소했습니다. 도시 간 배치(2곳에 3개 센터, 3곳에 3개 센터) 배치 77%~82% 감소 이는 RT의 도시 간 배치 증가에 따른 것입니다.
DN(RTO=0)은 동일한 컴퓨터실에 배포한 경우와 비교하여 같은 도시에 여러 컴퓨터실을 배포한 경우와 2개 장소에 3개 센터를 배포한 경우의 성능이 4%~12% 감소했습니다. . 3개 장소에 3개 센터를 배치한 성능은 높은 네트워크 대기 시간으로 인해 37% 감소했습니다. 이는 도시 전반에 걸쳐 RT 배치가 증가했기 때문이기도 합니다.그러나 DN의 Batch&Pipeline 메커니즘 덕분에 동시성을 높여 도시 간 영향을 해결할 수 있습니다. 예를 들어 3개 장소 및 3개 센터 아키텍처에서 동시성이 512개 이상인 경우 동일한 도시 및 2개의 성능 처리량을 제공합니다. 장소와 3개의 센터는 기본적으로 정렬될 수 있습니다.
도시 간 배포가 MGR_1(RPO<>0)에 큰 영향을 미치는 것을 볼 수 있습니다.

3.1.6. 성능 지터

실제 사용에서는 성능 데이터뿐만 아니라 성능 지터에도 주의를 기울여야 합니다. 결국, 불안감이 롤러코스터와 같다면 실제 사용자 경험은 매우 좋지 않을 것입니다. TPS 실시간 출력 데이터를 모니터링하고 표시합니다. sysbenc 도구 자체가 성능 지터의 출력 모니터링 데이터를 지원하지 않는다는 점을 고려하여 수학적 변동 계수를 비교 지표로 사용합니다.

변동 계수(CV): 변동 계수는 표준 편차를 평균으로 나눈 값으로, 특히 평균 차이가 큰 경우 다양한 데이터 세트의 변동을 비교하는 데 일반적으로 사용됩니다. CV가 클수록 평균에 비해 데이터의 변동이 커집니다.

256개의 동시 oltp_read_write 시나리오를 예로 들어 동일한 전산실의 MGR_1(RPO<>0)과 DN(RPO=0)의 TPS, 동일한 도시의 3개 센터, 2개 장소의 3개 센터, 세 곳의 세 센터. 지터 상황. 실제 지터 그래프는 다음과 같으며, 각 시나리오별 실제 지터 지표 데이터는 다음과 같습니다.

이력서	같은 컴퓨터실	같은 도시에 세 개의 센터가 있음	2개 장소와 3개 센터	3개 장소와 3개 센터
MGR_1	10.04%	8.96%	6.02%	8.63%
디엔에이	3.68%	3.78%	2.55%	4.05%
MGR_1/DN	272.83%	237.04%	236.08%	213.09%

테스트 결과에서 볼 수 있습니다.

MGR의 TPS는 oltp_read_write 시나리오에서 불안정한 상태이며, 이유 없이 갑자기 급격히 떨어지는 현상이 여러 배포 시나리오의 여러 테스트에서 발견되었습니다. 이에 비해 DN은 매우 안정적입니다.
변동계수 CV를 계산하면 MGR의 CV는 6%~10%로 매우 크며, 동일한 전산실에서 지연이 최소화되면 최대값인 10%에 도달하는 반면, DN의 CV는 2%~4로 비교적 안정적입니다. %이며 DN의 성능은 MGR보다 기본적으로 두 배 높습니다.
MGR_1(RPO<>0)의 성능 지터가 상대적으로 크다는 것을 알 수 있다.

3.2. RTO

분산 데이터베이스의 핵심 기능은 고가용성입니다. 클러스터의 모든 노드에 장애가 발생하더라도 전체 가용성에는 영향을 미치지 않습니다. 동일한 컴퓨터실에 하나의 마스터와 두 개의 백업이 배포된 3개 노드의 일반적인 배포 형태에 대해 다음 세 가지 시나리오에서 사용성 테스트를 수행하려고 했습니다.

기본 데이터베이스를 중단한 후 다시 시작하고 프로세스 중에 클러스터가 가용성을 복원하는 RTO 시간을 관찰합니다.
대기 데이터베이스를 중단한 후 다시 시작하여 프로세스 중에 기본 데이터베이스의 가용성 성능을 관찰합니다.

3.2.1. 메인 데이터베이스 다운타임 + 재시작

부하가 없을 때 리더를 종료하고 클러스터 내 각 노드의 상태 변화와 쓰기 가능 여부를 모니터링합니다.

	관리자	디엔에이
정상적으로 시작	0	0
리더를 죽이다	0	0
비정상적인 노드 시간 발견	5	5
3개 노드를 2개 노드로 줄이는 데 걸리는 시간	23	8

	관리자	디엔에이
정상적으로 시작	0	0
리더를 죽이고 자동으로 끌어올림	0	0
비정상적인 노드 시간 발견	5	5
3개 노드를 2개 노드로 줄이는 데 걸리는 시간	23	8
2노드 복원 3노드 시간	37	15

압력이 없는 조건에서 테스트 결과를 보면 다음과 같습니다.

DN의 RTO는 8~15초이며, 노드 2개로 줄이는 데 8초가 걸리고, 노드 3개를 복원하는 데 15초가 걸립니다.
MGR의 RTO는 23~37초입니다. 2개 노드로 다운그레이드하는 데 23초가 걸리고 3개 노드를 복원하는 데 37초가 걸립니다.
RTO 성능 DN이 MGR보다 전반적으로 우수합니다.

3.2.2. 대기 데이터베이스 다운타임 + 재시작

oltp_read_write 시나리오에서 sysbench를 사용하여 16개 스레드의 동시 스트레스 테스트를 수행합니다. 그림의 10초에서 대기 노드를 수동으로 종료하고 sysbench의 실시간 출력 TPS 데이터를 관찰합니다.

테스트 결과 차트에서 볼 수 있습니다.

대기 데이터베이스가 중단된 후 MGR의 주 데이터베이스 TPS가 크게 떨어졌으며 정상 수준으로 돌아오기까지 약 20초 동안 지속되었습니다. 로그 분석에 따르면 여기에는 오류가 있는 노드에 연결할 수 없음을 감지하는 프로세스와 MGR 클러스터에서 오류가 있는 노드를 추방하는 프로세스가 있습니다. 이번 테스트를 통해 MGR 커뮤니티에 오랫동안 떠돌고 있던 결함을 확인했습니다. 3개 노드 중 1개 노드만 사용할 수 없는 경우에도 마찬가지입니다.전체 클러스터가 일정 기간 동안 심각한 지터를 경험하여 사용할 수 없게 되었습니다.
단일 노드 장애가 발생하고 전체 인스턴스를 사용할 수 없는 단일 마스터 MGR 문제를 해결하기 위해 커뮤니티에서는 8.0.27부터 MGR paxos 단일 리더 기능을 도입하여 문제를 해결했지만 기본적으로 꺼져 있습니다. 여기서는 group_replication_paxos_single_leader를 켜고 계속해서 확인합니다. 이번에는 대기 데이터베이스를 중단한 후에도 기본 데이터베이스의 성능이 안정적으로 유지되고 있으며 그 이유는 네트워크 부하 감소와 관련이 있을 것입니다.
DN의 경우 대기 데이터베이스가 중단된 후 기본 데이터베이스 TPS가 즉시 약 20% 증가한 후 안정적으로 유지되었으며 클러스터는 항상 사용 가능했습니다.이는 MGR의 반대입니다. 대기 데이터베이스를 중단한 후 기본 데이터베이스는 매번 나머지 대기 데이터베이스에만 로그를 보내면 되며 네트워크 패킷 송수신 프로세스가 더 효율적이기 때문입니다.

테스트를 계속하여 대기 데이터베이스를 다시 시작 및 복원하고 기본 데이터베이스의 TPS 데이터 변경 사항을 관찰합니다.

테스트 결과 차트에서 볼 수 있습니다.

MGR은 5초 만에 2개 노드에서 3개 노드로 복구되었습니다.하지만 약 12초 동안 메인 라이브러리를 사용할 수 없는 상황도 발생합니다.대기 노드가 마침내 클러스터에 합류했지만 MEMBER_STATE 상태는 항상 RECOVERING으로 현재 데이터가 추적 중임을 나타냅니다.
group_replication_paxos_single_leader가 활성화된 후의 시나리오에서는 대기 데이터베이스 재시작도 확인됩니다. 결과적으로 MGR은 10초 안에 2개 노드에서 3개 노드로 복구됩니다.하지만 여전히 이용할 수 없는 시간은 약 7초 정도였다.이 매개변수는 단일 노드 오류가 발생하고 전체 인스턴스를 사용할 수 없는 단일 마스터 MGR의 문제를 완전히 해결할 수 없는 것 같습니다.
DN의 경우 대기 데이터베이스는 10초 안에 2개 노드에서 3개 노드로 복구되고 기본 데이터베이스는 계속 사용 가능합니다. 여기서는 TPS에 단기적인 변동이 있을 수 있습니다. 이는 다시 시작된 대기 데이터베이스의 로그 복제 지연이 뒤쳐져 있고 지연된 로그를 기본 데이터베이스에서 가져와야 하기 때문입니다. 기본 데이터베이스는 로그 검토 후 전반적인 성능이 안정됩니다.

3.3. RPO

MGR 다수 실패 RPO<>0 시나리오를 구성하기 위해 커뮤니티 자체의 MTR Case 방법을 사용하여 MGR에 대한 결함 주입 테스트를 수행합니다.


--echo
--echo ############################################################
--echo # 1. Deploy a 3 members group in single primary mode.
--source include/have_debug.inc
--source include/have_group_replication_plugin.inc
--let $group_replication_group_name= aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
--let $rpl_group_replication_single_primary_mode=1
--let $rpl_skip_group_replication_start= 1
--let $rpl_server_count= 3
--source include/group_replication.inc
 
--let $rpl_connection_name= server1
--source include/rpl_connection.inc
--let $server1_uuid= `SELECT @@server_uuid`
--source include/start_and_bootstrap_group_replication.inc
 
--let $rpl_connection_name= server2
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--echo
--echo ############################################################
--echo # 2. Init data
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
 
--source include/rpl_sync.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--echo
--echo ############################################################
--echo # 3. Mock crash majority members
 
--echo # server 2 wait before write relay log
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
--echo # server 3 wait before write relay log
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
 
--echo # server 1 commit new transaction
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
INSERT INTO t1 VALUES(2);
# server 1 commit t1(c1=2) record
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 1 crash
--source include/kill_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 3 check
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo
--echo ############################################################
--echo # 4. Check alive members, lost t1(c1=2) record
 
--echo # server 3 check
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 lost t1(c1=2) record
SELECT * FROM t1;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 lost t1(c1=2) record
SELECT * FROM t1;


!include ../my.cnf
 
[mysqld.1]
loose-group_replication_member_weight=100
 
[mysqld.2]
loose-group_replication_member_weight=90
 
[mysqld.3]
loose-group_replication_member_weight=80
 
[ENV]
SERVER_MYPORT_3=		@mysqld.3.port
SERVER_MYSOCK_3=		@mysqld.3.socket

사례 실행 결과는 다음과 같습니다.


 
############################################################
# 1. Deploy a 3 members group in single primary mode.
include/group_replication.inc [rpl_server_count=3]
Warnings:
Note	####	Sending passwords in plain text without SSL/TLS is extremely insecure.
Note	####	Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
[connection server1]
[connection server1]
include/start_and_bootstrap_group_replication.inc
[connection server2]
include/start_group_replication.inc
[connection server3]
include/start_group_replication.inc
 
############################################################
# 2. Init data
[connection server1]
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
include/rpl_sync.inc
SELECT * FROM t1;
c1
1
[connection server2]
SELECT * FROM t1;
c1
1
[connection server3]
SELECT * FROM t1;
c1
1
 
############################################################
# 3. Mock crash majority members
# server 2 wait before write relay log
[connection server2]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 3 wait before write relay log
[connection server3]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 1 commit new transaction
[connection server1]
INSERT INTO t1 VALUES(2);
SELECT * FROM t1;
c1
1
2
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13000	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13002	ONLINE	SECONDARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 1 crash
# Kill the server
# sleep enough time for electing new leader
 
# server 3 check
[connection server3]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 3 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
# server 2 check
[connection server2]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	UNREACHABLE	SECONDARY	8.0.32	XCom
# server 2 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
############################################################
# 4. Check alive members, lost t1(c1=2) record
# server 3 check
[connection server3]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 3 lost t1(c1=2) record
SELECT * FROM t1;
c1
1
 
# server 2 check
[connection server2]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 2 lost t1(c1=2) record
SELECT * FROM t1;
c1
1

누락된 숫자를 재현하는 사건의 대략적인 논리는 다음과 같습니다.

MGR은 단일 마스터 모드인 서버 1/2/3의 3개 노드로 구성됩니다. 여기서 서버 1은 기본 데이터베이스이고 1개의 레코드 c1=1을 초기화합니다.
오류 주입 서버 2/3은 릴레이 로그를 작성할 때 중단됩니다.
Server 1 노드에 연결하여 c1=2라는 레코드를 썼고 트랜잭션 커밋도 성공을 반환했습니다.
그러면 Mock server1이 비정상적으로 충돌합니다(머신 장애, 복구 불가, 접속 불가). 이때 Server 2/3이 대다수를 차지하게 됩니다.
서버 2/3을 정상적으로 다시 시작하지만(빠른 복구), 서버 2/3은 클러스터를 사용 가능한 상태로 복원할 수 없습니다.
Server 2/3 노드에 연결하여 데이터베이스 레코드를 쿼리합니다. c1=1의 레코드만 보입니다. (Server 2/3은 c1=2를 잃었습니다.)

위의 경우에 따르면, MGR의 경우 대부분의 서버가 다운되어 메인 데이터베이스를 사용할 수 없는 경우, 스탠바이 데이터베이스를 복원한 후 RPO<>0의 데이터 손실이 발생하며 성공적인 커밋 기록이 남게 됩니다. 원래 클라이언트에 반환된 내용은 손실됩니다.

DN의 경우 다수를 달성하려면 로그가 다수 유지되어야 하므로 위의 시나리오에서도 데이터가 손실되지 않고 RPO=0이 보장될 수 있습니다.

3.4. 대기 데이터베이스 재생 지연

MySQL의 기존 활성-대기 모드에서 대기 데이터베이스에는 일반적으로 IO 스레드와 Apply 스레드가 포함됩니다. Paxos 프로토콜이 도입된 후 IO 스레드는 주로 대기 데이터베이스의 복제 지연을 동기화합니다. 대기 데이터베이스의 재생 적용 오버헤드에 따라 달라지며 여기서는 대기 데이터베이스 재생 지연이 됩니다.

우리는 sysbench를 사용하여 oltp_write_only 시나리오를 테스트하고 100개의 동시성 및 다양한 이벤트 수에서 대기 데이터베이스 재생의 지연 기간을 테스트합니다.대기 데이터베이스 재생 지연 시간은 Performance_schema.replication_applier_status_by_worker 테이블의 APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 열을 모니터링하여 각 작업자가 실시간으로 작업 중인지 확인하여 복제가 종료되었는지 확인하면 확인할 수 있습니다.

테스트 결과 차트에서 볼 수 있습니다.

동일한 양의 기록된 데이터에서 모든 로그의 DN 대기 데이터베이스 재생 완료 시간은 MGR의 시간 소비보다 훨씬 낫습니다. MGR의 3~4%에 불과합니다. 이는 활성/대기 전환의 적시성에 매우 중요합니다.
쓰기 횟수가 증가함에 따라 MGR에 비해 DN의 대기 데이터베이스 재생 대기 시간 이점은 계속 유지되며 매우 안정적입니다.
대기 데이터베이스 재생 지연 원인을 분석하여 MGR의 대기 데이터베이스 재생 전략은 기본값인 EVENTUAL을 사용하여 group_replication_consistency를 채택합니다. 즉, RO 및 RW 트랜잭션은 실행 전에 이전 트랜잭션의 적용을 기다리지 않습니다. 이렇게 하면 기본 데이터베이스의 최대 쓰기 성능을 보장할 수 있지만 대기 데이터베이스 지연은 상대적으로 커집니다(기본 데이터베이스의 고성능 쓰기 대신 대기 데이터베이스 지연 및 RPO=0을 희생하고 전류 제한 기능을 켜는 방식). MGR의 성능 균형을 맞출 수 있으며 대기 데이터베이스는 지연되지만 기본 데이터베이스의 성능은 저하됩니다)

3.5. 테스트 요약

		관리자	디엔에이
성능	거래 읽기	평평한	평평한
	거래 쓰기	RPO<>0일 때 성능은 DN만큼 좋지 않습니다. RPO=0이면 성능이 DN보다 훨씬 떨어집니다. 도시 간 배포 성능이 27%~82% 심각하게 감소했습니다.	쓰기 트랜잭션 성능은 MGR보다 훨씬 높습니다. 도시 간 배포 성능이 4%에서 37%로 감소합니다.
	지터	성능 지터가 심하고 지터 범위는 6~10%입니다.	MGR의 절반에 불과한 3%로 비교적 안정적입니다.
RTO	기본 데이터베이스가 다운되었습니다	5초 만에 이상 징후가 발견됐고, 23초 만에 노드 2개로 줄었다.	5초 만에 이상현상이 발견됐고, 8초 만에 노드 2개로 줄어들었다.
	기본 라이브러리 다시 시작	5초 만에 이상 징후가 발견됐고, 37초 만에 3개 노드가 복구됐다.	5초 안에 이상을 감지하고, 15초 안에 3개의 노드를 복구합니다.
	백업 데이터베이스 가동 중지 시간	메인 데이터베이스의 트래픽이 20초 동안 0으로 떨어졌습니다. group_replication_paxos_single_leader를 명시적으로 켜면 이 문제를 완화할 수 있습니다.	기본 데이터베이스의 지속적인 고가용성
	대기 데이터베이스 재시작	메인 데이터베이스의 트래픽이 10초 동안 0으로 떨어졌습니다. group_replication_paxos_single_leader를 명시적으로 켜는 것도 효과가 없습니다.	기본 데이터베이스의 지속적인 고가용성
RPO	사례 재발	다수당이 무너지면 RPO<>0 성능과 RPO=0은 둘 다 가질 수 없습니다.	RPO = 0
대기 데이터베이스 지연	백업 데이터베이스 재생 시간	활성과 대기 사이의 지연이 매우 깁니다. 성능과 기본 백업 지연 시간은 동시에 달성할 수 없습니다.	전체 대기 데이터베이스 재생에 소요된 총 시간은 MGR의 4%이며 이는 MGR의 25배입니다.
매개변수	주요 매개변수	group_replication_flow_control_mode 흐름 제어는 기본적으로 활성화되어 있으며 성능 향상을 위해 이를 끄도록 구성해야 합니다. 복제_optimize_for_static_plugin_config 정적 플러그인 최적화는 기본적으로 꺼져 있으며 성능을 향상하려면 켜야 합니다. group_replication_paxos_single_leader는 기본적으로 꺼져 있으며 대기 데이터베이스가 다운되었을 때 메인 데이터베이스의 안정성을 향상시키기 위해 켜져야 합니다. group_replication_consistency는 기본적으로 꺼져 있으며 RPO=0을 보장하지 않습니다. RPO=0이 필요한 경우 AFTER를 구성해야 합니다. 기본 group_replication_transaction_size_limit는 143M이며 대규모 트랜잭션이 발생할 경우 늘려야 합니다. binlog_transaction_dependent_tracking의 기본값은 COMMIT_ORDER입니다. 대기 데이터베이스 재생 성능을 향상시키려면 MGR을 WRITESET로 조정해야 합니다.	기본 구성으로 전문가가 구성을 사용자 정의할 필요가 없습니다.

4. 요약

심층적인 기술적 분석과 성능 비교를 거쳐,폴라DB-X 자체 개발한 X-Paxos 프로토콜과 일련의 최적화된 설계를 통해 DN은 성능, 정확성, 가용성 및 리소스 오버헤드 측면에서 MySQL MGR에 비해 많은 이점을 입증했습니다. 그러나 MGR은 MySQL 생태계에서도 중요한 위치를 차지하고 있습니다. , 대기 데이터베이스 중단 지터, 기계실 간 재해 복구 성능 변동, 안정성 등 다양한 상황을 고려해야 합니다. 따라서 MGR을 효과적으로 활용하려면 전문적인 기술 및 운영 및 유지 관리 팀을 갖추고 있어야 합니다. 지원하다.

대규모, 높은 동시성 및 고가용성 요구 사항에 직면했을 때 PolarDB-X 스토리지 엔진은 기본 시나리오에서 MGR과 비교할 때 고유한 기술적 이점과 탁월한 성능을 제공합니다.폴라DB-XDN 기반 중앙집중형(표준 버전)은 기능과 성능의 균형이 잘 잡혀 있어 경쟁력이 매우 높은 데이터베이스 솔루션입니다.

기술나눔