zoukankan      html  css  js  c++  java
  • 三十九、延时从库

    延时从库介绍

    如果主从及时同步,那么主库误删除操作drop database xxx会立刻同步到从库上,这样会造成数据的损失,所以我们需要人为制造延时。

    我们可以在主库做了某项操作后,决定从库延时多长时间回放sql。

    配置过程

    在从库输入如下命令,延时5分钟用于测试

    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
    

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

    延时从库的恢复思路

    1、监控到主库发生误删除等操作,停止业务,挂维护页
    2、停止从库SQL线程,确认日志已同步之后,停止从库进程
    3、记录relaylog起点跟终点,截取relaylog日志,导出数据
    4、恢复数据到从库,导出故障库,恢复到主库中
    5、启动从库进程,查看主从是否同步

    跟截取binlog恢复相比,无需查找确定截取起点。例如如果主库发生了误操作导致库或表被删除,那么要通过查找binlog日志找到初始建库建表的语句作为起点开始截取,这很麻烦,这时使用从库恢复就很方便了。

    故障模拟及恢复

    1、主库创建测试库

    create database delay charset utf8mb4;
    use delay;
    create table t1 (id int);
    insert into t1 values(1),(2),(3);
    commit;
    drop database delay; 
    
    show master status; #记录pos号
    | mysql-bin.000041 |     2606 |
    

    2、先停止从库SQL线程,确认主从日志已同步后,停止从库进程,获取relaylog起始位置点

    mysql> stop slave sql_thread; 
    mysql> show slave status G;
    Read_Master_Log_Pos: 2606 #确定主从已同步日志
    SQL_Delay: 300
    SQL_Remaining_Delay: 224 #sql剩余延迟时间,也就是倒计时结束后会sql线程会回放relaylog
    
    mysql> stop slave;
    mysql> show slave status G
    Relay_Log_File: client2-relay-bin.000002
    Relay_Log_Pos: 320 #确定起点为320
    

    3、截取relay日志

    #确定终点为928
    mysql> show relaylog events in 'client2-relay-bin.000002';
    | client2-relay-bin.000002 | 928 | Gtid           |         6 |        2511 | SET @@SESSION.GTID_NEXT= '3d111a50-9355-11eb-b573-000c29a2912e:12' |
    | client2-relay-bin.000002 | 993 | Query          |         6 |        2606 | drop database delay   |           
    
    $ cd /usr/local/mysql/data/
    $ mysqlbinlog --start-position=320 --stop-position=928 client2-relay-bin.000002 >/backup/relay20210411.sql
    
    #也可使用截取GTID方式备份
    $ mysqlbinlog --skip-gtids --include-gtids='3d111a50-9355-11eb-b573-000c29a2912e:9-11' client2-relay-bin.000002 >/backup/relay20210411.sql
    



    4、恢复relaylog到从库,导出delay库恢复到主库

    $ source /backup/relay20210411.sql
    mysql> show databases; #确认delay库已恢复
    mysql> use delay;
    mysql> show tables;
    mysql> select * from t1;
    
    mysql> mysqldump -B delay -R -E --master-data=2 --single-transaction >/backup/delay20210411.sql
    $ scp /backup/delay20210411.sql root@10.154.0.111:/backup/
    
    mysql> start slave;
    
    
    #登录主库
    mysql> source /backup/delay20210411.sql;
    mysql> show databases; #确认delay库已恢复
    

    注意:主从库数据确认恢复完毕,从库开启复制进程,sql_thread还会从开始起点回放sql,也就是说还会删掉delay库,故恢复时主库不需要设置set sql_log_bin=0;,不然从库会因丢失delay库而导致不能同步。

    学习来自:B站课程:MySQL主从复制延时从库 P134-136

    今天的学习是为了以后的工作更加的轻松!
  • 相关阅读:
    POJ 1141 括号匹配 DP
    881. Boats to Save People
    870. Advantage Shuffle
    874. Walking Robot Simulation
    文件操作
    861. Score After Flipping Matrix
    860. Lemonade Change
    842. Split Array into Fibonacci Sequence
    765. Couples Holding Hands
    763. Partition Labels
  • 原文地址:https://www.cnblogs.com/tz90/p/14642571.html
Copyright © 2011-2022 走看看