MYSQL主从复制

MySQL 主从复制是基于二进制日志更改操作的。因此，要进行复制，必须在主服务器上启用二进制日志。

每个从服务器从主服务器接收已经记录到日志的数据。当一个从服务器连接到主服务器时，它通知主服务器从服务器日志中读取最后一个更新成功的位置。

从服务器接收从那时发生起的任何更新，并在主机上执行相同的更新。然后封锁等待主服务器通知的更新。

从服务器执行备份不会干扰主服务器，在备份过程中主服务器可以继续处理更新。

数据更安全：做了数据冗余，防止数据意外丢失，使得用户蒙受损失。一台机器宕机了，可以启用备份在另一台机器的数据。

性能大大提升：一主多从，不同用户从不同数据库读取，性能提升；让备份机器分担主机器的流量压力。

扩展性更优：流量增大时，可以方便的增加从服务器，不影响系统使用；升级数据库版本时，可以在不停止用户服务的情况下优先升级备用机器，待观测其可用稳定时再将主数据库升级。

负载均衡：一主多从相当于分担了主机任务，做了负载均衡。

可以进行数据库层面的读写分离；可以在从数据库上进行日常备份。

MySQL 主从复制集群功能使得 MySQL 数据库支持大规模高并发读写成为可能，同时有效地保护了物理服务器宕机场景的数据备份。

横向扩展

将工作负载分发到各 Slave 节点上，从而提高系统性能。

在这个场景下，所有的写(write)和更新(update)操作都在 Master 节点上完成；所有的读( read)操作都在 Slave 节点上完成。通过增加更多的 Slave 节点，便能提高系统的读取速度。

数据安全

数据从 Master 节点复制到 Slave 节点上，在 Slave 节点上可以暂停复制进程。可以在 Slave 节点上备份与 Master 节点对应的数据，而不用影响 Master 节点的运行。

数据分析

实时数据可以在 Master 节点上创建，而分析这些数据可以在 Slave 节点上进行，并且不会对 Master 节点的性能产生影响。

远距离数据分布

可以利用复制在远程主机上创建一份本地数据的副本，而不用持久的与Master节点连接。

拆分访问

可以把几个不同的从服务器，根据公司的业务进行拆分。通过拆分可以帮助减轻主服务器的压力，还可以使数据库对外部用户浏览、内部用户业务处理及 DBA 人员的备份等互不影响。

同步复制：当用户写如数据时，主服务器必须和从服务器同步后，才告诉用户写入成功，等待时间比较长。

异步复制：只要用户访问写数据到主服务器，立即返回给用户。

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

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到 relay log 中才返回成功信息给客户端(只能保证主库的 Binlog 至少传输到了一个从节点上)，否则需要等待直到超时时间然后切换成异步模式再提交。

相对于异步复制，半同步复制提高了数据的安全性，一定程度的保证了数据能成功备份到从库，同时它也造成了一定程度的延迟，但是比全同步模式延迟要低，这个延迟最少是一个 TCP/IP 往返的时间。所以，半同步复制最好在低延时的网络中使用。

半同步模式不是 MySQL 内置的，从 MySQL 5.5 开始集成，需要 master 和 slave 安装插件开启半同步模式。

一主一从和一主多从是我们现在见的最多的主从架构，使用起来简单有效，不仅可以实现高可用，而且还能读写分离，进而提升集群的并发能力。多主一从可以将多个 MySQL 数据库备份到一台存储性能比较好的服务器上。

双主复制，也就是可以互做主从复制，实现双机热备，每个 master 既是 master，又是另外一台服务器的 salve。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。

级联复制模式下，部分 slave 的数据同步不连接主节点，而是连接从节点。因为如果主节点有太多的从节点，就会损耗一部分性能用于 replication ，那么我们可以让 3~5 个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。

MySQL 根据两种不同的日志格式，对应了两种复制方式。

语句复制

基于语句的复制相当于逻辑复制，即二进制日志中记录了操作的语句，通过这些语句在从数据库中重放来实现复制。

这种方式简单，二进制文件小，传输带宽占用小。但是基于语句更新依赖于其它因素，比如插入数据时利用了时间戳。

因此在开发当中，我们应该尽量将业务逻辑逻辑放在代码层，而不应该放在 MySQL 中，不易拓展。

特点：

传输效率高，减少延迟。

在从库更新不存在的记录时，语句赋值不会失败，而行复制会导致失败，从而更早发现主从之间的不一致。

设表里有一百万条数据，一条sql更新了所有表，基于语句的复制仅需要发送一条sql，而基于行的复制需要发送一百万条更新记录

行数据复制

基于行的复制相当于物理复制，即二进制日志中记录的实际更新数据的每一行。

这样导致复制的压力比较大，日志占用的空间大，传输带宽占用大。但是这种方式比基于语句的复制要更加精确。

特点：

不需要执行查询计划。

不知道执行的到底是什么语句。

例如一条更新用户总积分的语句，需要统计用户的所有积分再写入用户表。如果是基于语句复制的话，从库需要再一次统计用户的积分，而基于行复制就直接更新记录，无需再统计用户积分。

混合类型的复制

一般情况下，默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制。

不能总让DBA手动拷贝来完成复制，所以还是要设计一套可以自动复制的机制。

我们暂定被复制的数据库为主库，粘贴出来的为从库，要实现主库到从库的复制，看起来非常简单，只需一个计划任务，定时将主库数据文件复制一份，并传输到从库所在服务器。

但毕竟定时任务不是实时的，万一主库在上次复制的十分钟后发生了故障，被激活的从库用的是最近一次复制的数据，所以会缺失十分钟的数据，后果不堪设想。

还是要实时复制，那可以这样，主库将每次执行完的语句实时发给从库，让从库马上执行，就能保证两边数据一致了。

不太好的是，主库是实时发送数据给从库的，需要等从库执行完毕才能处理下一条语句，严重占用了主库的执行时间，如果从库过多，主库就废了。

还得改成异步才能节省主库的时间，可以将主库执行完的语句存到文件里，让从库来取，这样主库就不用等待从库了。既然是写到文件，速度是很快的，主库完全可以在执行前就将语句写到文件中，达到更高的同步效率。

上述有些问题，从库无法做到跑去主库取数据，只能起一个线程先与主库建立连接，并向主库索要数据，然后主库也起一个线程读取文件内容，并推给从库线程，从库收到语句后就可以马上执行了。

这样效率还是很低，主库的线程要等从库收到语句并执行完毕才能推下一条，如果有多个从库，主库就要开启多个线程长期与各个从库保持通信，占用主库服务器资源，不如从库也创建个文件临时保存主库发来的语句，先存起来再慢慢执行，主库压力小了，从库也放心。

现在从库有了自己的文件做中继，就不用着急了，从库可以再起一个线程，慢慢执行中继文件中的语句，执行完毕之后原文件没有价值了，就可以清理掉，免得占用服务器资源。

到目前为止，最基本的复制机制就设计完了，这种由主库到从库的复制方式就是典型的主从架构，在此基础上可以进行演化，比如从库有很多，主库要为每个从库推送数据，主库的压力会随之增大，又因为主库的职责不仅仅是同步数据，还要忙着读写数据，所以同步数据的事可以找人代替，比如在主库与从库之间再建立一个主库，新建立的主库唯一的职责就是同步数据给从库，这样真正的主库就只需要推送一次数据给新建的主库，其余时间就可以安心读写数据了。

参考：

一文读懂MySQL复制机制

看完这篇还不懂 MySQL 主从复制，可以回家躺平了～