备份，灾难恢复，大规模，水平扩展，高性能的基础，也是高可用，可扩展，及数据仓库的基础。
简述
开销
Mysql有两种复制方式：基于行的复制和基于语句的复制。
都是通过在主库上记录二进制日志，在备库上重放日志实现的。
主要开销来自于：
- 主库部分启用二进制日志带来的开销。
- 每个备库会增加网络开销
-
主库开多线程给备库同步数据开销会累加
通常使用读写分离，在备库中读来获得读扩展
解决的问题
- 负载均衡 读写分离，度扩展
- 数据分布 用复制功能来简历多个不同的数据中心
- 备份
- 高可用性 避免单点失败，可以很快的切换到备库，缩短宕机时间
- 升级测试，用高版本作为备库，可以看看能否按照预期执行。
复制如何工作
- 主库事务提交时记录事件到二进制日志中
- 备库启动I/O线程去连接主库，主库启动一个线程来处理连接，然后又事务日志要写的时候，主库写日志给备库，备库处理到自己的中继日志中
- 重放中继日志，回写备库数据
配置复制
拢共分三步
- 在主备都创建复制账号
- 配置主库和备库
- 通知备库连接到主库复制数据
创建账号
注意权限，注意ip限制，因为有权利读取日志，所以还是限制了ip
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl1@'10.28.%.%' IDENTIFIED BY 'p4ssword';配置主备库
主库打开二进制日志my.cnf加入：
log_bin = mysql-bin
server_id = 10
server_id是自己定的。必须是唯一的。
使用如下的语句检查：
SHOW MASTER STATUS;备库的配置：
log_bin = mysql-bin
server_id = 2
##中继文件日志
relay_log = /var/lib/mysql/mysql-relay-bin
##允许把重复也记录到备库的binlog
log_slave_updates = 1
read_only = 1
##放弃了master_port这样的配置方式启动复制
在备库中执行：
CHANGE MASTER TO MASTER_HOST='主库ip',
-> MASTER_USER='repl', ## 刚才创建的
-> MASTER_PASSWORD='p4ssword',
-> MASTER_LOG_FILE='mysql-bin.000001', ## 主库中执行SHOW MASTER STATUS得到的
-> MASTER_LOG_POS=0; 从头读起执行完成后使用 SHOW SLAVE STATUS来查看一下发现Slave_IO_Runing为NO
在执行
START SLAVE;来启动
还可以从主库上检查复制线程
SHOW PROCESSLIST
有库不是新库时
把已有库编成另一个的备库，我们需要如下的信息：
- 某一时刻快照
- 主库当前的二进制文件和快照在二进制文件中的坐标
- 从快照时间到现在的二进制日志
一些克隆备库的方法： - 冷备 ， 关闭数据库， 把数据复制到备份。 然后配置主备，重启之后会用新的日志文件，在被库中执行CHANGE MASTER TO 命令进行同步
- mysqldump –single-transaction –all-databases –master-data=1 –host=server1 mysql –host=server2
- 使用Percona Xtrabackup工具
推荐的复制配置
sync_binlog=1 开启则每次提交事务都会将二进制日志同步到磁
盘。
log_bin=/ 指明二进制文件名，免得默认的因为系统不同而有问题
relay_log_purge 控制重放完后尽快删除中继日志
read_only=
relay_log=
复制原理
基于语句
简单的记录执行的语句，放到备库去执行
优点：
更容易理解
更灵活及容错，因为都是sql语句的
缺点：
存储过程，触发器不行
一些依赖环境的内置方法也不行
必须顺序执行，会带来更多的锁
基于行
日志记录行的变更。
优点：
可以直接复制变更结果，对于一些耗时sql可以节约性能
不会受到触发器等特殊情况的限制
缺点：
无法判断执行了哪些sql,有点像黑盒子
不好跟踪问题
对于一些特殊语句比如update 全表的一个状态，这种基于行的开销会很大
Mysql会自动切换，当基于语句不行的时候就会尝试基于行的。
复制拓扑
- 一个备库只能有一个主库
- 每个备库必须有唯一id
-
打开log_slave_updates选项时，备库可以把其主库上的数据变化传播到其他备库
一主多备
一个备库用于灾难恢复
- 适用于少写多读的场景。可以负载均衡
- 使用一个备库用于测试等等
-
ALtertable这样的语句在备库执行，然后主备切换
双主动双主库
太乱，Mysql不支持
主动-被动 双主结构
可以认为是一个热备。 可以随时切换主备
被动模式的主库也可以当备库一样使用主库带备库的 主动-被动 双主结构
主动，被动两个库都各有一个备库
分发主库
作为被动的主库有多个备库。这种可以防止备库太多给主库带来负载
但是这样就不能直接使用备库替换主库了。因为中转了一道bin_log不一样了树形
一个主，多个备，备库又有备库的结构。
好处跟分发主库有点像，可以减少多备库压力
坏处在于如果沿途有节点除了问题，会影响多个节点
选择性复制
备库复制主库中不同的表。
简单的做法就是在主库中把表放入不同的数据库，然后备库只复制其中一个数据库。
这样每个备库都只有一部分的主库写入负载
备库的用途
- 数据分离 可以专门分离一个备库出来，做在线数据分析OLAP，而不是在线事务处理OLTP
- 数据归档 在备库上保存主库上删除的数据
可以用过滤， 或者是user db1, replicate_ignore_db=db1这样的方式 - 备库做全文检索 把备库中的部分表用MyISAM引擎
- 只读备库
模拟多主库复制
Mysql不支持一个备库多主库， 可以让备库一会儿指向备库A，一会儿指向备库B， 这样增加一点额外的工作来记录bin-log位置
创建日志服务器
如果一个服务器崩溃了，我们去他的二进制日志或者中继日志，希望重放他。
这是可以勇mysqlbinlog工具。
更好的方式是，建立一个新的数据库，让他认为这些二进制文件时他的。然后启动他，让别的数据库来复制它来获得二进制文件进行重放
好处：
- 复制的速度很快
- 更方便处理错误
- 复制功能被测试过，运行良好
复制和容量规划
先看个计算，假设，读写消耗一样，读写比例2:8， 服务器只能每秒1000次请求。
这个时候做读写分离。 如果支撑请求翻倍需要增加多少台备库呢？
翻倍的话，要有400次写，1600次读，每个备库都会有400次写，那么这个时候就只能支撑600次读了，所以需要三台备库。
这样算下来，使用读写分离和备库的方式负载查询代价很高。
一般不要让读超过50%的负载，避免备库出现问题的时候造成单点热点过高。
可以停止备库，过一小时之后打开，看备库多久能赶上，来得到备库的执行性能
大多数情况下性能还是比较好的，在主库执行的耗时操作往往是备库延迟的原因。
