复制概述
复制解决的基本问题是让一台服务器的数据与其他服务器保持同步
MySQL支持两种复制方式：基于行的复制和基于语句的复制，通过在主库上记录二进制日志，然后在备库重放日志的方式来实现异步数据的复制
复制解决的问题
- 数据分布：比如在不同的地理位置存放数据备份，不同的数据中心
- 负载均衡：通过复制将读操作分布到多个服务器上，实现对读密集型应用的优化
- 备份：复制是备份的一种补充，代替不了备份
- 高可用性和故障切换：避免单点故障，切换备库缩短宕机时间
- MySQL升级测试
复制如何工作
- 在主库上把数据更改记录到二进制日志（Binary Log）中（这些记录被称为二进制日志事件）
- 备库将主库上的日志复制到自己的中继日志（Relay Log）中
- 备库读取中继日志中的事件，将其重放到备库数据之上
- 两个新的数据库之间的配置
创建复制账号、配置主库和备库、启动复制
- 从另一个服务器开始复制
一个已经运行了一段时间的主库，然后用一台新安装的备库与之同步，此时这台备库还没有数据，需要三个条件来让主库和备库保持同步：
- 在某个时间点的主库的数据快照
- 主库当前的二进制日志文件，二进制日志文件中的偏移量（日志文件坐标）
- 从快照时间到现在的二进制日志
- 从别的服务器克隆备库的方法
- 冷备份：关闭数据库，拷贝数据文件
- 热备份：mysqlhotcopy、rsync
- mysqldump
- 快照或备份
- Xtrabackup：可以在不影响主库的情况下设置备库
- 如果是从主库获得备份，可以从xtrabackup_binlog_pos_innodb文件中获得复制开始的位置
- 如果是从另外的备库获得备份，可以从xtrabackup_slave_info文件中获得复制开始的位置
复制的原理
- 基于语句的复制
主库会记录那些造成数据更改的查询，当备库读取并重放这些事件时，实际上只是把主库上执行过的sql再执行一遍
优点：
当主备的模式不同时，逻辑复制能够在多种情况下工作：比如数据类型不同、列的顺序不同；基于语句的复制方式一般允许更灵活的操作；基于预计的方式执行复制的过程基本上就是执行SQL语句。出现问题容易定位。
缺点：
对于储存过程、触发器，存在Bug；如果正在使用触发器或者储存过程，就不要使用基于语句的复制模式，除非能够清楚的确定不会碰到复制问题
- 基于行的复制
将实际数据记录在二进制日志中，可以证券的复制每一行数据
优点：
几乎没有基于行复制模式无法处理的场景，容易找到并解决数据不一致的情况；比如基于语句的复制模式，在备库更新一个不存在的记录时不会失败，但在基于行的复制模式下则会报错并停止复制
缺点：
由于语句并没有在日志里记录，因为无法判断执行了哪些SQL；使用一种完全不同的方式在备库进行数据变更，执行基于行的变化的过程就像一个黑盒子，无法知道服务器正在做什么；
复制拓扑
- 一主多备
场景：少量写、大量读
- 主-主（主动-主动）
(⊙o⊙)…MySQL不支持多主库复制
- 主-主（主动-被动）
构建容错性和高可用的强大方式，主要区别在于：其中一台服务器是只读的被动服务器，这种方式使得反复切换主动和被动服务器非常方便，因为服务器的配置是堆成的。使得故障转移和故障恢复很容易。它也可以让你在不关闭服务器的情况下执行维护、优化表、升级操作系统或者其他任务。
配置：
1）确保两台服务器上有相同的数据
2）启动二进制日志，选择唯一的服务器ID，并创建复制账号
3）启用备库更新的日志记录，这是故障转移和故障恢复的关键
4）把被动服务器配置成只读
5）启动每个服务器的MySQL实例
6）将每个主库设置为对方的备库，使用新创建的二进制日志开始工作
- 拥有备库的主-主结构
- 环形复制
环形结构非常脆弱，尽量避免
- 一个主库、一个分发主库和多个备库
分发主库也是一个备库，只是其他备库从这个分发主库来接收日志事件，降低主库的压力
- 树形或者金字塔形
好处是减轻主库的负担，缺点是中间层出现任何错误都会影响到多个服务器，中间层次越多，处理故障就会更困难、更复杂
用途建议
- 选择性复制
比如按部门，将数据复制到不同的数据库
- 分离功能
在主库上用作OLTP，在备库上作OLAP分析
- 数据归档
在备库上实现数据归档，保留主库上删除过的数据
- 将备库用作全文检索
- 只读备库
- 模拟多主库复制
- 创建日志服务器
创建没有数据的日志服务器，它的唯一目的就是更加容易重放并且过滤二进制日志事件，对崩溃后重启复制很有帮助
