1、介绍

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

2、为什么要有延时从库

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

    3、配置延时从库

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

停止主从同步

mysql>stop slave;

设置延时从库, 时间: (秒)

mysql>CHANGE MASTER TO MASTER_DELAY = 300;

启动主从同步

mysql>start slave;

查看延时状态

mysql> show slave status \G SQL_Delay: 300 SQL_Remaining_Delay: NULL

  1. <a name="JVKEn"></a>
  2. # 4、故障模拟及恢复
  3. 主库发生了逻辑损坏 (DROP、truncate)时，可以使用延时从库快速恢复数据
  4. <a name="MRcoq"></a>
  5. #### 环境

主从复制, 2小时延迟从库, 10:00 drop database relay;

<a name="S5UDT"></a>
#### 思路
  1. 及时监控故障: 主库 10:05发现故障, 从库此时8:05数据状态
  2. 立即将从库的SQL线程关闭, 需要对relay库 业务挂维护页
  3. 停止所有同步线程 (sql_thred、IO_thred)
  4. 在延时从库: 恢复到误删除之前的数据 手工模拟SQL线程工作, 直到drop之前位置点。 SQL线程上次执行到的位置 到 drop之前 relay.info —> 分析drop位置点 —> 截取relaylog日志 —> source
    <a name="XCkpw"></a>
#### 故障模拟
    create database delaydb charset utf8mb4; use delaydb; create table t1(id int); insert into t1 values(1),(2),(3); commit;

drop database delaydb;

<a name="T6qBl"></a>
#### 处理故障恢复
  1. 截取日志 起点: show slave status\G Relay_Log_File: centos7-relay-bin.000006 Relay_Log_Pos: 324

终点: mysql -e “show relaylog events in ‘centos7-relay-bin.000006’;” | grep -B 10 “drop database relay”

  1. 导出, 传输到主库 mysqlbinlog —start-position=342 —stop-position=1068 /data/3317/data/centos7-relay-bin.000006 > /tmp/relay.sql

  2. 导入主库 mysql> reset slave all; mysql> set sql_log_bin=0; mysql> source /tmp/relay.sql; mysql> set sql_log_bin=1; ```