10.1 复制概念
mysql有两种复制方式，都是通过主库上记录二进制日志，在备库重放日志实现异步的数据复制，所以会存在一定概率同时刻主库与备库数据不一致
- 基于行的复制
- 基于语句的复制
- mysql的复制大部分都向后兼容（版本）
- 复制一般不会增加主库的开销（启用二进制日志、还有一点网络及IO的消耗）
- 主备一般能扩展可读性，并不能解决写的瓶颈
10.1.1 复制的用途
- 数据分布（异地分布）
- 负载均衡
- 备份
- 高可用及故障切换
- mysql升级测试
10.1.2 复制如何工作
主库记录二进制日志，备库将二进制日志同步到自己的中继日志，最后在自己服务器进行回放
- 每次准备提交事务完成数据更新之前，主库将数据更新的事件记录到二进制日志中。mysql会按照事务提交顺序而不是sql执行顺序来同步，记录二进制日志后，会主动通知存储引擎备份结束可以提交事务
- 备份会启动一个工作线程，与主库建立客户端连接，主库会启动一个二进制转储线程，该线程会读取二进制日志中的事件。他不是主动进行轮询来查询日志，如果速度追赶上了主库，则休眠，一旦来了新日志主库会主动通知唤醒她执行转换操作
- 备库有一条I/O线程（同步日志到中继日志中），一条sql线程获取日志执行更心数据，实现了获取事件与重放事件的解耦，允许异步执行。但是这样会限制复制的过程，其中最重要的一点是主库并发执行的查询，在备库只能串行化执行，因为只有一个sql线程重复中继日志，这也是很多功能性能瓶颈所在
10.2 配置复制
10.2.1 创建复制账号
10.2.2 配置主库和备库
需要在主库上开启一些配置，假设主库是服务器server1，需要打开二进制日志并指定一个独一无二的服务器ID
10.2.3 启动复制
告诉备库如何连接并重放主库的二进制日志。
show slave status命令查看复制状态
10.2.3 从另一个服务器开始复制
- 在某个时间点的数据快照
- 主库当前的二进制日志文件和获得数据快照时在该二进制文件中的偏移量，通过这两个条件可以得到二进制日志的位置
- 从快照时间到现在的二进制日志
以下为从其他服务器复制备份库的办法
- 使用冷备份，关闭主库，把数据复制到备份库
- 使用热备份，如果是MyISAM引擎可以在主库运行时使用命令来复制数据
- 使用mysqldump命令（InnoDB）
- 使用快照或备份
- 使用第三方工具
10.3 复制的原理
基于语句的复制方式的优点
- 实现简单
- 某些场景下执行效率高，如更新几兆数据只是一个update语句时网络传输压力小
- 二进制日志里的事件更加紧凑
基于语句的复制方式存在的痛点
- 部分语句的更新不只是简单的执行，还收其他因素影响（如时间戳、元数据信息等）
- 在备库的执行必须串行化执行语句，需要更多的锁，且不是所有存储引擎都支持这种模式
基于行的复制方式的优点
- 可以正确的复制每一行记录
- 由于无需重放更新主库的查询，使用基于行的复制模式能够更高效的复制数据
基于行的复制方式的缺点
- 如果是全表更新，会基于行产生大量的行更新日志，网络传输会产生大量的更新日志
mysql会自动在两种模式下动态择优切换，默认使用基于语句的复制方式，但是发现基于语句的方式无法实现，就切换成基于行复制。基于行的复制很难进行时间点恢复,但是也不是不能实现。
理论上基于行的方式更优，但是方式太新，实际当前应用很少
server id唯一性的原因
10.4 复制拓扑
基本要求
- 每一个备库只能有一个主库
- 每个备库必须有一个唯一服务器ID
- 一主可有多从
- 如打开log_slave_updates参数，一个备库可以吧其主库上的数据变化传递到其他备库
如果备库的服务器ID相同会导致互相竞争，反复将对方从主库上剔除
环形复制
10.5 复制和容量规划
复制时的qps举例容量计算
复制无法解决写的瓶颈
可以通过人为停止主库的方式来测试备库的更新速度是多快
10.6 复制的管理和维护
- 监控复制
- 测试主备延迟
- 确定主备是否一致
10.7 复制的问题和解决方案
备份中断情况列举
10.8 复制速度
10.9 复制的高级特性
mysql5.5的复制改进
- 半同步复制：可以帮助确保备库拥有所有主库数据拷贝，减少了潜在数据丢失危险
