mysql主从复制
主从复制中涉及的文件
主库：binlog
从库：relaylog 中继日志
master.info 主库信息文件
relaylog.info relaylog应用的的信息
主从复制工作过程
1、从库执行change master to 命令（主库的连接信息+复制的起点）
2、从库会将以上信息，记录到master.info 文件
3、从库执行 start slave 命令，立即开启IO_T和SQL_T
4、从库 IO_T 读取 master.info 文件中的信息
5、从库 IO_T 请求连接主库，主库专门提供一个 DUMP_T ，负责和 IO_T 交互
6、IO_T 根据 binlog 的位置信息（mysql-bin.000004，444），请求主库的新的 binlog
7、主库通过 DUMP_T 将最新的 binlog ，通过网络TP给从库的IO_T
8、IO_T 接收到新的binlog 日志，存到到 TCP/IP 缓存，立即返回ACK给主库，并更新 master.info
9、IO_T将TCP/IP 缓存中数据，转存到磁盘 relaylog 中
10、SQL_T 读取 relay.info 中的信息，获取到上次已经应用过的 relaylog 的位置信息
11、SQL_T 会按照上次位置点回放最新的 relaylog ，再次更新 relay.info 信息
12、从库会自动 purge 应用过 relay 进行定期清理
补充说明：
一旦主从复制构建成功，主库当中发生了新的变化，都会通过 dump_T 发送信号给 IO_T ，增强了主从复制的实时性。
主从复制监控（一般从库中监控）
主库命令：
show master status
从库命令：
show slave status \G
#重点查看的参数：
主库有关信息：
1、Master_Log_File（关于主库的二进制日志文件）
2、Read_Master_Log_Pos（获取到的主库的位置信息点）
从库 relay 应用信息有关的 （relay.info）
1、Relay_Log_File
2、Relay_Log_Pos
3、Relay_Master_Log_File
从库线程运行状态（排错）
1、Slave_IO_Running: Yes
2、Slave_SQL_Running: Yes
3、Last_IO_Errno: 0
4、Last_IO_Errno:
5、Last_SQL_Errno（错误代码）: 0
6、Last_SQL_Errno（错误原因）：
过滤复制有关的信息（选择性同步，比如有8个库，只同步其中两个）
1、Replicate_DoDB:
2、Replicate_Ignore_DB:
3、Replicate_Do_Table:
4、Replicate_Ignore_Table:
5、Replicate_Wild_Do_Table:
6、Replicate_Wild_Ignore_Tables;
延时从库（主动设置延时的时间，延时逻辑的误操作的扩散）
1、SQL_Delay: 0
2、SQL_Remaining_Delay: NULL
GTID复制有关的状态信息
1、Retrieved_Gtid_Set:
2、Executed_Gtid_Set:
3、Auto_Position: 0
主从复制故障
解决：show slave status \G #查看监控，寻找报错原因
（1）、IO线程故障
解决：
1、stop slave
2、reset slave all;
3、change master to 位置信息点
4、start slave
（2）、网络故障
（3）、请求binlog 不到
（4）、sql线程故障
处理方法：
冲突时，一切以主库为准进行解决。
如果出现问题，尽量进行反操作
最直接稳妥办法，重新构建主从
暴力解决办法：
当错误代码为1007（对象已存在），1032（无法执行DML），1062（主键冲突或约束冲突）时，可用
stop slave;
set global sql_slave_skip_counter = 1; #跳过此次报错
start slave;
为了避免很大程度上的SQL线程故障
（1）从库只读；两个参数，加到配置文件里重启即可
read_only [OFF]
super_read_only [OFF]
show variables like '%read_only%'; #查看配置状态
（2）使用读写分离中间件（更多企业选择第2种）
主从延时监控及原因 *****
（1）binlog 写入不及时
sync_binlog=1
(2)默认 dump_t 是串行传输 binlog ，在并发事务量大时，导致传送日志变慢
解决：必须GTID ，使用Group commit 方式，可以支持 DUMP_T 并行
延时从库介绍及配置
SQL线程延时：数据以写入 relaylog 中了，SQL线程“慢点”运行，一般企业建议3-6小时，具体看公司运维人员对于故障的反应时间。
mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY = 300;
mysql>start slave;
mysql>show slave stauts \G
SQL_Delay: 300
SQL_Remaining_Delay: NULL
延时从库处理故障
恢复思路
1、监控到数据库逻辑故障
2、停从库SQL线程，记录已经回放的位置点（截取日志起点）
stop slave sql_thread ;
show slave stauts \G;
Relay_Log_File:db01-relay-bin.000002;
Relay_Log_Pos:320
3、截取relaylog
起点：show slave status \G
Relay_Log_File ,Relay_Log_Pos
终点：drop 之前的位置点
show relaylog events in ''
(4)模拟SQL线程回访日志
延时故障演练（恢复从库）
主库误删库故障，挂起维护页，排错，发现误
1、从库SQL线程停止
mysql>stop slave sql_thread;
2、从库立即获取起点位置
mysql>show slave status \G；
Relay_Log_File：db01-relay-bin.000002
Relay_Log_Pos：626
3、找到relay 的截取终点
mysql>show relaylog events in 'db01-relay-bin.000002';
找到drop database 事件的 Pos（relaylog）的值（此事件的起点）为终点
4、截取丢失的数据
mysqlbinlog --start-position=626 --stop-position=1299 db01-relay-bin.000002 >/tmp/relay.sql
vim /tmp/relay.sql #人工检查，看看是否包含 drop database 等危险操做
5、恢复 relay 到从库
mysql>set sql_log_bin=0;
mysql>source /tmp/relay.sql
GTID复制
GTID是对于一个提交事务的唯一编号，并且是一个全局（主从复制）唯一的编号。
GTID配置文件里的参数：
gtid-mode=on
enforce-gtid-consistency=true
log-slave-upadtes=1 #强制刷新GTID的binlog日志，在高并发，高可用中比加参数
gtid-mode=on #启用gtid 类型，否则就是普通的复制架构
enforce-gtid-consistency=true #强制GTID的一致性
log-slave-upadtes=1
GTID 复制与普通复制的区别
非gtid: 手动寻找位置起点信息
gtid: MASTER_AUTO_POSITION=1； #自动寻找位置起点信息
0、主库发生过的事务，在全局时由唯一 GTID 记录
1、change master to 的时候不再需要 binlog 文件名和 position号，MASTER_AUTO_POSITION=1；
2、在复制过程中，从库不再依赖 master.info 文件，而是直接读取最后一个 relaylog 的 GTID 号。
