MySQL主从之延时复制
短信预约 信息系统项目管理师 报名、考试、查分时间动态提醒
目录
- 一、延时复制
- 1.配置延时复制(已经有主从)
- 2.配置延时复制(没有主从)
- 3.关闭延时从库
- 实例
一、延时复制
延时从库只做备份,不提供任何对外服务,正常情况下我们是不会有刻意延迟从库的需求的,因为正常的线上业务自然是延迟越低越好。
但是针对测试场景,业务上偶尔需要测试延迟场景下业务是否能正常运行。
# 延时复制流程:
和异步复制类似,同样是将主库的binlog日志通过dump线程发送给从库的中继日志中,但是当执行SQL的线程时,
会根据配置的延时复制时长,sql线程等到了延迟时间之后再执行中继日志中的sql语句了。
# 注意:
延时从库恢复数据时不要关闭主库的binlog,实际上从库还是会执行主库执行错的语句,只不过又执行了重建语句
1.配置延时复制(已经有主从)
1.停止主从
mysql> stop slave;
Query OK, 0 rows affected (0.03 sec)
2.配置延时时间
mysql> change master to master_delay=180;
Query OK, 0 rows affected (0.01 sec)
3.开启主从
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
2.配置延时复制(没有主从)
1.搭建出一台mysql
2.配置主从
mysql> change master to
-> master_host=‘172.16.1.51‘,
-> master_user=‘rep‘,
-> master_password=‘123‘,
-> master_log_file=‘mysql-bin.000001‘,
-> master_log_pos=424,
-> master_delay=180;
Query OK, 0 rows affected, 2 warnings (0.02 sec)
3.开启线程
mysql> start slave;
Query OK, 0 rows affected (0.01 sec)
3.关闭延时从库
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)
mysql> change master to master_delay=0;
Query OK, 0 rows affected (0.01 sec)
mysql> start slave;
Query OK, 0 rows affected (0.02 sec)
实例
#关于延时复制如何恢复思考问题:
总数据量级500G,正常备份去恢复需要1.5-2小时
1)配置延时3600秒
mysql>CHANGE MASTER TO MASTER_DELAY = 3600;
2)主库
drop database db;
3)怎么利用延时从库,恢复数据?
提示:
1、从库relaylog存放在datadir目录下
2、mysqlbinlog 可以截取relaylog内容
3、show relay log events in ‘db01-relay-bin.000001‘;
#处理的思路:
1)停止SQL线程
mysql> stop slave sql_thread;
2)截取relaylog到误删除之前点
relay-log.info 获取到上次运行到的位置点,作为恢复起点
分析relay-log的文件内容,获取到误删除之前position
模拟故障处:
1)关闭延时
mysql -S /data/3308/mysql.sock
mysql> stop slave;
mysql> CHANGE MASTER TO MASTER_DELAY = 0;
mysql> start slave;
2)模拟数据
mysql -S /data/3307/mysql.sock
source /root/world.sql
use world;
create table c1 select * from city;
create table c2 select * from city;
3)开启从库延时5分钟
mysql -S /data/3308/mysql.sock
show slave status G
mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY = 300;
mysql>start slave;
mysql -S /data/3307/mysql.sock
use world;
create table c3 select * from city;
create table c4 select * from city;
4)破坏,模拟删库故障。(以下步骤在5分钟内操作完成。)
mysql -S /data/3307/mysql.sock
drop database world;
5)从库,关闭SQL线程
mysql -S /data/3308/mysql.sock
stop slave sql_thread;
6)截取relay-log
起点:
cd /data/3308/data/
cat relay-log.info
./db01-relay-bin.000002
283
终点:
mysql -S /data/3308/mysql.sock
show relaylog events in ‘db01-relay-bin.000002‘
db01-relay-bin.000002 | 268047
mysqlbinlog --start-position=283 --stop-position=268047 /data/3308/data/db01-relay-bin.000002 >/tmp/relay.sql
恢复relay.sql
1)取消从库身份
mysql> stop slave;
mysql> reset slave all;
2)恢复数据
mysql> set sql_log_bin=0;
mysql> source /tmp/relay.sql
mysql> use world
mysql> show tables;
MySQL主从之延时复制
原文地址:https://www.cnblogs.com/tcy1/p/13377994.html
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341