延时复制 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集群发生了主备切换后,这些只读节点能否与新的主节点保持
1809 0
|
3月前
|
关系型数据库 数据库 PostgreSQL
[postgres]配置主从异步流复制
[postgres]配置主从异步流复制
|
关系型数据库 数据库 MySQL
|
监控 关系型数据库 MySQL
请不要用SECONDS_BEHIND_MASTER来衡量MYSQL主备的延迟时间
MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是今天碰到了一个场景,发现 Seconds_Behind_Master 为 0 , 备库的 show slave status 显示 IO/SQL 线程都是正常的 , MySQL 的主库上的变更却长时间无法同步到备库上。
1978 0
|
SQL 关系型数据库 MySQL
第28节 从库Seconds_Behind_Master延迟总结
从库Seconds_Behind_Master延迟总结 到这里本系列已经接近尾声了,是时候对常见引起主从延迟的情形进行一个总结了。我想如果我一开始就把这些情形拿出来也许大家对具体的原因不是那么清楚,但是经过本系列的学习,我相信当我说起这些情形的时候大家都很清楚它的原因了。
987 0
|
SQL 关系型数据库
slave复制中断 ,别滥用SQL_SLAVE_SKIP_COUNTER
slave复制中断 ,别滥用SQL_SLAVE_SKIP_COUNTER 来源:http://blog.chinaunix.net/uid-26364035-id-3588217.html 【问题背景】  1、从库的复制出现中断,如主键冲突;对应的表或者库不存在;基于row复制时,操作的行不存在; 常常大家会通过使用set global SQL_SLAVE_SKIP_COUNTER=n 来跳过导致复制错误的SQL.  2、 使用sql_slave_skip_counter跳过,每一次跳过为一个Binlog event group, 也就相当于一个事务。
1790 0