mysql主从同步延迟 重建从库步骤

总结

1 从主库上导出数据,用来重建从库使用

mysqldump --user=root --all-databases --flush-privileges --single-transaction

--master-data=1 --flush-logs --triggers --routines --events --hex-blob >20190116master.sql

2 从库 停止主从状态 stop slave;

3 从库导入数据20190116master.sql

4 更改从库状态

CHANGE MASTER TO

MASTER_LOG_FILE=‘mysql-bin.000009‘,

MASTER_LOG_POS= 120;

5 启动从库状态 start slave;

6 查看从库状态 show slave status \G;

原文地址:https://www.cnblogs.com/daizhengyang/p/10270983.html

时间: 2024-10-18 05:23:23

mysql主从同步延迟 重建从库步骤的相关文章

MySQL主从同步延迟717秒?!!

原标题:MySQL主从同步延迟717秒?!! 最近业务MySQL主从监控刚加好,随后总收到延迟几百秒的告警,但实际排查下来却没有大碍,告警信息如下: 网上找下来也有人遇到同样的问题,(但这个问题属于MySQL的BUG还是zabbix的BUG呢?..) 分析的很有深度,原理透彻,这里分享给大家 MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是 今天碰到了一个场景,发现 Seconds_Behind_Ma

MySQL主从同步、读写分离配置步骤

现在使用的两台服务器已经安装了MySQL,全是rpm包装的,能正常使用. 为了避免不必要的麻烦,主从服务器MySQL版本尽量保持一致; 环境:192.168.0.1 (Master) 192.168.0.2 (Slave) MySQL Version:Ver 14.14 Distrib 5.1.48, for pc-linux-gnu (i686) using readline 5.1 1.登录Master服务器,修改my.cnf,添加如下内容: server-id = 1 //数据库ID号,

MySQL主从同步、读写分离配置步骤、问题解决笔记

根据要求配置MySQL主从备份.读写分离,结合网上的文档,对搭建的步骤和出现的问题以及解决的过程做了如下笔记:       现在使用的两台服务器已经安装了MySQL,全是rpm包装的,能正常使用.       为了避免不必要的麻烦,主从服务器MySQL版本尽量保持一致; 环境:192.168.0.1 (Master)           192.168.0.2 (Slave) MySQL Version:Ver 14.14 Distrib 5.1.48, for pc-linux-gnu (i6

Mysql主从同步延迟与系统时间的关系

Mysql主从同步延迟受到多种因素影响, 比如大事务, 从库查询压力, 网路延迟等: 这些比较常见: 但还受到主从机器系统时钟差的影响,这一点可能容易被忽视.上周, 就遇到了这样的情况, 主库的系统时间由于某种原因落后于从库几十秒, 结果频繁的出现大的主从延迟同步 ,查了N久业务方面的问题,都找不出原因: 在和同事的交流中,发现大家对参数Seconds_Behind_Master的理解有点补一样,基本有两种理解: 一种理解是来源于 Mysql手册上的描述,大体意思是这个时间是从库线程处理的最近的

pt-heartbeat监测mysql主从同步延迟

pt-heartbeat监测mysql主从同步延迟: 安装percona toolkit(pt-heartbeat为该软件的子命令): http://repo.percona.com/release/6/RPMS/x86_64/percona-toolkit-3.0.13-1.el6.x86_64.rpm yum install perl-DBD-MySQL yum install perl-IO-Socket-SSL yum install perl-TermReadKey 在主库上创建hea

MySQL主从同步延迟原因及解决办法

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主从同步延迟zabbix怎么监控

这个涉及到zabbix自定义监控项与MySQL主从同步两个技术,首先确保MySQL主从同步的前提下,在从库show slave status\G中找到"Seconds_Behind_Master"参数,改参数表示从库与主库同步的延迟间隔:然后在被监控端的zabbix-agent配置文件中添加"UserParameter=db_status,mysql -uzabbix -pzabbixpass -e "show slave status\G" 2>/

使用MySQL Proxy解决MySQL主从同步延迟

MySQL的主从同步机制非常方便的解决了高并发读的应用需求,给Web方面开发带来了极大的便利.但这种方式有个比较大的缺陷在于MySQL的同步机制 是依赖Slave主动向Master发请求来获取数据的,而且由于服务器负载.网络拥堵等方面的原因,Master与Slave 之间的数据同步延迟是完全没有保证的.短在1秒内,长则几秒.几十秒甚至更长都有可能. 由于数据延迟问题的存在,当应用程序在Master 上进行数据更新,然后又立刻需要从数据库中读取数据时,这时候如果应用程序从Slave上取数据(这也是

mysql主从同步延迟原因及解决方法

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