mysql主从失败使用bin-log恢复

主从失败的时候先查看从数据库show slave status\G

记住bin-log的pos和binlog文件(一般选择最近的pos的上一个点来进行恢复)或者查看mysql的错误日记的时间点,

将mysql-binlog转化为txt，可以查看数据库的每一个操作

mysqlbinlog /路径/mysql-bin.000xxx >txt1.txt

使用change master to master_host=‘xxxx‘,master_user=‘mysync‘,master_password=‘q123456‘,
master_log_file=‘mysql-bin.xxx‘,master_log_pos=xxx;

关键在与能否找到mysql主库的没有同步的pos和pos所在的bin-log文件

时间： 2024-10-28 21:49:49

mysql主从失败使用bin-log恢复的相关文章

mysql主从同步异常原因及恢复syncnavigator

mysql数据库做主从复制,不仅可以为数据库的数据做实时备份,保证数据的完整性,还能做为读写分离,提升数据库的整体性能.但是,mysql主从复制经常会因为某些原因使主从数据同步出现异常.因此,下面介绍的是mysql主从同步异常的原因及恢复的方法. 这个问题是在部署主从复制的时候,可能会遇到的回到顶部 Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL s

MySQL主从失败错误Got fatal error 1236解决方法

由于mysql主服务器异外重启, 导致slave maysql server报错, 错误如下:查看从伺服器错误:mysql> show slave status\G;Master_Log_File: mysql-bin.000288Read_Master_Log_Pos: 627806304Relay_Log_File: mysql-relay-bin.000990Relay_Log_Pos: 627806457Relay_Master_Log_File: mysql-bin.000288Sla

mysql主从同步常见异常及恢复方法

1. 一般的异常只需要跳过一步即可恢复 >slave stop; >SET GLOBAL sql_slave_skip_counter = 1; >slave start; 2.断电导致主从不能同步时,通主库的最后一个bin-log日志进行恢复在主库服务器上,mysqlbinlog mysql-bin.xxxx > binxxxx.txt tail -n 100000 binxxxx.txt > tail-binxxxx.txt vim tail-binxxxx.txt

MySQL主从失败报错误： Got fatal error 1236

一.问题原因及报错误信息由于MySQL主库意外重启,导致从库无法同步报错如下: 登录从库查看主从同步的错误信息 [[email protected]192-168-7-101 mysql]# vim mysqld-error.log 2018-12-11 12:57:35 1788 [ERROR] Error reading packet from server: Client requested master to start replication from position > file

2015-09-16 mysql 主从原理、同步常见异常及恢复方法

1.原理 MySQL复制技术有以下一些特点: (1) 数据分布 (Data distribution ) (2) 负载平衡(load balancing) (3) 备份(Backups) (4) 高可用性和容错行 High availability and failover 整体上来说,复制有3个步骤: (1) master将改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件,

监控mysql主从脚本

一.下载并解压sendEmail cd /usr/local/src wget tar -zxvf sendEmail-v1.56.tar.gz cp sendEmail-v1.56/sendEmail /usr/local/bin/ 拷贝之后就能用了发邮件命令: sendEmail [email protected] -t [email protected] -s smtp.163.com -u "test"-xu zhang_peicheng -xp xxxxxxxxxx

slave断电，mysql主从奔溃恢复从服务至正常

本想连照片一起上传的,这样更直观:很遗憾照片无法上传,但是也无法阻止我发文!!! slave上操作: [[email protected] mysql]# tail slave.err 160121 21:44:43 [Note] Event Scheduler: Purging the queue. 0 events 160121 21:44:43 [Note] Error reading relay log event: slave SQL thread was killed 160121

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

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

Mysql主从架构-主库宕机如何恢复业务

在我们日常工作场景,首先要做到架构无单点隐患,其次在优化[安全.性能.高可用.高并发等],Mysql这款关系型数据库稳定.高效,所以使用广泛,如果企业架构是1主多从,那如果Mysql主库宕机,如何解决? ----MySQL 主从同步原理图一.Mysql主库宕机情况分类: 1)硬件问题,(服务器.ecs.虚拟主机等等)宕机 2)service问题,Mysql宕机,服务异常,端口异常等二.硬件问题处理思路硬件问题我们可以查看IDC巡检记录,或通过远程控制卡查看硬件运行状态,根据事实情况就行硬件