一、MySQL复制功能提供分担读负载功能
1、为高可用，灾难恢复，备份提供更多的选择
2、通过二进制日志，将数据库复制到备库中（异步）
二、可以实现不同服务器上的数据分布
1、利用二进制日志增量进行
2、不需要太多的带宽
3、但是使用基于行的复制再进行大批量的更改时，会给带宽带来一定的压力
4、特别是跨IDC环境下进行复制
5、应该分批进行
三、实现数据读取的负载均衡
1、需要其它组件配合完成
2、利用DNS轮询的方式把程序的读连接到不同的备份数据库
3、使用LVS，haproxy这样的代理方式
4、非共享架构，同样的数据分布在多台服务器上
四、增强了数据安全性
1、利用备库的备份来减少主库负载
2、复制并不能替代备份
3、方便进行数据库高可用架构的部署
4、避免MySQL单点失败
五、实现数据库高可用和故障切换
实现数据库在线升级
六、MySQL日志：
1、服务层日志：二进制日志，慢查日志，通用日志
2、存储引擎层日志
2.1、innodb：重做日志，回滚日志
七、二进制日志
1、记录了所有对MySQL数据库的修改事件
2、包括增删改查事件和对表结构的修改事件
3、只记录成功的事件
八、基于段的格式：binlog_format=STATEMENT
记录的是sql语句
优点：
1、日志记录量相对比较小，节约磁盘及网络IO
1.1、只对一条记录修改或者插入
1.2row格式所产生的日志量小于段产生的日志量
2、并不强制要求主从数据库的表定义完全相同
3、相比于基于行的复制方式更为灵活
缺点：
1、必须记录上下文信息
2、保证语句在从服务器上执行结果和在主服务器上相同
2.1、在特定函数如UUID()，user()
2.2、这样非确定性还是无法复制的
2.3、可能导致MySQL复制的主备服务器数据不一致
查看格式：show variables like ‘binlog_format’
设置格式：set session binlog_format=statemnet
刷新log：show binary logs(先查看)，flush logs
查看mysqlbinlog ：mysqlbinlog 日志名
九、基于行的日志格式：binlog_format=ROW
row格式可以避免MySQL复制中出现的主从不一致问题
优点：
1、使MySQL主从复制更加安全
2、对每一行数据的修改比基于段的复制高效
误操作而修改了数据库中的数据，同时又没有备份可以恢复时，我们就可以通过分析二进制日志，对日志中记录的数据修改操作做反向处理的方式来达到恢复数据的目的
缺点：
1、记录日志量大
binlog_row_image=[FULL|MINMAL|NOBLOB]
show variable like ‘bingo_row_image’;
set session bingo_row_image=minimal;
十、混合日志格式：binlog_format=MIXED
特点:
1、根据SQL语句由系统决在基于段和基于行的日志格式中进行选择
2、数据量的大小由所执行的SQL语句决定
建议使用mixed格式或者Row格式
binlog_format=row
binlog_row_image=minimal
十一、复制类型
1、基于SQL语句的复制（SBR）
二进制日志格式使用的是statement格式
优点：
1.1、日志记录量相对比较小，节约磁盘及网络IO
1.2、并不强制要求主从数据库的表定义完全相同
1.3、相比于基于行的复制方式更为灵活
缺点：
1、对于非确定性事件，无法保证主从复制数据的一致性
2、对于存储过程，触发器，自定义函数进行的修改也可能造成数据不一致
3、相比于基于行复制方式在从上执行时需要更多的锁
2、基于行的复制（RBR）
二进制日志格式使用的是基于行的日志格式
优点：
1、可以应用于任何SQL的复制包括非确定函数，存储过程等
2、可以减少数据库锁的使用
缺点：
1、要求主从数据库的表结构相同，否则可能会中断复制
2、无法在从上单独执行触发器
3、混合模式
根据实际内容在以上两者间切换
复制工作方式
1、主将变更写入二进制日志
2、从读取主的二进制日志变更并写入到relay_log中
2.1、基于日志点的复制
2.2、基于GTID的复制
3、在从上重放relay_log中的日志
3.1、基于SQL段的日志是从库上重新执行记录的SQL
3.2、基于行的日志则是在从库上直接应用对数据库行的修改
配置MySQL复制
基于日志的复制配置步骤
1、在主DB服务器上建立复制账号，然后授权
CREATE USER ‘real’ @’IP段”identified by ‘password’;
2、配置主数据库服务器
bin_log=mysql-bin
server_id=100(必须是唯一)
3、配置从数据库服务器
bin_log=mysql-bin
server_id=101
relay_log=mysql-relay-bin
log_slave_update=no(可选)
read_only=no(可选)
4、初始化从服务器数据
方法1：mysqldump - -master-data=2 -single-transaction
方法2：xtrabackup - -slave-info(如果只使用innodb,不会出现锁表操作)
5、启动复制连路
优点：
1、是MySQL最早支持的复制技术，Bug相对比较少
2、对SQL查询没有任何限制
3、故障处理比较容易
缺点：
1、故障转移时重新获取新主的日志点信息比较困难
基于GTID复制
基于MySQL5.6
基于日志的复制：从哪个二进制日志的偏移量进行增量同步，如果指定错误会造成遗漏或重复，导致主从不一致
基于GDID的复制
1、从->主：从库已经执行事务的GTID值
2、主->从：从库未执行事务的GTID值
同一个事务只在指定的从库执行一次
GTID：即全局事务ID，其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID
GTID=source_id:transation_id
1、在主DB服务器上建立复制账号
2、配置主数据库服务器
bin_log=/usr/local/mysql/log/mysql_bin
server_id=100
gtid_mode=on
enfore-gtid-consiste
log-slave-updates=no
3、配置从库服务器
server_id=101
relay_log=/usr/local/mysql/log/relay_log
gtid_mode=on
enforce-gtid-consistency
log-slave-updates=on
read_only=no(建议)
master_info_repository=TABLE(建议)
relay_log_info_repository=TABLE(建议)
初始化从服务器数据
mysqldump —master-data=2 -single-transaction
xtarbackup —slave-info
记录备份时最后的事务的GTID值
启动GTID的复制
优点：
1、可以方便的进行故障转移
2、从库不会丢失主库上的任何修改
缺点:
1、故障处理比较复杂
2、对执行的SQL有一定的限制
选择复制模式要考虑的问题
1、使用的MySQL版本，GTID需要5.6以上
2、复制架构及主从切换的方式
3、所使用的高可用管理组件
4、对应用的支持程度
MySQL5.7之前，一个从库只能有一个主库
MySQL5.7之后支持一从多主架构
MySQL复制拓扑
1、一主多从复制拓扑
优点
1、配置简单
2、可以用多个从库分担读负载
用途
1、为不同业务使用不同的从库
2、将一台从库放到远程IDC，用作容灾备恢复
3、分担主库的读负载
主-主复制拓扑
1、主备模式的主主复制
只有一台服务器对外提供服务
一台服务器处于只读状态并且只作为热备使用
在对外提供服务的主库出现故障或是计划性的维护时才会进行切换
使原来的备库成为主库，而原来的主库会成为新的备库并处理只读或是下线状态，待维护完成后重新上线
注意事项:
1、确定两台服务器上的初始化数据相同
2、确保两台服务器上已经启动binlog并且有不同的server_id
3、在两台服务器上启用log_slave_updates参数
4、在初始化的备库上启用read_only
2、主主模式的主主复制
注意事项:
1、产生数据冲突而造成复制链路的中断
2、耗费大量时间
3、造成数据丢失
4、两个主中所操作的表最好能够分开
5、使用下面2个参数控制自增ID的生成
auto_increment_increment=2
auto_increment_offset=1|2
3、级联复制
主->分发主库->多个从库
MySQL性能优化
1、影响主从延迟的因素
1.1、主库写入二进制日志的时间:控制主库的事务大小，分割大事务
1.2、二进制日志传输时间:使用MIXED日志格，设置set binlog_row_image=minnial
1.3、默认情况下从只有一个SQL线程，主上并发的修改在从上变成串行:使用多线程复制，在MySQL5.7中可以按照逻辑时钟的方式来分配SQL线程
1、stop slave(停止链路复制)
2、set global slave_parallel_type=‘logical_clock’;(设计成逻辑时钟的方式)
3、set global slave_parallel_workers=4;设置线程数量
4、start slave 启动
MySQL复制常见问题处理
由于数据损坏或丢失所引起的主从复制错误
1、主库或从库意外宕机引起的错误
解决：使用跳过二进制日志事件，注入空事务的方式先恢复中断的复制链路，再使用其它方法来对比主从服务器上的数据
2、主库上的二进制日志损坏
解决：通过change master命令来重新指定
3、备库上的中继日志损坏
4、在从库上进行数据修改造成的主从复制错误:read_only
5、不唯一的server_id或server_uuid
server_uuid是记录在数据目录中的auto,cnf文件中
6、max_allow_packet设置引起的主从复制错误
MySQL复制无法解决的问题
1、分担主数据库的写负载
通过分库分表处理
2、自动进行故障转移及主从切换
3、提供读写分离功能