高可用：
两地双中心概念
同城：同IDC：增强半同步复制
跨城：异步复制
两地三中心：（金融支付银行）
同城：跨IDC，增强半同步
跨城：异步复制
传统复制线程解析
GTID原理
半同步复制线程解析
并发复制
延迟复制实现
多源复制
MySQL-5.7 在复制线程方面的增强
主从数据校验：
pt-table-checksum
GTID:
MySQL 5.6 从非GTID到GTID切换，需要重启
MySQL 5.7 支持在线启用GTID
切换流程：
gtid_modd=
1、主从全部off_permissive。
set global gtid_mode=off_permissive;
2、从库on_permissive，主库on_permissive
set global gtid_mode=on_permissive
3、确认整个group中binlog非GTID的执行完毕
4、主库on，从库on
set global gtid_modd=on;
MySQL 5.7 GTID会存储到表里。
支持slave不用开启binlog(log_slave_updates)
mysql.gtid_executed
如何记录GTID
如果开启binlog,在binlog切换时，将当前的GTID插入到gtid_executed表中。
如果没有开启binlog，每个事务提交前，会执行一个insert
gtid_executed表压缩
控制压缩频率
set global gtid_executed_compression_period=N;（默认1000）
enforce-gtid-consistency
off:不检测是否有GTID不支持的语句/事务
warn：当发现不支持语句/事务，返回警告，并在日志中记录警告信息
on： 当发现语句/事务不支持GTID时，返回错误
TIPS：
在现实从非GTID切换过程中，可以先设置成：warn
GTID Limit：
不能使用 create table tb1 select * from tb2;
可以改成： create table tb1 like tb2; insert into tb1 select * from tb2;
事务中更新非事务表：
begin：update no_trx_tabe set col1 =xxx where xxx; update trx_tb set col1=xxx where ...commit;
事务中创建/删除临时表
begin:update trx_tb set xxx;create temporary table...;commit;
sql_slave_skip_counter 不支持
GTID跳过错误：
stop slave;
SET @@SESSION.GTID_NEXT= '01eea86a-5da6-11e8-a709-c03fd5486d6f:282';
begin;commit;
set gtid_next="automactic"
半同步复制：
在Master收到Slave将事务执行完的ACK应答后才Commit事务（5.6是Master在Commit后，才等待Slave应答）
因此在事务复制到slave前，并发的事务看不到当前的事务的数据
当master故障时，所有已提交的事务都会复制到slave上
默认采用无数据丢失的应答等待机构，用户可以选择使用5.6的应答待机制
set rpl_semi_sync_master_wait_point=after_sync|after_commit
如果响应超时 rpl_semi_sync_master_timeout(超时时间)，会自动降级为异步复制
修复会自动升级为半同步
增强半同步：
5.7以后默认：(生产使用增强半同步没问题）
主库写binlog，传输到从库后，从库返回ACK，主库commit；性能更好
set rpl_semi_sync_master_wait_point=AFTER_SYNC;
创建单独的应答接收线程
变成双工默认，发送和接收互不影响
master接收到N个slave应答后，才commit事务
用户可以设置应答的slave数量
set global rpl_semi_sync_master_wait_for_slave_count=2;(有两个slave相应再commit；)
特别提示：
低于5.7的版本，在从库关闭后一段时间后，刚启动时，注意先用异步复制，复制追上后，再用半同步复制
master:
set global rpl_semi_sync_master_enabled=ON|OFF;
slave;
set global rpl_semi_sync_master_enabled=ON|OFF; (确认主库on，之后slave再on)
增强半同步 Master Crash Recovery
1、扫描最后一个Binlog提取其中的Xid
2、扫描innodb维持状态（redo log）在Prepare的事务链表，和binlog中的Xid比较，如果binlog中存在，则提交，否回滚。
提交到innoDB中处于Prepare，并且写Binlog的，就可以从崩溃中恢复事务。
并发复制
MySQL 5.6的并发复制是基于库级别（由于生产都是多实例+单库的架构，所以基本无用）
实质上需要：
让master上能并发执行的事务，在slave上也并发执行
在binlog中记录事务并发执行的相关信息
slave上根据上这些的信息，让这些食物在slave上多个线程中并发执行
MySQL 5.7的并发复制是基于事务级别的（logical Clock）
基于锁的并行复制
并发信息以逻辑时间方式写入的gtid_log_event中，共记录2个逻辑时间：
sequence_number
当事务写入binlog时，事务自己的逻辑时间，按照事务记录binlog的顺序递增
commit_parent
当食物进行prepare阶段时，已经提交的事务的最大逻辑时间
事务在slave执行
commit_parent 之前事务全部提交以后，才开始执行
并行复制：
最好配置binlog group commit
binlog_group_commit_sync_delay=20-300 微妙 ：时间
binlog_group_commit_sync_no_delay_count=10-30 ：事务数
延迟复制
让从库和主库保持固定时间的延迟（sql_thread)
使用场景
利用延迟复制做误操作恢复
利用延迟复制做统计分析环境处理
stop slave sql_thread
change master to master_delay=N; #N单位是S
多源复制
多个M对应一个S
场景：
集中备份
数据分析聚合
分片数据合并
多个channels(channel包含：recevier thread,relay logs,applier threads)每个channel能独立的运行和停止
通过P_S表进行状态监控：
下列表中添加了channel_name字段，不同的channel的信息在不同的行中显示
replication_applier_status_by_coordinator
replication_applier_status_by_work
replication_connection_status
show slave status\G
group replication
实质是：
二进制日志
基于Row格式+GTID
一个通信框架+事务排序控制
增强半同步&并行复制
是一个趋势
备份不好搞定
xtrabackup备份，造成性能损失比较严重
新的节点加入过程对原有集群性能有影响
练习：
1、增强半同步复制，半同步复制，异步复制区别
2、测试主从数据校验，pt-table-checksum