1.主从复制的前提(传统复制)
两个以上实例
主库开启binlog
server_id要不同
主库需要建立专用的复制用户
告诉从库，主库的信息
从库开启线程
grant replication slave on *.* to 'repl'@'172.16.88.%' identified by '123';CHANGE MASTER TO MASTER_HOST='172.16.88.83',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='123',MASTER_LOG_FILE='mysql-bin.001355',MASTER_LOG_POS=154;复制
主从复制中涉及的文件
主：binlog
从：relaylog/master.info/relaylog.info
涉及的线程
主：binlog_dump
从：slave_IO/slave_SQL
2.主从复制故障
从库：
IO线程故障
连接主库(网络，连接信息错误，链接数上限等)
排查思路：用复制用户手工登陆(stop slave,reset slave all;change master,start)
请求binlog
binlog损坏，不存在
sql线程故障(回放relay-log)
relay-log 损坏
sql重复执行，约束条件：
主键冲突报错：update冲突行，跳过报错。原则：一切以主库为准
避免措施
从库只读
read_only
super_read_only
使用读写分离中间件
mycat、maxscale、atlas、proxySQL
2.1主从延时
主库原因
1.binlog写入不及时
sync_binlog=1
2.默认情况下dump_t是串行传输binlog
在并发事务量大时，或者大事务，导致传送日志较慢
解决？GTID，使用group commit方式，可以支持DUMP_T并行
3.主库极其繁忙
慢语句，锁等待，从库个数，网络延时
从库原因
1.传统复制
由于是单SQL线程，只能一次执行一个事务，如果主库并发事务量大
5.6版本，有了GTID，可以实现多SQL线程，但是只能基于不同库的事务(顺序)进行并发回放。
5.7版本中，增强了GTID，增加了seq_no,增加了新型的并发SQL线程模式（logical_clock）
2.主从硬件差异太大
3.主从的参数配置
4.从库和主库的索引不一致
5.主从版本有差异
主从延时的监控（show slave status）
seconds_behind_master:0
主库方面原因监控
主库：show master status
从库：master_log_file/Read_master_log_pos
从库方面原因监控
拿了多少
master_log_file/Read_master_log_pos
执行了多少
relay_log_file/relay_log_pos
问题binlog和relaylog号对不上？
exec_master_log_pos拿这个与Read_master_log_pos比较
延时从库
sql线程延时，数据写入relaylog，但sql线程慢点运行
change master to master_delay=3600;
show slave status有关信息
sql_delay
sql_remaining_delay
延时从库处理逻辑故障
思路
1.发现故障
2.停从库sql线程，记录已经回放的pos点
stop slave sql_thread;
relay_log_file/relay_log_pos：320
3.截取relaylog
起点：relay_log_file/relay_log_pos：320
终点：show relaylog events in 'relay_log_file'（看左边的pos点）
4.模拟sql线程回访日志
从库 source
5.恢复业务
单一库的话，直接替代
多个库的话，从库导出故障库还原到主库中
3.过滤复制
主库（不常用）
binlog_do_db(白名单)
binlog_ignore_db(黑名单)
从库
show slave status
replicate_do_db
replicate_ignore_db
replicate_do_table
replicate_ignore_table
replicate_wild_do_table
replicate_wild_ignore_table
例子：vim etc/my.cnf
replicate_do_db=test
4.GTID
核心参数
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=1 slave更新是否记入binlog日志，当从库作为其他从库的主库时，必须开启
CHANGE MASTER TO MASTER_HOST='172.16.88.83',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='123',MASTER_AUTO_POSITION=1;START SLAVE;复制
与传统区别：
1.在全局有唯一gtid记录，更方便failover
2.额外参数3个
3.change master不需要指定binlog和pos
4.复制过程中，从库不再依赖master.info文件，而是读取最后一个relaylog的GTID号
binlog的gtid模式
对于binlog中的每个事务，都会生成一个gtid号，DDL，DCL一个event就是一个事务，就会有gtid号
DML来讲，begin到commit，就是一个gtid号
组成
server_uuid:TID
GTID的幂等性
恢复时，如果有相同的gtid号，就会自动跳过，会影响主从和binlog恢复
恢复
mysqlbinlog --include-gtids='xxxx:1-3' mysql-bin.000001
恢复时报错？因为幂等性检查，1-3事务已经做过了
正确操作
mysqlbinlog --skip-gtids --include-gtids='xxxx:1-3' mysql-bin.000001
--skip-gtids 忽略原有的gtid信息，恢复时生成最新的gtid信息
--exclude-gtids 跳过的gtid
5.半同步(用的少)
解决主从数据一致性问题，性能有损耗。
从库relay落地，io线程会给主库返回一个ack，主库收到后事务才能提交。
部分内容来自网络，如有侵权请联系作者删除。
