MySQL延时从库使用思路
一、延时从库介绍
是我们认为配置的一种特殊从库
人为配置从库和主库延时N小时
二、为什么要有延时从库
数据库故障?
物理损坏
主从复制非常擅长解决物理损坏.
逻辑损坏
普通主从复制没办法解决逻辑损坏
三、配置延时从库
SQL线程延时:数据已经写入relaylog中了,SQL线程"慢点"运行
一般企业建议3-6小时,具体看公司运维人员对于故障的反应时间
tzh>stop slave;
tzh>CHANGE MASTER TO MASTER_DELAY = 300; #单位秒，测试设置成5分钟
tzh>start slave;
tzh> show slave status\G
SQL_Delay: 300 #查看延时从库的时间
SQL_Remaining_Delay: NULL
四、模拟故障，恢复数据
4.1、故障恢复思路
1主1从,从库延时5分钟,主库误删除1个库
1. 5分钟之内 侦测到误删除操作
2. 停从库SQL线程
3. 截取relaylog
起点 :停止SQL线程时,relay最后应用位置
终点:误删除之前的position(GTID)
4. 恢复截取的日志到从库
5. 从库身份解除,替代主库工作
4.2、故障模拟及恢复
1.主库数据操作（主库操作）
create database relay charset utf8;
use relay
create table t1 (id int);
insert into t1 values(1);
drop database relay;
2. 停止从库SQL线程（从库操作）
stop slave sql_thread;
3. 找relaylog的截取起点和终点
起点:
[root@slave1 mysql]# cat relay-log.info #或者连到从库show slave status;查看也行
7
./slave1-relay-bin.000002
320
终点: 找到drop database relay 这两行
show relaylog events in 'slave1-relay-bin.000002'; #类似查看binlog的那个命令，查看当前真正使用的relay日志文件即可
| Log_name | Pos | | End_log_pos（binlog对应位置，不用理会） | Info
| slave1-relay-bin.000002 | 980（终点） | 679876 | drop database relay
mysqlbinlog --start-position=320 --stop-position=980 /data/mysql/slave1-relay-bin.000002>/tmp/relay.sql
4. 从库恢复relaylog
set global read_only=0;
set sql_log_bin=0;
source /tmp/relay.sql
set sql_log_bin=1;
set global read_only=1;
5. 从库身份解除
stop slave;
reset slave all
