하나의 기사로 MySql 마스터-슬레이브 동기화에 대한 철저한 이해

이 글은 MySQL의 마스터-슬레이브 동기화와 그 작동 원리 등을 주로 소개합니다. 관심 있는 친구들은 함께 살펴보고 배울 수 있습니다.

1 소개

안녕하세요 여러분, MySQL은 모두가 가장 일반적으로 사용하는 데이터베이스입니다. 다음은 mysql에 대한 기본 지식을 정리하기 위해 mysql 마스터-슬레이브 동기화에 대한 지식 포인트를 공유합니다. 오류가 있으면 알려주세요.

2 MySql 마스터-슬레이브 동기화 개요

MySQL 마스터-슬레이브 동기화, 즉 MySQL 복제는 하나의 데이터베이스 서버에서 여러 데이터베이스 서버로 데이터를 동기화할 수 있습니다. MySQL 데이터베이스에는 마스터-슬레이브 동기화 기능이 제공됩니다. 구성 후 데이터베이스 및 테이블 구조를 기반으로 다양한 방식으로 마스터-슬레이브 동기화를 실현할 수 있습니다.

Redis는 고성능 인메모리 데이터베이스이지만 오늘날의 주인공은 아닙니다. MySQL은 디스크 파일 기반 관계형 데이터베이스이므로 읽기 속도는 느리지만 강력하고 사용할 수 있습니다. 영구 데이터 저장용. 실제 작업에서는 MySQL과 연계하여 Redis를 캐시로 사용하는 경우가 많으며, 데이터 접근 요청이 있을 경우 먼저 캐시에서 검색하고, 존재하지 않으면 직접 꺼냅니다. 데이터베이스에 다시 액세스하게 됩니다. 이렇게 하면 읽기 효율성이 향상되어 백엔드 데이터베이스에 대한 액세스 부담도 줄어듭니다. Redis와 같은 캐시 아키텍처를 사용하는 것은 동시성 아키텍처에서 매우 중요한 부분입니다.

비즈니스 볼륨이 지속적으로 증가함에 따라 데이터베이스에 대한 부담도 계속 증가할 것입니다. 캐시의 빈번한 변경도 데이터의 쿼리 결과에 크게 의존하므로 데이터 쿼리 효율성이 떨어지는 등의 문제가 발생합니다. 부하가 높고 연결이 너무 많습니다. 전자 상거래 시나리오의 경우 읽기는 많고 쓰기는 적은 일반적인 시나리오가 많이 있습니다. MySQL용 마스터-슬레이브 아키텍처를 사용하고 읽기와 쓰기를 분리하여 마스터 서버(마스터)가 쓰기 요청을 처리하고 슬레이브 서버가 처리하도록 할 수 있습니다. (슬레이브)은 읽기 요청을 처리하여 데이터베이스의 동시 처리 기능을 더욱 향상시킬 수 있습니다. 아래 그림과 같이:

위 그림에서 두 개의 슬레이브 라이브러리를 추가한 것을 볼 수 있습니다. 이 두 슬레이브 라이브러리는 함께 많은 수의 읽기 요청을 견딜 수 있으며 메인 라이브러리에 대한 압력을 공유할 수 있습니다. 슬레이브 데이터베이스는 마스터-슬레이브 복제를 통해 마스터 데이터베이스의 데이터를 지속적으로 동기화하여 슬레이브 데이터베이스의 데이터가 마스터 데이터베이스의 데이터와 일치하는지 확인합니다.

다음으로 마스터-슬레이브 동기화 기능과 마스터-슬레이브 동기화가 어떻게 구현되는지 살펴보겠습니다.

3 마스터-슬레이브 동기화의 역할

일반적으로 모든 시스템이 데이터베이스에 대한 마스터-슬레이브 아키텍처를 설계할 필요는 없습니다. 왜냐하면 우리의 목적이 높은 동시 액세스를 향상시키는 것이라면 아키텍처 자체에 특정 비용이 있기 때문입니다. 데이터베이스 효율성을 위해서는 먼저 SQL 문과 인덱스를 최적화하여 데이터베이스의 최대 성능을 최대한 활용해야 합니다. 두 번째로 Redis 및 MongoDB와 같은 캐싱 도구를 사용하여 메모리 내 데이터베이스에 데이터를 저장하는 등의 캐싱 전략을 채택해야 합니다. 읽기 효율성을 높이기 위한 마지막 단계는 데이터베이스에 마스터-슬레이브 아키텍처를 채택하고 읽기와 쓰기를 분리하는 것입니다. 시스템을 사용하고 유지하는 데 드는 비용은 아키텍처 업그레이드에 따라 점차 증가합니다.

본론으로 돌아가서, 마스터-슬레이브 동기화는 데이터베이스의 처리량을 향상시킬 수 있을 뿐만 아니라 다음 세 가지 측면도 있습니다.

3.1 읽기 및 쓰기 분리

마스터-슬레이브 복제를 통해 데이터를 동기화할 수 있습니다. , 읽기 및 쓰기 분리는 데이터베이스의 동시 처리 기능을 향상시킵니다. 간단히 말해서 데이터는 여러 데이터베이스에 배치되며 그 중 하나는 마스터 데이터베이스이고 나머지는 슬레이브 데이터베이스입니다. 기본 데이터베이스의 데이터가 변경되면 해당 데이터는 자동으로 슬레이브 데이터베이스에 동기화되며, 우리 프로그램은 읽기-쓰기 분리 방법을 사용하여 슬레이브 데이터베이스에서 데이터를 읽을 수 있습니다. 전자 상거래 애플리케이션은 종종 "더 많이 읽고 더 적게 쓰기"를 수행하며, 읽기와 쓰기를 분리하면 더 높은 동시 액세스를 달성할 수 있습니다. 원래는 모든 읽기 및 쓰기 압력이 하나의 서버에서 부담되었습니다. 이제는 여러 서버가 읽기 요청을 공동으로 처리하여 기본 데이터베이스에 대한 부담을 줄입니다. 또한, 슬레이브 서버에서 로드 밸런싱을 수행할 수 있으므로 정책에 따라 다양한 읽기 요청이 여러 슬레이브 서버에 고르게 분산되어 읽기가 더 원활해집니다. 원활한 읽기를 위한 또 다른 이유는 잠금 테이블의 영향을 줄이는 것입니다. 예를 들어, 쓰기를 메인 라이브러리에 맡기면 메인 라이브러리에서 쓰기 잠금이 발생하더라도 슬레이브 라이브러리의 쿼리 작업에는 영향을 미치지 않습니다.

3.2 데이터 백업

마스터-슬레이브 동기화는 데이터 서비스 제공에 영향을 주지 않고 기본 데이터베이스의 정상적인 작동 중에 백업되는 데이터 핫 백업 메커니즘과도 동일합니다.

3.3 고가용성

데이터 백업은 실제로 중복 메커니즘입니다. 이 중복 방법을 통해 데이터베이스의 고가용성을 교환할 수 있으며, 서버에 장애가 발생하거나 사용할 수 없는 경우 신속하게 장애 조치를 수행하고 슬레이브를 허용할 수 있습니다. 데이터베이스는 서비스의 정상적인 작동을 보장하기 위해 마스터 데이터베이스 역할을 합니다. 전자상거래 시스템 데이터베이스의 고가용성 SLA 지표에 대해 알아볼 수 있습니다.

4 마스터-슬레이브 동기화 원리

마스터-슬레이브 동기화의 원리를 말하자면, 데이터베이스의 중요한 로그 파일, 즉 데이터베이스를 업데이트하는 이벤트를 기록하는 Binlog 바이너리 파일을 이해해야 합니다. 실제로 마스터-슬레이브 동기화의 원리는 기본입니다. Binlog를 기반으로 한 데이터 동기화에 대해 설명합니다.

마스터-슬레이브 복제 과정에서 작업은 세 개의 스레드를 기반으로 합니다. 하나는 마스터 노드에 있는 binlog 덤프 스레드이고, 나머지 두 스레드는 모두 I/O 스레드와 SQL 스레드입니다. 는 아래와 같이 슬레이브 노드에 있습니다.

위 그림과 결합하여 마스터-슬레이브 복제의 핵심 프로세스를 이해해 보겠습니다.

• 마스터 노드가 쓰기 요청을 받으면 쓰기 요청이 수행됩니다. 추가, 삭제 또는 수정 작업이 될 수 있습니다. 이 때 쓰기 요청의 모든 업데이트 작업은 binlog 로그에 기록됩니다.

• 마스터 노드는 그림의 Slave01 노드와 Slave02 노드와 같은 데이터를 슬레이브 노드에 복사합니다. 이 과정에서 슬레이브 노드가 연결되면 먼저 각 슬레이브 노드가 마스터 노드에 연결되어야 합니다. 마스터 노드에 전송하면 마스터 노드는 각 슬레이브 노드에 대해 binlog 덤프 스레드를 생성하여 각 슬레이브 노드에 binlog 로그를 보냅니다.

• binlog 덤프 스레드는 마스터 노드의 binlog 로그를 읽은 다음 binlog 로그를 슬레이브 노드의 I/O 스레드로 보냅니다. 메인 라이브러리가 이벤트를 읽으면 Binglog가 잠깁니다. 읽기가 완료되면 잠금이 해제됩니다.

• binlog 로그를 받은 후 슬레이브 노드의 I/O 스레드는 먼저 binlog 로그를 로컬 릴레이 로그에 기록하고 binlog 로그는 릴레이 로그에 저장됩니다.

• 슬레이브 노드의 SQL 스레드는 Relaylog의 binlog 로그를 읽고 이를 특정 추가, 삭제 및 수정 작업으로 구문 분석하고 마스터 노드에서 수행된 이러한 작업을 슬레이브 노드에서 다시 실행합니다. 데이터 복원이 이루어지므로 마스터 노드와 슬레이브 노드의 데이터 일관성이 보장될 수 있습니다.

마스터-슬레이브 동기화의 데이터 내용은 실제로 바이너리 로그(Binlog)이지만 실제로는 이러한 이벤트가 데이터베이스의 업데이트 작업에 해당합니다. INSERT, UPDATE, DELETE 등

또한 모든 버전의 MySQL이 기본적으로 서버의 바이너리 로그를 활성화하는 것은 아니라는 점에 유의해야 합니다. 마스터-슬레이브 동기화를 수행할 때 먼저 서버가 바이너리 로그를 활성화했는지 확인해야 합니다.

바이너리 로그는 네트워크 전송 중에 200ms와 같은 약간의 지연이 발생합니다. 이로 인해 슬레이브 라이브러리에서 사용자가 읽은 데이터가 최신 데이터가 아닐 수 있으며 이로 인해 마스터도 실패할 수 있습니다. 동기화로 인해 데이터 불일치가 발생합니다. 예를 들어, 레코드를 업데이트하면 메인 데이터베이스에서 이 작업이 완료되고 100ms 등의 짧은 시간 내에 동일한 레코드를 다시 읽습니다. 이때 슬레이브 데이터베이스는 데이터 동기화가 완료되지 않았습니다. 그렇다면 우리가 라이브러리에서 읽은 데이터는 오래된 데이터입니다. 이 상황에서는 어떻게 해야 할까요?

5 마스터-슬레이브 동기화의 데이터 일관성 문제를 해결하는 방법

상상할 수 있듯이 우리가 조작하려는 데이터가 모두 동일한 데이터베이스에 저장되어 있으면 데이터를 업데이트할 때 레코드를 추가할 수 있습니다. , 읽을 때 데이터 불일치가 발생하지 않도록 합니다. 하지만 이때 슬레이브 라이브러리의 역할은 읽기와 쓰기를 분리하지 않고 데이터를 백업하여 메인 라이브러리의 압력을 공유하는 것입니다.

그래서 우리는 읽기와 쓰기를 분리할 때 마스터-슬레이브 동기화의 데이터 불일치 문제, 즉 마스터와 슬레이브 간의 데이터 복제 방법 문제를 해결할 방법을 찾아야 합니다. 약한 것에서 강한 것으로 나누는 방법에는 다음 세 가지 복사 방법이 있습니다.

5.1 완전 동기 복제

우선, 완전 동기 복제는 메인 라이브러리가 트랜잭션을 완료한 후 처리 결과가 클라이언트에 반환되기 전에 모든 슬레이브 라이브러리도 트랜잭션을 완료해야 함을 의미합니다. 동기 복제 데이터 일관성은 보장되지만 마스터 데이터베이스는 모든 슬레이브 데이터베이스가 트랜잭션을 완료할 때까지 기다려야 하므로 성능이 상대적으로 낮습니다. 아래와 같이:

5.2 비동기 복제

비동기 복제는 메인 라이브러리가 항목을 제출할 때 binlog 덤프 스레드가 binlog 덤프 스레드가 전송되면 binlog 로그를 슬레이브 라이브러리로 보내도록 알린다는 것을 의미합니다. binlog 로그를 슬레이브 라이브러리에 저장하면 슬레이브 라이브러리가 트랜잭션을 동기식으로 완료할 때까지 기다릴 필요가 없으며 마스터 라이브러리가 처리 결과를 클라이언트에 반환합니다.

메인 라이브러리는 자체적으로 트랜잭션을 완료하기만 하면 되기 때문에 슬레이브 라이브러리가 트랜잭션을 완료했는지 여부를 신경 쓰지 않고 처리 결과를 클라이언트에 반환할 수 있습니다. 이로 인해 단기적인 마스터-슬레이브 데이터 불일치가 발생할 수 있습니다. 메인 라이브러리가 방금 트랜잭션을 완료한 경우, 삽입된 새 데이터가 데이터베이스에서 즉시 쿼리되는 경우 쿼리되지 않을 수 있습니다.

게다가 마스터 데이터베이스가 물건을 제출한 후 충돌이 발생하면 binlog가 슬레이브 데이터베이스에 동기화할 시간이 없을 수 있습니다. 이때 복구 실패로 인해 마스터 노드와 슬레이브 노드가 전환되면 데이터 손실이 발생하므로 비동기식 복제는 성능은 높지만 데이터 일관성 측면에서는 가장 취약합니다.

Mysql 마스터-슬레이브 복제는 기본적으로 비동기 복제를 복제 전략으로 사용합니다.

5.3 반동기 복제

MySQL은 버전 5.5부터 반동기 복제를 지원하기 시작합니다. 원칙은 클라이언트가 COMMIT를 제출한 후 결과가 클라이언트에 직접 반환되지 않고 오히려 하나 이상의 슬레이브 라이브러리가 Binlog를 수신하고 이를 클라이언트에 반환하기 전에 릴레이 로그에 쓸 때까지 기다립니다. 이것의 장점은 데이터의 일관성을 향상시킨다는 점이다. 물론 비동기식 복제에 비해 네트워크 연결이 하나 이상 더 지연되고 기본 데이터베이스에 쓰는 효율성이 떨어진다.

버전 MySQL 5.7에는 rpl_semi_sync_master_wait_for_slave_count 매개변수도 추가되었습니다. 응답해야 하는 슬레이브 라이브러리 수를 설정할 수 있습니다. 기본값은 1입니다. 즉, 하나의 슬레이브 라이브러리가 응답하는 한 해당 라이브러리로 반환될 수 있습니다. 고객. 이 매개변수를 늘리면 데이터 일관성의 강도를 향상시킬 수 있지만 마스터 데이터베이스가 슬레이브 데이터베이스의 응답을 기다리는 시간도 늘어납니다.

그러나 반동기 복제에도 다음과 같은 문제가 있습니다.

• 비동기 복제에 비해 반동기 복제의 성능이 저하되었으며, 비동기 복제에 비해 슬레이브 라이브러리가 작동할 때까지 기다릴 필요가 없습니다. receive 데이터에 응답하려면 반동기 복제는 최소한 하나의 슬레이브 데이터베이스가 binlog 로그 수신 응답을 확인할 때까지 기다려야 하는데, 이는 성능 측면에서 더 비용이 많이 듭니다.
• 마스터 라이브러리가 슬레이브 라이브러리의 응답을 기다리는 최대 시간은 구성 가능합니다. 구성된 시간을 초과하면 반동기 복제가 비동기 복제가 되며 비동기 복제 문제도 발생합니다.
• MySQL 5.7.2 이전 버전에서는 반동기 복제에 팬텀 읽기 문제가 있었습니다.

메인 라이브러리가 트랜잭션을 성공적으로 제출하고 슬레이브 라이브러리의 확인을 기다리는 중일 때, 이때 슬레이브 라이브러리는 처리 결과를 클라이언트에게 반환할 시간이 없었지만 메인 라이브러리가 스토리지 엔진이 이미 트랜잭션을 제출했습니다. 다른 클라이언트 클라이언트는 기본 라이브러리에서 데이터를 읽을 수 있습니다.

그런데 메인 라이브러리가 다음 1초에 갑자기 끊기는데 이때 다음 요청이 들어오면 메인 라이브러리가 끊기 때문에 슬레이브 라이브러리가 응답하지 않기 때문에 요청을 슬레이브 라이브러리로만 전환할 수 있습니다. 아직 메인 라이브러리의 데이터 동기화가 완료되지 않았으므로 당연히 이 데이터를 라이브러리에서 읽을 수 없습니다. 이전 초에 데이터를 읽은 결과와 비교하면 팬텀 읽기 현상이 발생합니다.

5.4 향상된 반 동기 복제

향상된 반 동기 복제는 mysql 5.7.2 이후 버전의 반 동기 복제를 개선한 것입니다. 원칙은 거의 동일하며 주로 팬텀 읽기 문제를 해결합니다.

마스터 라이브러리가 rpl_semi_sync_master_wait_point = AFTER_SYNC 매개변수로 구성된 후, 스토리지 엔진이 트랜잭션을 커밋하기 전에 마스터 라이브러리는 트랜잭션을 제출하기 전에 슬레이브 라이브러리로부터 데이터 동기화가 완료되었다는 확인을 받아야 하므로 팬텀 읽기 문제가 해결됩니다. . 아래 그림을 참조하세요.

6 요약

위 내용을 통해 MySQL 데이터베이스의 마스터-슬레이브 동기화를 이해했습니다. 목표가 데이터베이스의 높은 동시성뿐이라면 SQL 최적화부터 시작할 수 있습니다. , 인덱싱 및 Redis 데이터 캐싱 등의 측면에서 최적화를 고려한 후 마스터-슬레이브 아키텍처 채택 여부를 고려합니다.

마스터-슬레이브 아키텍처 구성에서 읽기-쓰기 분리 전략을 채택하려면 자체 프로그램을 작성하거나 타사 미들웨어를 통해 구현할 수 있습니다.

자신만의 프로그램을 작성하면 더 독립적이라는 장점이 있습니다. 슬레이브 데이터베이스에서 실행할 쿼리를 판단할 수 있으며 실시간 요구 사항이 높은 경우 기본 데이터베이스에서 실행할 수 있는 쿼리도 고려할 수 있습니다. 동시에 프로그램은 데이터베이스에 직접 연결되어 미들웨어 계층을 줄이고 일부 성능 손실을 줄입니다.

미들웨어를 사용하는 방법은 분명한 장점이 있으며 강력하고 사용하기 쉽습니다. 그러나 클라이언트와 데이터베이스 사이에 미들웨어 계층을 추가하면 성능이 다소 저하될 수 있습니다. 동시에 상용 미들웨어의 가격이 상대적으로 높고 학습 비용도 어느 정도 있습니다. 또한 MaxScale과 같은 몇 가지 뛰어난 오픈 소스 도구를 사용하는 것도 고려할 수 있습니다. MariaDB에서 개발한 MySQL 데이터 미들웨어입니다. 예를 들어, 아래 그림에서는 MaxScale을 데이터베이스 프록시로 사용하고, 라우팅과 포워딩을 통해 읽기-쓰기 분리가 완성됩니다. 동시에 MHA 도구를 강력하고 일관된 마스터-슬레이브 전환 도구로 사용하여 MySQL의 고가용성 아키텍처를 완성할 수도 있습니다.

추천 학습: "MySQL 비디오 튜토리얼"

위 내용은 하나의 기사로 MySql 마스터-슬레이브 동기화에 대한 철저한 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!