MySQL 마스터-슬레이브 지연에 대한 솔루션을 완전히 마스터하세요.

이 기사에서는 마스터-슬레이브 지연이 무엇인지, 마스터-슬레이브 지연의 소스 및 마스터-슬레이브 지연 솔루션을 포함하여 마스터-슬레이브 지연 솔루션과 관련된 문제를 주로 정리하는 mysql에 대한 관련 지식을 제공합니다. 아래 내용을 살펴보시고 모든 분들께 도움이 되었으면 좋겠습니다.

추천 학습: mysql 동영상 튜토리얼

이전 프로젝트에서는 MySQL 마스터-슬레이브 복제 및 AOP를 기반으로 읽기-쓰기 분리를 구현했으며, 이 구현 과정을 기록하기 위해 블로그에도 작성했습니다. MySQL 마스터-슬레이브 복제가 구성되어 있기 때문에 자연스럽게 마스터-슬레이브 지연이 발생하게 되는데, 마스터-슬레이브 지연이 애플리케이션 시스템에 미치는 영향을 최소화하는 방법은 개인적으로 마스터-슬레이브 지연에 대한 솔루션이 필요하다고 생각합니다. MySQL 마스터-슬레이브 복제의 핵심인 읽기 쓰기 분리를 구현합니다.

이 주제에 관해서는 사실 예전부터 블로그에 글을 써서 공유할까 생각도 해봤는데 한번도 안건에 올리지 못했습니다. 최근 "SpringBoot에서 MySQL 읽기-쓰기 분리를 구현합니다"에서 한 독자가 이 질문을 묻는 메시지를 남겼고, 이는 나에게도 이 글을 쓰게 된 계기가 되었습니다. 이 문제에 관해서 저는 많은 정보와 블로그를 읽었고, 저만의 실천을 통해 사장님의 어깨 위에 서서 이 블로그를 정리했습니다.

마스터-슬레이브 지연이란 무엇입니까

마스터-슬레이브 지연을 해결하는 방법을 논의하기 전에 먼저 마스터-슬레이브 지연이 무엇인지 이해하겠습니다.

마스터-슬레이브 복제를 완료하려면 슬레이브 라이브러리는 I/O 스레드를 통해 마스터 라이브러리의 덤프 스레드가 읽은 binlog 콘텐츠를 가져와 자체 릴레이 로그에 기록한 다음 SQL 스레드를 작성해야 합니다. 슬레이브 라이브러리는 릴레이 로그를 읽고, 릴레이 로그에서 로그를 다시 실행하는 것은 SQL을 다시 실행하고 자신의 데이터베이스를 업데이트하여 데이터 일관성을 달성하는 것과 같습니다.

데이터 동기화와 관련된 시점은 주로 다음 세 가지를 포함합니다.

1. 메인 라이브러리는 트랜잭션 실행을 마치고 이를 binlog에 기록하고 이 순간을 T1으로 기록합니다.
2. 이후 슬레이브 라이브러리로 전달됩니다. , 슬레이브 라이브러리는 이를 수신합니다. binlog의 시간은 T2로 기록됩니다.
3. 슬레이브 라이브러리는 이 트랜잭션을 실행하고 이 시간을 T3으로 기록합니다.

소위 마스터-슬레이브 지연은 동일한 트랜잭션에 대해 슬레이브 라이브러리의 실행이 완료되는 시간과 메인 라이브러리의 실행이 완료되는 시간의 차이를 말하는데, 바로 T3 - T1. T3 - T1。

可以在备库上执行 show slave status 命令，它的返回结果里面会显示 seconds_behind_master，用于表示当前备库延迟了多少秒。
seconds_behind_master 的计算方法是这样的：

1. 每个事务的 binlog 里面都有一个时间字段，用于记录主库上写入的时间；
2. 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到 seconds_behind_master。

在网络正常的时候，日志从主库传给从库所需的时间是很短的，即 T2 - T1 的值是非常小的。也就是说，网络正常情况下，主从延迟的主要来源是从库接收完 binlog 和执行完这个事务之间的时间差。

由于主从延迟的存在，我们可能会发现，数据刚写入主库，结果却查不到，因为可能还未同步到从库。主从延迟越严重，该问题也愈加明显。

主从延迟的来源

主库和从库在执行同一个事务的时候出现时间差的问题，主要原因包括但不限于以下几种情况：

• 有些部署条件下，从库所在机器的性能要比主库性能差。
• 从库的压力较大，即从库承受了大量的请求。
• 执行大事务。因为主库上必须等事务执行完成才会写入 binlog，再传给备库。如果一个主库上语句执行 10 分钟，那么这个事务可能会导致从库延迟 10 分钟。
• 从库的并行复制能力。

主从延迟的解决方案

解决主从延迟主要有以下方案：

1. 配合 semi-sync 半同步复制；
2. 一主多从，分摊从库压力；
3. 强制走主库方案（强一致性）；
4. sleep 方案：主库更新后，读从库之前先 sleep 一下；
5. 判断主备无延迟方案（例如判断 seconds_behind_master
대기 데이터베이스에서 showslave status 명령을 실행할 수 있으며, 그 반환 결과는 현재 대기 데이터베이스가 몇 초인지 나타내는 데 사용되는 seconds_behind_master를 표시합니다. 지연.
seconds_behind_master는 다음과 같이 계산됩니다.
6. 각 트랜잭션의 binlog에는 시간 필드가 있으며, 이는 기본 데이터베이스에 기록된 시간을 기록하는 데 사용됩니다. 대기 데이터베이스 현재 실행 중인 트랜잭션의 시간 필드 값을 계산하고, 현재 시스템 시간과의 차이를 계산하여 seconds_behind_master를 구합니다.

네트워크가 정상일 때는 마스터 데이터베이스에서 슬레이브 데이터베이스로 로그를 전송하는 데 필요한 시간이 매우 짧습니다. 즉, T2 - T1 값이 매우 작습니다. 즉, 정상적인 네트워크 조건에서 마스터-슬레이브 지연의 주요 원인은 binlog를 수신하는 슬레이브 라이브러리와 트랜잭션을 실행하는 사이의 시간 차이입니다. 마스터-슬레이브 지연의 존재로 인해 데이터가 방금 마스터 데이터베이스에 기록되었지만 아직 슬레이브 데이터베이스에 동기화되지 않았기 때문에 결과를 찾을 수 없다는 것을 알 수 있습니다. 마스터-슬레이브 지연이 심각할수록 이 문제는 더욱 분명해집니다.

마스터-슬레이브 지연의 원인동일한 트랜잭션을 실행할 때 마스터 라이브러리와 슬레이브 라이브러리 사이에 시간 차이 문제가 있습니다. 주된 이유는 다음과 같은 상황을 포함하지만 이에 국한되지는 않습니다.

Under 일부 배포 조건,

슬레이브 라이브러리 머신의 성능이 기본 데이터베이스의 성능보다 나쁩니다🎜. 🎜🎜🎜슬레이브 데이터베이스에 더 큰 압박이 가해지고 있습니다🎜. 즉, 슬레이브 데이터베이스에 많은 요청이 가해집니다. 🎜🎜🎜큰일을 실행하세요🎜. 기본 데이터베이스는 트랜잭션 실행이 완료될 때까지 기다렸다가 binlog에 기록한 다음 대기 데이터베이스로 전달해야 하기 때문입니다. 마스터 데이터베이스에서 명령문을 실행하는 데 10분이 걸리는 경우 이 트랜잭션으로 인해 슬레이브 데이터베이스에서 10분 지연이 발생할 수 있습니다. 🎜🎜🎜라이브러리의 병렬 복사 기능🎜. 🎜

🎜마스터-슬레이브 지연에 대한 솔루션🎜🎜마스터-슬레이브 지연을 해결하려면 주로 다음 솔루션이 있습니다. 🎜🎜🎜🎜반동기식 반동기 복제🎜와 협력 여러 슬레이브🎜를 사용하여 슬레이브 데이터베이스에 대한 압력을 공유합니다. 🎜🎜🎜마스터 라이브러리 솔루션 강제 적용🎜(강한 일관성) 🎜🎜슬립 솔루션: 마스터 라이브러리가 업데이트된 후 슬레이브 라이브러리에서 읽기 전에 슬립합니다. 마스터-슬레이브 비지연 솔루션(예: 판단 seconds_behind_master code> 매개변수가 이미 0, 비교점임) 🎜🎜🎜병렬 복제🎜 - 라이브러리에서 복사 지연 문제를 해결합니다. 🎜여기에서는 제가 프로젝트에서 사용하는 몇 가지 솔루션, 즉 🎜반동기 복제, 실시간 작업으로 인해 메인 라이브러리를 강제로 사용, 병렬 복제🎜를 주로 소개합니다. 🎜🎜🎜반동기 반동기 복제🎜🎜🎜MySQL에는 세 가지 동기화 모드가 있습니다. 즉: 🎜<p><strong>"비동기 복제"</strong>: MySQL의 기본 복제는 비동기식입니다. 메인 라이브러리는 클라이언트가 제출한 트랜잭션을 실행한 후 즉시 결과를 클라이언트에 반환하며 슬레이브 라이브러리가 이를 수신하고 처리했는지 여부는 신경 쓰지 않습니다. 이로 인해 메인 데이터베이스가 다운되면 네트워크상의 이유로 인해 메인 데이터베이스에 제출된 트랜잭션이 슬레이브 데이터베이스로 전송되지 않을 수 있습니다. 마스터에 연결하면 새 마스터의 데이터가 불완전해질 수 있습니다. </p> <p><strong>"완전 동기식 복제"</strong>: 메인 라이브러리가 트랜잭션을 완료하고 모든 슬레이브 라이브러리가 트랜잭션을 실행하면 메인 라이브러리가 트랜잭션을 제출하고 결과를 클라이언트에 반환한다는 의미입니다. 반환하기 전에 모든 슬레이브 라이브러리가 트랜잭션을 완료할 때까지 기다려야 하기 때문에 완전 동기 복제 성능은 필연적으로 심각한 영향을 받습니다. </p> <p><strong>"반동기 복제"</strong>: 완전 동기 복제와 완전 비동기 복제 사이의 유형입니다. 메인 라이브러리는 릴레이 로그 파일을 수신하고 쓰기 위해 적어도 하나의 슬레이브 라이브러리만 기다리면 됩니다. 모든 슬레이브 라이브러리가 마스터 라이브러리에 ACK를 반환할 때까지 기다릴 필요가 없습니다. 기본 라이브러리는 이 ACK를 받은 후에만 "트랜잭션 완료" 확인을 클라이언트에 반환할 수 있습니다. </p> <p><strong>MySQL의 기본 복제는 비동기식이므로 마스터 데이터베이스와 슬레이브 데이터베이스 사이의 데이터에 일정한 지연이 발생합니다. 더 중요한 것은 비동기식 복제로 인해 데이터 손실이 발생할 수 있다는 것입니다</strong>. 그러나 완전 동기식 복제는 트랜잭션을 완료하는 데 걸리는 시간을 늘리고 성능을 저하시킵니다. 그래서 저는 반동기 복제에 관심을 돌렸습니다. <strong>MySQL 5.5부터 MySQL은 플러그인 형태의 반동기화 복제를 지원합니다</strong>. </p> <p>비동기 복제와 비교하여 반동기 복제는 데이터 보안을 향상시키고 마스터-슬레이브 지연을 줄입니다. 물론 이 지연은 적어도 하나의 TCP/IP 왕복 시간입니다. 따라서 <strong>반동기 복제는 지연 시간이 짧은 네트워크</strong>에 가장 적합합니다. </p> <blockquote> <p>반동기 복제를 수행하려면 마스터 라이브러리와 슬레이브 라이브러리 모두 반동기 복제를 활성화해야 합니다. 그렇지 않으면 마스터 라이브러리가 기본 비동기 복제로 되돌아갑니다. </p> <ul>대기 프로세스 중에 대기 시간이 구성된 제한 시간을 초과하고 슬레이브 라이브러리로부터 ACK가 수신되지 않으면 이때 기본 라이브러리가 자동으로 비동기 복제로 변환됩니다. 하나 이상의 반동기 슬레이브 노드가 따라잡으면 마스터 데이터베이스가 자동으로 반동기 복제로 변환됩니다. <li> <li>반동기 복제의 잠재적인 문제</ul> </blockquote>기존 반동기 복제(MySQL 5.5에서 도입됨)에서 마스터 데이터베이스는 데이터를 binlog에 기록하고 커밋을 실행하여 트랜잭션을 커밋한 후 항상 ACK를 기다립니다. 슬레이브 데이터베이스, 즉 슬레이브 데이터베이스에서 라이브러리가 릴레이 로그를 작성한 후 데이터를 디스크에 쓴 다음 메인 라이브러리에 ACK를 반환한 후에만 메인 라이브러리가 이 ACK를 받은 후에 "트랜잭션 완료"를 반환할 수 있습니다. 클라이언트에게 확인. <h4></h4> <p></p> <p>문제가 발생합니다. 즉, 메인 라이브러리가 실제로 트랜잭션을 스토리지 엔진 계층에 커밋했고 애플리케이션은 이미 데이터가 변경되었음을 확인할 수 있으며 반환을 기다리고 있습니다. <img src="https://img.php.cn/upload/article/000/000/067/cbef40562254d59aabda3ee32efe155e-0.jpg" alt="MySQL 마스터-슬레이브 지연에 대한 솔루션을 완전히 마스터하세요.">이 시점에서 메인 데이터베이스가 다운된 경우</p> 슬레이브 데이터베이스가 릴레이 로그를 작성하지 않았을 수 있으며, <p>마스터 데이터베이스와 슬레이브 데이터베이스 간의 데이터 불일치<strong>가 발생합니다. </strong><strong>위 문제를 해결하기 위해 </strong>MySQL 5.7에서는 향상된 반동기 복제</p>를 도입했습니다. 위 그림의 경우 "Waiting Slave dump"는 "Storage Commit" 이전으로 조정됩니다. 즉, 마스터 라이브러리가 binlog에 데이터를 쓴 후 적어도 하나의 슬레이브 라이브러리가 나올 때까지 슬레이브 라이브러리의 응답 ACK를 기다리기 시작합니다. Relay Log에 기록하고, 데이터를 디스크에 기록하고, ACK가 메인 라이브러리로 반환되어 커밋 작업이 수행될 수 있음을 메인 라이브러리에 알리고, 메인 라이브러리가 해당 트랜잭션을 트랜잭션 엔진에 제출합니다. 그래야만 애플리케이션에서 데이터 변경 사항을 볼 수 있습니다. <p><strong></strong><strong></strong></p> 물론 이전 반동기화 솔루션도 지원됩니다. MySQL 5.7.2에는 제어를 위한 새로운 매개변수 <p>가 도입되었습니다. 이 매개변수에는 두 가지 값이 있습니다. <img src="https://img.php.cn/upload/article/000/000/067/cbef40562254d59aabda3ee32efe155e-1.png" alt="MySQL 마스터-슬레이브 지연에 대한 솔루션을 완전히 마스터하세요."></p> <blockquote>AFTER_SYNC: 이는 새로운 반동기화 방식으로, 스토리지 커밋 전에 슬레이브 덤프를 대기하는 것입니다. <p><code>rpl_semi_sync_master_wait_pointAFTER_COMMIT: 이것은 오래된 반동기식 솔루션입니다.

1. after_commit 모드를 사용하는 MySQL 5.5 - 5.6에서는 클라이언트 트랜잭션이 스토리지 엔진 계층에 제출된 후 메인 라이브러리가 슬레이브 라이브러리의 확인을 기다리는 동안 메인 라이브러리가 다운됩니다. 이때 현재 클라이언트에게 결과가 반환되지는 않지만 트랜잭션이 제출된 것이며 다른 클라이언트가 제출된 트랜잭션을 읽게 됩니다. 슬레이브 데이터베이스가 트랜잭션을 수신하지 못하거나 릴레이 로그에 기록하지 않고 마스터 데이터베이스가 다운된 후 스탠바이 데이터베이스로 전환되면 이전에 읽은 트랜잭션은 사라지고 팬텀 읽기(phantom read)가 발생하게 된다. 데이터가 손실됩니다.

2. MySQL 5.7의 기본값은 after_sync입니다. 마스터 데이터베이스는 각 트랜잭션을 binlog에 기록하고 이를 슬레이브 데이터베이스에 전달한 후 디스크(릴레이 로그)에 플러시합니다. 메인 라이브러리는 슬레이브 라이브러리가 ack를 반환할 때까지 기다린 다음 트랜잭션을 커밋하고 커밋 OK 결과를 클라이언트에 반환합니다. 메인 라이브러리가 충돌하더라도 메인 라이브러리에 제출된 모든 트랜잭션은 슬레이브 라이브러리의 릴레이 로그와 동기화되도록 보장할 수 있으며, 이는 after_commit 모드로 인한 팬텀 읽기 및 데이터 손실 문제를 해결합니다. 장애 조치 중에 일관성이 향상됩니다. 개선 . 왜냐하면 슬레이브 데이터베이스가 성공적으로 쓰지 못하면 마스터 데이터베이스가 트랜잭션을 커밋하지 않기 때문입니다. 또한 커밋하기 전에 슬레이브 라이브러리에서 ACK를 기다리면 트랜잭션이 누적될 수 있으며 이는 그룹 커밋 그룹 제출에 유리하고 성능을 향상시킵니다.

   하지만 여기에는 문제가 있습니다. 스토리지 엔진이 커밋되기 전에 메인 라이브러리가 중단된다고 가정하면 트랜잭션이 실패한 것이 분명합니다. 그러나 해당 Binlog가 이미 Sync 작업을 수행했기 때문에 슬레이브는 라이브러리가 이러한 Binlog를 수신했으며 실행이 성공하면 슬레이브 데이터베이스에 추가 데이터가 있는 것과 동일합니다(슬레이브 데이터베이스에는 이 데이터가 있지만 기본 데이터베이스에는 없음). 이것도 문제이지만 추가 데이터는 일반적으로 심각한 문제는 아닙니다. 보장할 수 있는 것은 데이터가 손실되지 않는다는 것입니다. 데이터를 잃는 것보다 더 많은 데이터를 갖는 것이 좋습니다.

   하나의 마스터, 다중 슬레이브
   슬레이브 데이터베이스가 많은 수의 쿼리 요청을 수행하는 경우 슬레이브 데이터베이스의 쿼리 작업은 많은 CPU 리소스를 소비하므로 동기화 속도에 영향을 미치고 마스터-슬레이브 지연이 발생합니다. 그런 다음 여러 개의 슬레이브 라이브러리를 더 연결하고 이러한 슬레이브 라이브러리가 읽기 압력을 공유하도록 할 수 있습니다.
   간단히 말하면 기계를 추가하는 것입니다. 방법은 간단하고 투박하지만 비용도 발생합니다.

   기본 데이터베이스 솔루션 강제

   금전과 관련된 금융 시스템, 온라인 실시간 시스템, 작성 후 등 일부 작업에서 데이터에 대한 엄격한 실시간 요구 사항이 있어 최신 실시간 데이터를 반영해야 하는 경우 비즈니스를 즉시 다시 읽어야 하는 경우 읽기와 쓰기의 분리를 포기해야 하며 이러한 읽기 요청도 메인 라이브러리로 이동해야 하므로 지연 문제가 없습니다.
   물론, 읽기와 쓰기의 분리로 인해 얻을 수 있는 성능 향상도 손실되므로 적절한 절충이 필요합니다.

   병렬 복제

   일반적으로 MySQL 마스터-슬레이브 복제에는 Binlog Dump 스레드, IO 스레드 및 SQL 스레드의 세 가지 스레드가 포함되며 모두 단일 스레드입니다. 복제 지연은 일반적으로 두 가지 위치에서 발생합니다.
   SQL 스레드가 너무 바빠서(주요 이유)
   • 네트워크 지터로 인해 IO 스레드 복제 지연이 발생합니다(2차 이유).
   대기 데이터베이스의 로그 실행은 데이터를 업데이트하기 위해 릴레이 로그를 실행하는 대기 데이터베이스의 SQL 스레드 논리입니다.
   MySQL 버전 5.6 이전에는 MySQL이 단일 스레드 복제만 지원했기 때문에 기본 데이터베이스 동시성과 TPS가 높을 때 심각한 마스터-슬레이브 지연 문제가 발생했습니다.

   MySQL 5.6부터 데이터를 동시에 복원할 수 있는 다중 SQL 스레드 개념, 즉 병렬 복제 기술이 등장합니다. 이는 MySQL 마스터-슬레이브 지연 문제를 매우 잘 해결할 수 있습니다.

   단일 스레드 복제부터 최신 버전의 멀티 스레드 복제까지 여러 버전을 거쳐 진화했습니다. 실제로 최종 분석에서 모든 멀티 스레드 복제 메커니즘은 하나의 스레드만 있는 sql_thread를 여러 스레드로 분할하는 것입니다. 이는 모두 다음과 같은 멀티 스레드 모델을 준수함을 의미합니다.

   coordinator는 원래 sql_thread이지만, 이제는 더 이상 데이터를 직접 업데이트하지 않고 전송 로그를 읽고 트랜잭션을 배포하는 역할만 담당합니다. 실제로 로그를 업데이트하는 것이 작업자 스레드가 됩니다. 작업자 스레드 수는 매개변수 에 의해 결정됩니다. slave_parallel_workers

   작업자 스레드가 동시에 실행되므로 트랜잭션 격리를 보장하고 업데이트 적용 범위 문제를 방지하기 위해 코디네이터는 배포 시 다음 두 가지 기본 요구 사항을 충족해야 합니다.
   1. 동일한 행에서 두 트랜잭션을 업데이트하고 배포해야 합니다. 동일한 작업자에게(업데이트 적용을 피하기 위해) .
   2. 동일한 트랜잭션은 분할될 수 없으며 동일한 워커에 배치되어야 합니다(트랜잭션 격리를 보장하기 위해).
   모든 다중 스레드 복제 버전은 다음 두 가지 기본 원칙을 따릅니다.
   다음은 병렬 복제 전략의 MySQL 공식 버전 반복을 이해하는 데 도움이 될 수 있는 테이블별 배포 전략과 행별 배포 전략입니다.
   • 테이블 전략에 따른 배포: 서로 다른 테이블을 업데이트하면 두 트랜잭션이 병렬로 실행될 수 있습니다. 데이터가 테이블에 저장되기 때문에 테이블별 배포를 통해 두 작업자가 동일한 행을 업데이트하지 않도록 할 수 있습니다.
     • 테이블 기반 배포 방식은 여러 테이블에 균등한 로드가 있는 시나리오에서 잘 작동하지만 단점은 핫 테이블이 발생하는 경우(예: 모든 업데이트 트랜잭션이 특정 테이블과 관련된 경우) 모든 트랜잭션이 동일한 작업자이면 단일 스레드 복제가 됩니다.
   • 행별 분산 전략: 두 트랜잭션이 동일한 행을 업데이트하지 않는 경우 대기 데이터베이스에서 병렬화될 수 있습니다. 분명히 이 모드에서는 binlog 형식이 행이어야 합니다.
     • 행별 병렬 복제 솔루션은 핫스팟 테이블의 문제를 해결하고 더 높은 수준의 병렬화를 제공합니다. 그러나 단점은 테이블별 병렬 분산 전략에 비해 행별 병렬 복제입니다. 전략에서는 스레드 배포를 결정할 때 더 많은 계산이 필요합니다.

   MySQL 5.6 버전의 병렬 복제 전략

   MySQL 5.6 버전은 병렬 복제를 지원하지만 지원되는 세분성은 베이스별 병렬 처리(스키마 기반)입니다.

   핵심 아이디어는 : 서로 다른 스키마의 테이블이 동시에 제출되면 데이터가 서로 영향을 미치지 않습니다. 즉, 슬레이브 라이브러리는 SQL 스레드 기능과 유사한 스레드를 릴레이 로그의 다른 스키마에 할당할 수 있습니다. 릴레이 로그를 재생합니다. 기본 데이터베이스에서 커밋된 트랜잭션은 기본 데이터베이스의 데이터와 일관성을 유지합니다.

   메인 데이터베이스에 여러 개의 DB가 있는 경우 이 전략을 사용하면 슬레이브 데이터베이스에서 복제 속도를 크게 향상시킬 수 있습니다. 그러나 일반적으로 단일 데이터베이스에 여러 테이블이 있기 때문에 데이터베이스 기반 동시성은 효과가 없으며 병렬 재생도 전혀 수행할 수 없으므로 이 전략은 많이 사용되지 않습니다.

   MySQL 5.7의 병렬 복제 전략

   MySQL 5.7은 그룹 제출 기반 병렬 복제를 도입했으며, 매개변수 slave_parallel_workers 设置并行线程数，由参数 slave-parallel-type는 병렬 복제 전략을 제어하는 ​​데 사용됩니다.

   • 은 DATABASE로 구성됩니다. -MySQL 5.6 버전의 데이터베이스 병렬 전략
   LOGICAL_CLOCK으로 구성되어 그룹 제출을 기반으로 하는 병렬 복제 전략 사용을 나타냅니다.
   binlog의 그룹 커밋 메커니즘을 사용하면 그룹이 제출한 트랜잭션이 가능하다는 결론을 내릴 수 있습니다.

   병렬로 실행될 수 있습니다. 트랜잭션이 잠금 충돌 테스트를 통과했기 때문에 동일한 그룹에 제출된 트랜잭션은 동일한 행을 수정하지 않습니다(MySQL의 잠금 메커니즘으로 인해).

   그룹 제출을 기반으로 한 병렬 복제의 구체적인 프로세스는 다음과 같습니다:

   그룹에 함께 제출된 트랜잭션은 동일한 commit_id를 가지며 다음 그룹은 commit_id+1입니다. binlog에 직접 기록됩니다.
   1. 전송 대기 데이터베이스 애플리케이션에 도달하면 동일한 commit_id를 가진 트랜잭션이 실행을 위해 여러 작업자에게 배포됩니다.
   2. 이 그룹의 모든 실행이 완료된 후 코디네이터는 일괄 실행을 중단합니다.
   준비 및 커밋 상태의 모든 트랜잭션은 대기 데이터베이스에서 병렬로 실행될 수 있습니다

   . binlog 그룹이 제출한 두 가지 관련 매개변수:

   binlog_group_commit_sync_delay 매개변수는 fsync를 호출하여 디스크를 플러시하기 전에 지연해야 하는 마이크로초 수를 나타냅니다.
   • binlog_group_commit_sync_no_delay_count 매개변수는 fsync를 호출하기 전에 누적된 횟수를 나타냅니다.
   • 이 두 매개 변수는 binlog 쓰기에서 fsync까지의 시간을 의도적으로 늘려서 디스크에 binlog 쓰기 횟수를 줄이는 데 사용됩니다. MySQL 5.7의 병렬 복제 전략에서는 "준비 단계에서 동시에 더 많은 트랜잭션"을 생성하는 데 사용할 수 있습니다. 대기 데이터베이스 복제의 동시성을 향상시키려는 목적을 달성하려면 이 두 매개변수의 값을 조정하는 것을 고려할 수 있습니다.

   추천 학습:

   mysql 비디오 튜토리얼

위 내용은 MySQL 마스터-슬레이브 지연에 대한 솔루션을 완전히 마스터하세요.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!