MySQL复制

一、复制概述

复制解决的问题是让一台Mysql服务器的数据与另一台服务器保持同步。一台主库的数据可以同步到多台备库上，备库本身也可以配制成另外一台服务器的主库。复制不仅有利于构建高性能的应用，同时也是高可用性、可扩展性、灾难恢复、备份以及数据仓库等工作的基础。

二、复制原理

1.复制方式

基于语句

Msql5.0之前只支持基于语句的复制。主库会记录那些造成数据更改的查询，备库读取并重放这些事件，将这些sql在执行一遍。这种方式的优点有：一、实现简单。二、binlog更加紧凑。缺点有：对于一些依赖系统环境的查询没法支持，比如依赖了时间的SQL，由于mysql的复制是异步的，执行复制会有延迟。

update t_table set field = xxx where create_time > NOW();

基于行

Mysql5.1开始支持基于行的复制，这种方式会将实际数据记录在binlog中。它的优点在于可以正确的复制每一行数据。基于行的复制在某些场景下比基于语句的复制更加高效，比如从a表中扫描大量数据，然后写入到汇总表中。基于语句的复制需要将整个sql重放，而基于行的复制只需要同步少量最终结果数据，并不需要执行大量的查询。基于行的复制在某些场景下也可以比基于语句的复制更加低效，比如修改id<xxx的数据，将它们的delete_flag置为1，对于复制语句来讲，binlog中只需要记录一条sql，而基于行的复制需要在binlog中记录大量的实际数据。
没有哪种方式对所有情况都是完美的，Mysql能够在两种复制方式间动态切换。默认基于语句的复制方式，如果发现语句无法正确复制，则切换成基于行的复制。

2.复制如何工作

第一步

主库上记录binlog。在每次准备提交事务完成数据更新前，主库将数据更新的事件记录到binlog中，MySQL会按照事务提交的顺序记录binlog，在记录binglog后存储引擎再提交事务。

第二步

备库将主库上的binlog复制到自己的relay log中。备库会启动一个IO线程，跟主库建立一个客户端连接。主库会启动一个binlog dump线程，读取binlog事件，如果该线程追赶上了主库，它会进入睡眠状态，直到新的事件来临，再次被主库唤醒。备库IO线程将接收到的事件记录到relay log中。

第三步

备库读取relay log中的事件，并重放到备库数据中。备库会启动一个SQL线程，从relay log中读取事件，并再备库上执行。SQL线程执行的事件也可以通过配置选项来决定是否写入自己的二进制日志中。
MySQL的复制架构实现了获取事件和重放事件的解耦，允许两个过程异步进行，IO线程与SQL线程独立工作。但这种架构也限制了复制的过程，主库上并发执行的查询到备库上只能串行，因为只有一个SQL来重放relay log。

如果打开备库打开了log_slave_updates选项，备库也会记录binlog，并可以作为另一个备库的数据源。

三、复制拓扑结构

复制的基本原则：
1.一个MySQL备库只能有一个主库
2.每个备库有唯一的服务器id
3.一个主库可以有多个备库
4.如果打开了log_slave_updates选项，一个备库会记录bin log，并可以作为其他备库的主库。

一主多备

在有少量写和大量读，并且对数据一致性要求不高时，这种配置十分有用。写主库，读从库，从而分摊压力。直到主备之间的同步成为瓶颈。

被动双主

两台服务器分别是对方的主库，也是对方的备库。但是只有一台执行写操作。这种方式使得反复切换主动和被动服务器非常方便。主动服务器将变更记录到binlog中，被动服务器重放变更事件，并记录binlog，binlog事件被同步到主动服务器上，主动服务器判断事件服务器id未主动服务器自己，于是忽略这些事件。这种复制模式类似创建了一个热备份。

多层复制

1.如果有多个备库从主库复制，可能给主库带来很大压力，可以选择一个备库从主库复制，然后其余备库从那个备库中复制。
2.对于在线事务处理OLTP和在线数据分析OLAP的查询，OLTP查询短，而OLAP查询通常很大而且慢，不要求绝对新的数据。可以将两者分开，查询不同的库。