延时复制 delayed replication

简介: mysql5.6开始支持延时复制,默认master_delay为0秒,CHANGE MASTER TO MASTER_DELAY = N;表示延时N秒原理:延时复制的本质是sql_thread需要等待延时时间之后才能执行。

mysql5.6开始支持延时复制,默认master_delay为0秒,

CHANGE MASTER TO MASTER_DELAY = N;

表示延时N秒

原理:延时复制的本质是sql_thread需要等待延时时间之后才能执行。


延时复制适用场景:

(1)防止主库误操作,在复制同步之前,可以停止同步;

(2)用作测试,不用模拟负载就可以实现主从延迟;

(3)用来检查数据库以前的数据,如延迟设置为1周,这样不需要备份恢复就可以看到比对一周以前的数据

(4)reset slave会把SQL_delay的值清零,并且还会把Master_Log_File等值清空,但是不影响复制;



创建一个延时复制:
slave:
root@localhost [testdb]>stop slave;
root@localhost [testdb]>change master to master_delay=60;
root@localhost [testdb]>start slave;

root@localhost [testdb]>show slave status\G
......
                    SQL_Delay: 60  --延时时间
          SQL_Remaining_Delay: 56           --剩余时间
      Slave_SQL_Running_State: Waiting until MASTER_DELAY seconds after master executed event   --等待延时
......
master:
root@localhost [testdb]>delete from t1 where c1=4;

slave:
root@localhost [testdb]>select * from t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | aaa  |
|  2 | bbb  |
|  3 | ccc  |
|  4 | ddd  |
+----+------+

root@localhost [testdb]>show processlist;
+----+-------------+-----------+--------+---------+------+----------------------------------------------------------------+------------------+
| Id | User        | Host      | db     | Command | Time | State                                                          | Info             |
+----+-------------+-----------+--------+---------+------+----------------------------------------------------------------+------------------+
| 26 | root        | localhost | testdb | Query   |    0 | starting                                                       | show processlist |
| 27 | system user |           | NULL   | Connect |  345 | Waiting for master to send event                               | NULL             |
| 28 | system user |           | NULL   | Connect |   10 | Waiting until MASTER_DELAY seconds after master executed event | NULL             |
+----+-------------+-----------+--------+---------+------+----------------------------------------------------------------+------------------+

#在没有达到60秒之前查看relay-log日志,发现已经写入relay-lo中,说明延时是阻塞SQL_thread线程
[root@Darren1 data]# mysqlbinlog -vv --base64-output=decode-rows relay-bin.000003
BEGIN
/*!*/;
# at 452
#170409 22:12:27 server id 330622  end_log_pos 5624 CRC32 0x86f7edf4    Table_map: `testdb`.`t1` mapped to number 147
# at 502
#170409 22:12:27 server id 330622  end_log_pos 5668 CRC32 0x697c52ed    Delete_rows: table id 147 flags: STMT_END_F
### DELETE FROM `testdb`.`t1`
### WHERE
###   @1=3 /* INT meta=0 nullable=0 is_null=0 */
###   @2='ccc' /* VARSTRING(30) meta=30 nullable=1 is_null=0 */

root@localhost [testdb]>select * from t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | aaa  |
|  2 | bbb  |
|  3 | ccc  |
+----+------+


目录
相关文章
|
弹性计算 网络协议 容灾
PostgreSQL 时间点恢复(PITR)在异步流复制主从模式下,如何避免主备切换后PITR恢复(备库、容灾节点、只读节点)走错时间线(timeline , history , partial , restore_command , recovery.conf)
标签 PostgreSQL , 恢复 , 时间点恢复 , PITR , restore_command , recovery.conf , partial , history , 任意时间点恢复 , timeline , 时间线 背景 政治正确非常重要,对于数据库来说亦如此,一个基于流复制的HA架构的集群,如果还有一堆只读节点,当HA集群发生了主备切换后,这些只读节点能否与新的主节点保持
1710 0
|
关系型数据库 MySQL 数据库
主从同步设置的重要参数log_slave_updates
说明:最近部署了mysql的集群环境,详细如下M01和M02为主主复制,M01和R01为主从复制;在测试的过程中发现了以下问题: 1、M01和M02的主主复制是没有问题的(从M01写入数据能同步到M02,从M02写入数据能够同步到M01); 2、主从同步的时...
1937 0
|
关系型数据库 数据库 MySQL
|
监控 关系型数据库 MySQL
请不要用SECONDS_BEHIND_MASTER来衡量MYSQL主备的延迟时间
MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是今天碰到了一个场景,发现 Seconds_Behind_Master 为 0 , 备库的 show slave status 显示 IO/SQL 线程都是正常的 , MySQL 的主库上的变更却长时间无法同步到备库上。
1925 0
|
SQL 监控 关系型数据库
mysql主从复制出现Waiting for Slave Worker to release partition
本文分享mysql主从复制出现Waiting for Slave Worker to release partition
mysql主从复制出现Waiting for Slave Worker to release partition
|
SQL 关系型数据库 MySQL
第28节 从库Seconds_Behind_Master延迟总结
从库Seconds_Behind_Master延迟总结 到这里本系列已经接近尾声了,是时候对常见引起主从延迟的情形进行一个总结了。我想如果我一开始就把这些情形拿出来也许大家对具体的原因不是那么清楚,但是经过本系列的学习,我相信当我说起这些情形的时候大家都很清楚它的原因了。
965 0
|
关系型数据库 数据库 PostgreSQL
multi-master - 多主 - 多写 - 如何在多写中避免数据复制打环(死循环)
标签 PostgreSQL , 打环 背景 双写或者多写,除了需要考虑数据冲突的问题,另一个要考虑的就是打环的问题。 为什么会打环呢? DB A <-> DB B 1、A insert into tbl values (1,'test'); 产生redo 同步到B 2、B 接收到同步内容 insert into tbl values (1,'test'); 产生redo 同步到A 3、。
1381 0