10、主从复制高级进阶-延时从库、过滤复制、半同步复制、GTID
1 延时从库
1.1 延时从库介绍
普通的主从复制，处理物理故障损坏比较擅长，例如磁盘损坏，误操作rm等。如果主库出现了drop database类的逻辑误损坏，无法避免。
延时从库：主库做了某项操作之后，从库延时一定时间回放（SQL线程延时操作，IO线程正常工作），可以处理逻辑损坏。
1.2 延时从库配置方法
mysql> stop slave;
mysql> change master to master_delay = 300; //建议配置为3-6个小时
mysql> start slave;
mysql> show slave status \G;
...
SQL_Delay: 300
SQL_Remaining_Delay: NULL
...
1.3 延时从库逻辑损坏故障恢复
1.3.1 故障场景
主库误删除ys库，延时从库配置SQL线程延时300秒。发现主库误操作后，从库立刻停止sql_thread线程，并使用relay-log，将从库恢复到主库误删除之前的情况，业务由主库切换至从库，完成故障恢复。
1.3.2 从库配置延时
mysql> stop slave;
mysql> change master to master_delay = 300; //建议配置为3-6个小时
mysql> start slave;
1.3.3 主库建ys库，并误删模拟
create database ys charset utf8mb4;
use ys;
create table t1(id int);
insert into t1 VALUES(1),(2),(3),(4);
commit;
insert into t1 VALUES(11),(22),(33),(44);
commit;
drop database ys;
1.3.4 从库恢复步骤
- 停业务，挂维护页
- 停从库SQL线程
stop slave sql_thread;
- 查看目前从库执行到的relay-log位置点，确定后续dump relay-log的
起点
show slave status \G;
#目前执行到的relay-log是Dell-Inspiron-relay-bin.000006，位置点是320
[(none)]>show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
...
Relay_Log_File: Dell-Inspiron-relay-bin.000006
Relay_Log_Pos: 320
...
- 确定误操作前，relay-log的
终点位置
show relaylog events in "Dell-Inspiron-relay-bin.000006";
relay-log中同时有relay-log的position和主库binlog的position，只需关注relay-log的位置点，本例的position是1240。
- 截取relay-log
mysqlbinlog --start-position=320 --stop-position=1240 /data/3307/data/Dell-Inspiron-relay-bin.000006 > /tmp/relay.sql
- 从库恢复误删的数据
set sql_log_bin=0;
source /tmp/relay.sql;
set sql_log_bin=1;
2 过滤复制
主从同步时，从库只同步部分库或表，而不是全量同步。
有两种实现方法：
- 主库只将部分库的日志写入binlog，不推荐
-
从库接收全量的relay-log，sql线程只回放部分库的日志，推荐这种方法！
2.1 方法1：主库只将部分库的日志写入binlog
my.cnf文件中配置库的白名单或黑名单，多个库需要写多行。配置后需要重启数据库。
#白名单
binlog_do_db=库1
binlog_do_db=库2
#黑名单
binlog_ignore_db=库1
binlog_ignore_db=库2
2.2 方法2：从库接配置sql线程部分回放
my.cnf文件中配置库或表的白名单或黑名单，多个需要写多行。一般库和表只配置一种，配置库级别较多。配置后需要重启数据库。
#库白名单
replicate_do_db=database1
#库黑名单
replicate_ignore_db=database1
#表白名单
replicate_do_table=database1.t1
#表黑名单
replicate_ignore_table=database1.t1
#表模糊白名单
replicate_wild_do_table=database1.t*
#表模糊黑名单
replicate_wild_ignore_table=database1.t*
2.2.1 配置示例
从库配置
replicate_do_db=test1
主库有两个测试库test1，test2
从库只同步了test1
比对主从log的同步情况，发现主库的binlog从库已完全接收
主库信息
从库已完成全部log接收
3 半同步复制
传统复制的问题：
传统异步非GTID复制的工作模式下，IO线程接收binlog，日志放在缓存中就会返回ACK给主库，此时relay-log没有落盘，故障时会出现主从数据不一致的情况
半同步复制：
在主从结构中，主从库同时加入半同步复制插件，插件控制从库IO是否将relay-log落盘。一旦落盘，通过插件返回ACK给主库的ACK_reciver。接收到ACK之后，主库的事务才能commit提交成功。默认情况下，如果超过10秒没有返回ACK，半同步复制会切换为原始的异步复制。
半同步复制很少使用，因为就算在5.6和5.7版本中加入了比较好的特性，也不能完全保证100%的数据一致。
如果比较关注主从最终一致（金融类），可以考虑MGR或者PXC等一致性架构。
4 GTID复制
5.6版本出现，没有默认开启。5.7版本默认开启匿名GTID记录。
作用：DUMP线程可以并行传输，SQL线程可以并行回放。5.7.17+版本以后几乎都是GTID模式。
4.1 GTID复制配置
主从的my.cnf配置文件中，添加如下配置
[mysqld]
...
enforce-gtid-consistency=true
autocommit=0
log-slave-updates=1
#前2条为普通开启GTID的配置，最后1条为主从GTID保持一致的配置
从库配置change master to时，进行如下配置
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_AUTO_POSITION=1;
start slave;
4.2 基于GTID检查同步状态
主库show master status;
从库
show slave status \G;
#已经接收到的日志的GTID号
Retrieved_Gtid_Set: 2d794f06-7ffa-11eb-b5e7-000c2951bbce:1-2
#已经回放到的GTID号
Executed_Gtid_Set: 2d794f06-7ffa-11eb-b5e7-000c2951bbce:1-2
4.3 GTID_PURGED参数
第一次开启主从并设置MASTER_AUTO_POSITION=1时，IO线程不再依赖master.info文件，而是直接读取最后一个relaylog的GTID号，并参考额外的gitd_purged信息。用于确定向主库请求的GTID起点。
GTID_PURGED作用：mysqldump备份时，默认SET_GTID_PURGED=AUTO会将备份中包含的事务操作，以以下方式SET@@GLOBAL.GTID_PURGED='8c49d7ec-7e78-11e8-9638-000c29ca725d:1';告诉从库，我的备份中已经有以上事务，IO线程请求日志时，会略过GTID_PURGED的事务，从下一个GTID开始。
5 性能架构
高可用：
MHA
读多写少：读写分离方案
Altas、ProxySQL、Maxscale、Mycat
读多写多：分布式方案
Mycat（DBLE）、Altas-sharing
