上次课总结：
1.双主结构，都可以写？ 不推荐。
常用架构，一主3从，3从带3从从。所以一主12从。
2.主从延时：
主库：
dump串行操作问题。
5.6+ 开启了GTID，并发传输多个事件。
大事务和锁是我们额外关注的。
从库：
SQL并发回放的问题。
5.7+ ，logical_clock 逻辑时钟
大事务和锁是需要我们额外关注的。
主从复制高级进阶
1.特殊从库的应用
1.1.1延时从库
普通的主从复制，处理物理故障损坏比较擅长。
如果主库出现了DROP DATABASE操作？
延时从库：主库做了某项操作之后，从库延时多长时间回放（SQL）
可以处理逻辑损坏。
1.1.2 配置
mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)
mysql> change master to master_delay=300;
Query OK, 0 rows affected (0.01 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status\G
SQL_Delay: 300
SQL_Remaining_Delay: NULL
1.1.3 故障模拟及恢复
#模拟数据
create database ys charset=utf8mb4;
use ys;
create table t1(id int);
begin;
insert into t1 values(1),(2),(3),(4);
commit;
begin;
insert into t1 values(11),(22),(33),(44);
commit;
drop database ys;
# 恢复思路
1.先停业务，挂维护页。
2.停从库的SQL线程。
stop slave sql_thread;
查看realy-log.info --->位置点信息
stop slave;
3.追加后去缺失部分的日志到从库(手工模拟sql线程工作)
日志在哪儿存？ ralay-log
范围： ys: relay-log.info 位置点 ------> drop
4.恢复业务方案
1.ys 导出 恢复到 主库
2.推荐方法 ：直接将从库直接承担当主库。
#恢复
1.从库：stop slave sql_thread;
2.截取relaylog
起点：
Relay_Log_File: later02-relay-bin.000002
Relay_Log_Pos: 320
320
终点：mysql> show relaylog events in 'later02-relay-bin.000002';
| later02-relay-bin.000002 | 1240 | Query | 7 | 1200 | drop database ys |
1240
mysqlbinlog --start-position=320 --stop-position=1240 /data/3306/later02-relay-bin.000002 >/tmp/relay.sql
3.从库恢复
set sql_log_bin = 0;
source /tmp/relay.sql
set sql_log_bin=1;
1.2过滤复制
a.在主库不记录某一个库的binlog日志
b.再从库接收某一个库的日志，但是不执行,不回放.（推荐）。
a.主库的配置方法
主库：show master status;
白名单：
binlog_do_db= lb
黑名单：
Binlog_Ignore_DB
从库：(生产中主要是用库级别)
Replicate_Do_DB= lb 库级别白名单
Replicate_Ignore_DB=test 库级别黑名单
Replicate_Do_Table=lb.t1 表级别白名单
Replicate_Ignore_Table=test.t1 表级别黑名单
Replicate_Wild_Do_Table=lb.t* 模糊的 lb库t开头的所有表
Replicate_Wild_Ignore_Table:
在从库 /etc/my.cnf 配置文件中设置
replicate_do_db= lb
replicate_do_db= test
多个库的写法
重启从库 ，查看状态
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 39.101.199.159
Master_User: repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 2281
Relay_Log_File: later02-relay-bin.000004
Relay_Log_Pos: 862
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: lb
这时在主库进行lb库以外的库操作，从库io线程会继续写入主库
送过来的日志，但是不会写入库中。只有主库lb库的操作才会复制到从库
的lb库中。
1.3 半同步复制
Classic replication:
传统异步非GTID复制工作模型下，会导致主从数据不一致的情况。
5.5版本为了保证主从数据的一致性问题，加入了半同步复制的组件（插件）
在主从结构中，都加入了半同步复制的插件，控制从库IO是否将relaylog落盘，
一旦落盘通过插件返回ACK给主库ACK_rec,主库的事务才能提交成功，在默认情况下，如果超过10秒没有返回ACK，此次复制行为会切换为异步复制。
在5.6 5.7中也加入了一些比较好的特性（after commit sync），也不能保证数据100%的数据一致。
如果生成业务比较关注主从最终一致，我们推荐可以使用MGR的架构，或者
PXC等一致性架构。
