MySQL主从复制

MySQL主从同步的三种模式

   概要

   随着业务的增长，一台数据服务器已经满足不了需求了，负载过重。这个时候就需要减压了，实现负载均衡读写分离，一主一丛或一主多从。

   主服务器只负责写，而从服务器只负责读，从而提高了效率减轻压力。

   一、相关概念

   1.  master--主数据库

   2. slave--从数据库

   3. binlog--二进制日志文件

   4.  relaylog--中继日志

   中继日志存在于 slave(从数据库) 中，它是从 master(主数据库) 的二进制日志复制过来的，并不是自己的数据库变化产生的，有点接力的感觉，称为中继日志，即relay log。

   5. ack--确认应答（确认消息、确认机制）

   mysql主从同步分为三种模式：异步复制、半同步复制、全同步复制。下面来分别介绍下。 

   一、异步复制

   异步复制是 mysql 默认的同步方式，在 master 为 slave 开通账号密码、ip授权之后，slave 可以从 master 进行数据同步，主要依赖的是 master 的 binlog 日志。

   如下图：

   master 会生成一个 log dump 线程，用来给slave的 I/O 线程传 binlog。

   slave 会启动两个线程，IO Thread 和 SQL Thread：

   1）IO Thread 负责从 master 拉取 binlog 日志，并写入 relay 中继日志

   2）SQL Thread 负责将 relay 中继日志中的变更进行重放，更新数据来达到跟 master 保持数据一致的目的

   这个过程中，slave 通过IO线程拉取 binlog ，master 无需关注是否有 slave 需要同步，只做自己的事情，整个复制过程都是异步完成的，这个就是异步复制。

   异步复制的优势是性能好，缺点是数据的安全性比较差。

   在某一刻主从之间的数据差异可能较大，主机挂掉之后从机接管，可能会丢失一部分数据。

   三、半同步复制

   半同步复制在异步复制的基础上，确保任何一个主库上的事务在提交之前至少有一个从库已经收到该事务并将日志记录下来。

   如下图：

 

   master 更新操作写入 binlog 之后会主动通知 slave，slave 接收到之后写入 relay log 即可应答，master 只要收到至少一个ack应答，则会提交事务。

   可以发现，相比较于异步复制 ，半同步复制需要依赖至少一个 slave 将 binlog 写入 relay log 才行，在性能上有所降低，但是可以保证至少有一个 slave(从数据库)跟 master(主数据库) 的数据是一致的，数据的安全性提高。

   对于数据一致性要求高的场景，可以采用半同步复制的同步策略，比如主库挂掉时，准备接管的那一个从库，对数据的一致性要求比较高。

   半同步复制的优点是数据的安全性好，缺点是性能比异步复制稍低。

   四、全同步复制

   全同步复制跟半同步复制的区别是，全同步复制必须收到所有 slave的 ack，才会提交事务。

   master(主数据库) 的事务提交依赖于后面所有的 slave(从数据库)，这样一来性能就会明显得下降，除非是对所有 slave(从数据库) 数据一致性要求非常高的场景，否则我们一般不采用这种策略。

   全同步复制的数据一致性最好，但是性能也是最差的。

 

   参考链接： 

   https://cloud.tencent.com/developer/article/2354879