MySQL延时从库使用思路

MySQL延时从库使用思路

一、延时从库介绍

是我们认为配置的一种特殊从库
人为配置从库和主库延时N小时

二、为什么要有延时从库

数据库故障?
物理损坏
主从复制非常擅长解决物理损坏.
逻辑损坏
普通主从复制没办法解决逻辑损坏

三、配置延时从库

SQL线程延时:数据已经写入relaylog中了,SQL线程"慢点"运行
一般企业建议3-6小时,具体看公司运维人员对于故障的反应时间

tzh>stop slave;
tzh>CHANGE MASTER TO MASTER_DELAY = 300;   #单位秒，测试设置成5分钟
tzh>start slave;
tzh> show slave statusG
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