MySQL复制

一.MySQL复制概述

    复制是指将主数据库的DDL和DML操作通过二进制日志传到复制服务器（也叫从库）上，然后在从库上对这些日志重新执行（也叫重做），从而使从库和主库的数据保持同步。

    为什么要做主从复制？

    1.如果主库出现问题，可以快速切换到从库提供服务

    2.可以在从库上执行查询操作，降低主库的访问压力

    3.可以在从库上执行备份，以避免备份期间影响主库的服务

    复制的原理是什么？

    1.首先，MySQL主库在事务提交时会把数据变更作为事件Events记录在二进制日志文件Binlog中，MySQL主库上的sync_binlog参数控制Binlog日志刷新到磁盘。

    2.主库推送二进制日志文件binlog中的事件从从库的中继日志Relay Log，之后从库根据中继日志重做数据变更操作，通过逻辑复制以此来达到主库和从库的数据一致。

    

    复制中的各类文件？

    二进制日志文件Binlog会把MySQL中所有的数据修改操作以二进制的形式记录到日志文件中，包括Create, Drop, Insert, Update, Delete操作等，但二进制日志文件不会记录Select操作。

    中继日志文件Relay Log的文件格式、内容和二进制日志文件Binlog一样，唯一的区别在于从库上的SQL县城在执行完当前中继日志文件中的事件后，SQL线程会自动删除当前中继日志文件，避免从库上的中继日志文件占用过多的磁盘空间。

    为了保证从库crash重启之后，从库的IO线程和SQL线程仍然能够知道从哪里开始复制，从库上默认还会创建两个日志文件用来报错复制的进度。这两个文件在磁盘上以文件形式分别记录了从库的IO线程当前读取主库二进制Binlog的进度和SQL线程应用中继日志的进度。

    三种复制方式？

    1.Statement：基于SQL语句级别的Binlog，每条修改数据的SQL都会保存到Binlog里

    2.Row：基于行级别，记录每一行数据的变化，也就是将每行数据的变化都记录到Binlog里，记录得非常详细，但并不记录原始SQL，在复制的时候，并不会因为存储过程或持法器造成主从数据不一致的问题，但是记录的日志量较statement格式要大的多

    3.Mixed：混合Statement和Row模式，默认情况下才从statement模式记录，某些情况会切换到Row模式

二、复制的3种常见架构

1.一主多从复制架构

    在主库读取请求压力非常大的场景下，可以通过配置一主多从复制架构实现读写分离，把大量对实时性要求不是特别高的读请求通过负载均衡分布到多个从库上，降低主库的读取压力。在主库出现异常宕机的情况下，可以把一个从库切换为主库继续提供服务。

2.多级复制架构

    主库Master1只需要给一个从库Master2推送Binlog日志即可，减轻主库Master1推送的压力，二级主库再推送Binlog日志给从库。多级复制解决了一主多从场景下，从库的IO负载和网络压力，缺点是MySQL的复制是异步复制，多级复制场景下的主库的数据是经历过两次复制才到达从库的，期间的延时比一主多从复制场景下只经历一次复制的要大

3.双主复制/Dual Master架构

    双主/Dual Master架构特别适用于DBA做维护等需要主从切换的场景，通过双主架构避免了重复搭建从库的麻烦。

三、MySQL复制搭建过程

1.异步复制

    主库执行完Commit提交操作后，在主库写入Binlog日志后即可成功返回客户端，无需等到Binlog日志传送给从库

2.半同步复制

    半同步复制为了保证主库上每一个Binlog事务都能够被可靠地复制到从库上，主库在每次事务成功提交时，并不及时反馈给前端用户，而是等待其中一个从库也接收到Binlog事务并成功写入中继日志后，主库才返回Commit操作成功给客户端。

四、如何提高复制的性能

主库是多线程并发在写入，而从库仅仅只有一个SQL线程在执行应用，容易出现从库追不上主库的情况。

方案一：通过拆分减少一个从库上需要数据同步的表来解决。使不同的从库复制不同的库/表，减少每个库上需要写入的数据。

方案二：MySQL5.6支持基于Schema的多线程复制，运训从库并行更新

此文来源于阅读《深入浅出MySQL 数据库开发、优化与管理维护》