MySQL Binlog 스토리지 시스템의 아키텍처를 설계하는 방법

1. 킹버스 소개

1.1 킹버스란 무엇인가요?

Kingbus는 Raft Strong Consistency 프로토콜을 기반으로 하는 분산형 MySQL binlog 스토리지 시스템입니다. 실제 마스터의 binlog를 동기화하고 이를 분산 클러스터에 저장하는 MySQL 슬레이브 역할을 할 수 있습니다. 동시에 클러스터의 binlog를 다른 슬레이브와 동기화하는 MySQL 마스터 역할도 합니다. kingbus에는 다음과 같은 기능이 있습니다:

MySQL 복제 프로토콜과 호환되며 Gtid를 통해 마스터의 binlog를 동기화하고 슬레이브가 Gtid를 통해 kingbus에서 binlog를 가져오도록 지원합니다.

지역 간 데이터 복제인 Kingbus는 뗏목 프로토콜을 통해 지역 간 데이터 복제를 지원합니다. 클러스터에 기록된 binlog 데이터는 여러 노드에서 강력한 일관성을 보장하며 binlog 순서는 마스터의 순서와 완전히 일치합니다.

고가용성, Kingbus는 Raft 강력한 합의 프로토콜을 기반으로 구축되었기 때문에 클러스터 노드의 절반 이상이 생존할 때 전체 binlog 풀 및 푸시 서비스의 고가용성을 달성할 수 있습니다.

1.2 Kingbus는 어떤 문제를 해결할 수 있나요?

Kingbus는 마스터의 네트워크 전송 트래픽을 줄일 수 있습니다. 하나의 마스터와 여러 개의 슬레이브가 있는 복제 토폴로지에서는 마스터가 각 슬레이브에 binlog를 보내야 합니다. 슬레이브가 너무 많으면 네트워크 트래픽이 마스터 네트워크 카드의 상한에 도달할 가능성이 높습니다. 예를 들어, 마스터가 대용량 테이블 삭제나 온라인 DDL 삭제 등의 작업을 수행하면 즉시 대량의 binlog 이벤트가 발생할 수 있습니다. 마스터에 10개의 슬레이브가 연결되면 마스터의 네트워크 카드 트래픽이 10배로 증폭됩니다. . 마스터가 기가비트 네트워크 카드를 사용하는 경우 10MB/S 이상의 트래픽이 생성되면 네트워크 카드가 가득 찰 수 있습니다. 킹버스를 통해 마스터에 연결하면 슬레이브를 여러 시스템에 분산하여 전송 트래픽의 균형을 맞출 수 있습니다.

마스터 장애 조치 프로세스를 단순화하려면 킹버스에 연결된 슬레이브를 마스터로 승격하고 킹버스를 새 마스터로 리디렉션하기만 하면 됩니다. 다른 슬레이브는 여전히 킹버스에 연결되어 있으며 복제 토폴로지는 변경되지 않습니다.

binlog 파일을 저장하기 위해 마스터가 사용하는 공간을 저장합니다. 일반적으로 MySQL은 더 비싼 SSD를 사용합니다. binlog 파일이 많은 공간을 차지하면 MySQL에 저장되는 데이터를 줄여야 합니다. 모든 binlog를 kingbus

에 저장하여 마스터에 저장되는 binlog 파일 수를 줄일 수 있습니다. 이기종 복제를 지원합니다. Alibaba의 오픈 소스 운하를 통해 Kingbus에 연결합니다. Kingbus는 binlog를 운하에 지속적으로 푸시한 다음 이를 kafka 메시지 대기열에 푸시하고 최종적으로 Hive를 통해 직접 SQL을 작성하여 실시간을 달성합니다. 사업 분석.

2. 킹버스 전체 구조

kingbus의 전체 구조는 아래 그림과 같습니다.

Kingbus에서는 raft 로그와 mysql binlog가 통합되어 있으며 raft 로그의 데이터 부분은 binlog 이벤트이므로 두 가지 유형을 저장할 필요가 없습니다. 로그를 별도로 저장하여 저장 공간을 절약하세요. kingbus는 뗏목 노드 투표 정보 및 일부 특수 binlog 이벤트(FORMAT_DESCRIPTION_EVENT)의 특정 콘텐츠와 같은 일부 메타 정보를 저장해야 하기 때문입니다.

Raft는 etcd raft 라이브러리를 사용하여 kingbus 클러스터의 리드 선택, 로그 복제 및 기타 기능을 복제합니다.

Binlog 동기화 장치는 Raft 클러스터의 리드 노드에서만 실행됩니다. 전체 클러스터에는 동기화 장치가 하나만 있습니다. 동기화 장치는 슬레이브인 척하고 마스터에 대한 마스터-슬레이브 복제 연결을 설정합니다. 마스터는 동기화 장치가 전송한 실행_gtid_set을 기반으로 동기화 장치가 수락한 binlog 이벤트를 필터링하고 동기화 장치가 허용하지 않은 binlog 이벤트만 보냅니다. 이 복제 프로토콜은 MySQL 마스터-슬레이브 복제 메커니즘과 완벽하게 호환됩니다. syncer는 binlog 이벤트를 수신한 후 binlog 이벤트 유형에 따라 일부 처리를 수행한 다음 binlog 이벤트를 메시지로 캡슐화하여 raft 클러스터에 제출합니다. Raft 알고리즘을 통해 이 binlog 이벤트는 여러 노드에 저장되고 강력한 일관성을 달성할 수 있습니다.

Binlog 서버는 복제 프로토콜을 구현하는 마스터입니다. 실제 슬레이브는 binlog 서버가 모니터링하는 포트에 연결할 수 있습니다. binlog 서버는 binlog 이벤트를 슬레이브에 보내는 전체 프로세스를 참조하여 구현됩니다. MySQL 복제 프로토콜. binlog 이벤트가 슬레이브에 전송되지 않으면 binlog 서버는 주기적으로 하트비트 이벤트를 슬레이브에 보내 복제 연결을 유지합니다.

API 서버는 다음을 포함하여 전체 kingbus 클러스터의 관리를 담당합니다.

Raft 클러스터 멤버십 운영, 클러스터 상태 보기, 노드 추가, 노드 제거, 노드 정보 업데이트 등

Binlog syncer 관련 작업: binlog syncer를 시작하고, binlog syncer를 중지하고, binlog syncer 상태를 확인합니다.

Binlog 서버 관련 작업, binlog 서버 시작, binlog 서버 중지 및 binlog 서버 상태 확인. 서버 계층의 다양한 이상은 뗏목 계층에 영향을 미치지 않습니다. 서버는 요청에 따라 시작 및 중지될 수 있는 플러그인으로 이해될 수 있습니다. 향후 Kingbus를 확장할 때는 관련 로직을 갖춘 서버만 구현하면 됩니다. 예를 들어 kafka 프로토콜 서버를 구현하는 경우 kafka 클라이언트를 통해 kingbus에서 메시지를 사용할 수 있습니다.

3.kingbus 코어 구현

3.1 스토리지의 핵심 구현

저장소에는 두 가지 로그 형태가 있는데, 하나는 raft 알고리즘에 의해 생성되어 사용되는 raft 로그(이하 raft 로그)이고, 다른 하나는 사용자 형태의 로그(즉, mysql binlog 이벤트)이다. . 스토리지 설계에서는 두 개의 로그 양식이 하나의 로그 항목으로 결합됩니다. 다른 헤더 정보로만 구별됩니다. 저장소는 아래 그림과 같이 데이터 파일과 인덱스 파일로 구성됩니다.

세그먼트의 크기는 고정되어 있으며(1GB) 추가 쓰기만 가능합니다. 이름은 세그먼트의 뗏목 인덱스 범위를 나타내는 first_raft_index-last_raft_index입니다.

마지막 세그먼트만 쓸 수 있으며 파일 이름은 first_raft_index-inprogress입니다. 다른 세그먼트는 읽기 전용입니다.

읽기 전용 세그먼트와 해당 인덱스 파일은 mmap을 통해 쓰고 읽습니다.

마지막 세그먼트의 인덱스 내용은 디스크와 메모리 모두에 저장됩니다. 인덱스를 읽으려면 메모리에서만 읽어야 합니다.

3.2 etcd raft 라이브러리 사용

Etcd raft 라이브러리는 적용된 로그, 커밋된 항목 등을 처리할 때 단일 스레드입니다. 특정 기능에 대한 링크를 참조하세요. 이 기능의 처리 시간은 최대한 짧아야 합니다. 처리 시간이 뗏목 선택 시간을 초과하면 클러스터가 다시 선택됩니다. 이 점은 특별한 주의가 필요합니다.

3.3 binlog syncer의 핵심 구현

binlog syncer의 주요 작업은 다음과 같습니다.

binlog 이벤트 가져오기

binlog 이벤트 구문 분석 및 처리

binlog 이벤트를 raft 클러스터에 제출합니다. 분명히 파이프라인 메커니즘을 사용하면 전체 프로세스의 처리 속도를 향상시킬 수 있습니다. Kingbus는 별도의 고루틴을 사용하여 각 단계를 처리하고 파이프라인을 통해 여러 단계를 연결합니다. binlog syncer는 binlog 이벤트를 하나씩 수신하므로 syncer가 중단된 후 마스터를 다시 연결해야 할 수도 있습니다. 이때 마지막 트랜잭션이 불완전할 수 있습니다. Kingbus는 고유한 기능을 통해 MySQL 소스 코드를 참조하여 완벽하게 구현된 트랜잭션 무결성 분석 기능을 구현합니다.

3.4 binlog 서버의 핵심 구현

Binlog 서버는 마스터의 기능을 구현합니다. 슬레이브가 binlog 서버와 복제 연결을 설정하면 슬레이브는 관련 명령을 보내고 binlog 서버는 이러한 명령에 응답해야 합니다. 마지막으로 binlog 이벤트를 슬레이브에 보냅니다. 각 슬레이브에 대해 binlog 서버는 goroutine을 시작하여 raft 로그를 지속적으로 읽고 관련 헤더 정보를 제거한 후 binlog 이벤트로 변환한 후 슬레이브에 보냅니다.

위 내용은 MySQL Binlog 스토리지 시스템의 아키텍처를 설계하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!