mysql主从延迟设置

Mysql (需5.6以上版本)延迟复制配置,通过设置Slave上的MASTER TO MASTER_DELAY参数实现:

CHANGE MASTER TO MASTER_DELAY = N;

N为多少秒,该语句设置从数据库延时N秒后,再与主数据库进行数据同步复制

具体操作:

登陆到Slave数据库服务器

mysql>stop slave;

mysql>CHANGE MASTER TO MASTER_DELAY = 600;

mysql>start slave;

mysql>show slave status \G;

查看SQL_Delay的值为600,表示设置成功。

注释:

SQL_Delay:一个非负整数,表示秒数,Slave滞后多少秒于master。

SQL_Remaining_Delay:当 Slave_SQL_Running_State 等待,直到MASTER_DELAY秒后,Master执行的事件,

此字段包含一个整数,表示有多少秒左右的延迟。在其他时候,这个字段是NULL。

参考:Mysql官网(http://dev.mysql.com/doc/refman/5.6/en/replication-delayed.html)

时间: 2024-10-13 02:49:02

mysql主从延迟设置的相关文章

MySQL主从延迟复制实践及生产故障案例恢复实践

1.1 MySQL主从延迟复制介绍 从MySQL5.6开始支持了主从延迟复制,这个功能主要解决的问题是,当主库有逻辑的数据删除或错误更新后,所有的从库都会进行错误的更新,从而导致所有的数据库数据异常,即使有定时的备份数据可以用于数据恢复,特别是数据库数据量很大时,恢复时间会很长,再恢复期间数据库数据被删或错误数据影响正常的访问体验. 而延迟复制就可以较好的解决这个问题.例如,可以设定某一个从库和主库的更新延迟1小时,这样主库数据出问题以后,1个小时以内发现,可以对这个从库进行无害恢复处理,使之依

MySQL 主从数据库设置

1.复制的介绍 MySQL 支持单向.异步复制,复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引 以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置. 从服务器接收从那时起发生的任何更新,然后封锁并等待主服务器通知新的更新. 请注意当你进行复制时,所有对复制中的表的更新必须在主服务器上进行.否则,你必须要小心,以避免用户对主服务器

实时刷新缓存-处理mysql主从延迟的一些设计方案

概要: 在项目开发当中,经常有这样一种场景,对数据库进行添加.修改.删除操作的应用直接连接master库,只对数据库进行查询的应用,会先建立一个中央缓 存,例如redis或者memcache,如果缓存没有命中,那么直接访问slave库.下文会介绍一下在刷新中央缓存时,如果发生主从延迟,应该如何处 理.也即是,当应用System-A 把数据库写入master库的时候,System-B应用在读取slave库的时候,master库的数据还没同步到slave库,如果这个时候刷新缓存 的话,会直接把旧的数

MySQL 主从延迟复制方法总结

mysql 5.6开始已经支持主从延迟复制,可设置从库延迟的时间.延迟复制的意义在于:主库误删除对象时,在从库可以查询对象没改变前状态. 方法介绍 1.percona公司pt-slave-delay工具 主库: [[email protected] ~]$ login Logging to file '/tmp/master.log' Warning: Using a password on the command line interface can be insecure. Welcome

MySQL 主从延迟几万秒 Queueing master event to the relay log(转)

数据库版本Server version:    5.6.24-log Source distribution 问题描述 数据采集平台业务数据库由于批量灌数据导致主从延迟上万秒. 复制线程长期处于Queueing master event to the relay log状态. 监控数据显示1.Seconds_Behind_Master 维持在6w秒左右,且有上升趋势.2.主库有大量的binlog积压无法同步到从库,但主从库的网卡流量都很低远未达到瓶颈.3.从库的qps与tps很低,维持在几百左右

MySQL主从延迟现象及原理分析详解

一.现象 凌晨对线上一张表添加索引,表数据量太大(1亿+数据,数据量50G以上),造成主从延迟几个小时,各个依赖从库的系统无法查询数据,最终影响业务. 现在就梳理下主从延迟的原理. 二.原理 根据 MySQL 官方文档 MySQL Replication Implementation Details 中的描述,MySQL 主从复制依赖于三个线程:一个线程(),两个线程(和).主从复制流程如下图: master 服务器和 slave 服务器连接时,创建以发送数据: 一个对应一个 slave 服务器

MySQL主从延迟原因以及解决方案

1.MySQL数据库主从同步延迟原理. 谈到MySQL数据库主从同步延迟原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作(mysql5.6版本之前),主库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高:slave的Slave_IO_Running线程会到主库取日志,效率会比较高,slave的Slave_SQL_Running线程将主库的DDL和DML操作都在slave实施.DML和DDL的IO操作是随机的,不是顺序的,因此成本会很高,还

mysql主从同步设置

1.主服务器地址:192.168.1.244    从服务器地址:192.168.1.245 2.主服务器master设置 1)修改/etc/my.cnf 添加: log-bin = /home/mysql/log/mysql-bin.log server-id=244 (注:主从server id不可重复,建议以IP地址设置) 2)登录mysql 创建用户sync并授权192.168.1.245 mysql> GRANT REPLICATION SLAVE ON *.* to 'sync'@'

MySQL 主从延迟监控脚本(pt-heartbeat)

对于MySQL数据库主从复制延迟的监控,我们可以借助percona的有力武器pt-heartbeat来实现.pt-heartbeat通过使用时间戳方式在主库上更新特定表,然后在从库上读取被更新的时间戳然后与本地系统时间对比来得出其延迟.本文主要是通过脚本来定期检查从库与主库复制的延迟度并发送邮件,供大家参考. 有关pt-heartbeat工具的安装可以参考:percona-toolkit的安装及简介    有关pt-heartbeat工具的介绍可以参考:使用pt-heartbeat监控主从复制延