展开

关键词

Mysql通过binlog恢复数据

> flush logs; 查看binlog日志,找到需要恢复到的位置 > show binlog events in 'mysql3306-bin.000008'; image-20210615225134682 在3927位置,rumenz表被删除,所以我们找到了恢复数据的结束点 恢复数据 查看前面用到的所有日志文件 > shwo master logs; +----------------------+-- 13:18:54" 起始时间点 --stop-datetime="2021-06-05 13:21:53" 结束时间点 --database=demo 指定只恢复 日志文件,需要全部指定上去 如果只恢复指定数据库,如demo数据库,使用-d demo或-database demo > mysqlbinlog -d demo --stop-position=3927 入门介绍 Mysql之binlog三种模式

10610

通过binlog日志恢复表记录

1 使用binlog日志 1.1 问题 利用binlog恢复库表,要求如下: 启用binlog日志 创建db1库tb1表,插入3条记录 删除tb1表中刚插入的3条记录 使用mysqlbinlog恢复删除的 需要将binlog日志格式修改为STATEMENT .. .. 日志恢复表记录 binlog会记录所有的数据库、表更改操作,所以可在必要的时候重新执行以前做过的一部分数据操作,但对于启用binlog之前已经存在的库、表数据将不适用。 根据上述“恢复被删除的3条表记录”的需求,应通过mysqlbinlog工具查看相关日志文件,找到删除这些表记录的时间点,只要恢复此前的SQL操作(主要是插入那3条记录的操作)即可。 50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/; 2) 执行指定Pos节点范围内的sql命令恢复数据 根据上述日志分析,只要恢复从2014.01.12 20:12:14

8110
  • 广告
    关闭

    90+款云产品免费体验

    提供包括云服务器,云数据库在内的90+款云计算产品。打造一站式的云产品试用服务,助力开发者和企业零门槛上云。

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    binlog server伪装master恢复增量数据

    导读 接上一篇《一种MySQL备份恢复设计思路》,在上一篇文章中我们介绍了如何利用binlog来进行增量恢复,其中提到了用binlog server伪装master来进行增量恢复,那么今天我们来演示一下具体过程 不管怎么样,node1的binlog已经注册上来了。接下来我们将node3作为node2的从库来进行数据恢复。 总结一下 整个过程实际上并不复杂,需要做的主要的就是如下几点: 找到需要恢复的起始GTID位点和终止GTID位点 从binlog server上拉取对应的binlog或者直接在binlog server 上部署一个空实例 注册binlog,这一步比较关键 设置异机恢复实例的gtid_purged,配置主从关系 利用命令start slave until SQL_BEFORE_GTIDS恢复到指定的位点 假如你是5.7以上的版本,甚至可以用到并行加速恢复,缩短整个增量恢复的时间

    22720

    mysql binlog恢复数据实战

    数据库备份 数据库恢复的先决条件是,定时备份数据库,缩小binlog恢复范围.首先我们备份测试数据库数据: mysqldump -uroot -p --database test > testBackSql.sql 数据恢复 在上面的操作中,我们备份了数据为164 id之前的所有数据,插入数据到了367之后被删库.假设我们并不知道id到了367.开始使用binlog分析日志: 首先使用 flush logs; 命令刷新二进制日志 刷新后,新的binlog用于做恢复数据时的记录, 因为当执行备份文件恢复数据和binlog恢复时,都会产生新的binlog,不要和原来的数据进行冲突.   (如果涉及多个binlog,需要执行多个binlog恢复日志) 通过查询binlog,获取到最后恢复点:  /www/server/mysql/bin/mysqlbinlog /www/server/data 将原有备份数据恢复:  cat testBackSql.sql |mysql -uroot -p ? 备份数据已经恢复了,开始恢复二进制数据.

    2.1K10

    MySQL基于Binlog的数据恢复实战

    1、环境状态说明 2、恢复流程说明 2.1 正向恢复 2.2 反向恢复 3、数据准备 3.1 查询当前binlog数据状态 3.2 查找恢复position区间 3.3 position点确认 4、操作恢复 4.1 正向恢复 4.1.1 恢复备份数据 4.1.2 恢复binlog日志 4.1.3 检查数据恢复状态 4.2 反向恢复 4.2.1 安装binlog2sql 4.2.2 生成反转 2、恢复流程说明 按照正反两种方式分别进行测试恢复 2.1 正向恢复 主要思路 通过全量备份恢复当日0:00时间点的数据 通过binlog恢复当日0:00-22:00错误语句之前的全部语句 2.2 反向恢复 主要思路 使用binlog2sql从binlog日志中提取错误语句的反向语句 在当前已经执行了错误语句的数据库执行反向语句,将数据恢复至错误语句执行前的状态 3、数据准备 3.1 查询当前binlog 4.2 反向恢复 反向恢复时通过binlog2sql,将错误执行的update语句反转,再update回来 4.2.1 安装binlog2sql 项目地址: https://github.com/danfengcao

    52930

    Mysql之binlog日志说明及利用binlog日志恢复数据操作记录

    众所周知,binlog日志对于mysql数据库来说是十分重要的。在数据丢失的紧急情况下,我们往往会想到用binlog日志功能进行数据恢复(定时全备份+binlog日志恢复增量数据部分),化险为夷! 这可以根据前面提到的mysql-bin.000003的新binlog日志进行恢复。 8) 从binlog日志恢复数据 恢复命令的语法格式: mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名 -------------------- ----------------- 另外: 也可指定时间节点区间恢复(部分恢复): 除了用pos节点的办法进行恢复,也可以通过指定时间节点区间进行恢复,按时间恢复需要用mysqlbinlog命令读取binlog 总结: 所谓恢复,就是让mysql将保存在binlog日志中指定段落区间的sql语句逐个重新执行一次而已。

    1.3K80

    【MySQL】通过SQL_Thread快速恢复binlog

    将数据库回档至指定时间点或位置,常常是使用全量备份+binlog增量实现的。 而数据量很大的情况下,增量恢复binlog一直是一个苦恼的问题。 因为恢复binlog速度十分慢,并且容易出错。 通过sql_thread恢复 处理思路: 1)重新初始化一个实例,恢复全量备份文件。 2)找到第一个binlog文件的position,和剩下所有的binlogbinlog恢复。 该测试使用的版本为:MySQL 5.7.16 效果: 快速恢复到指定位置点,即通过全备文件+binlog恢复到故障前的最后一个position。 2)性能相对较好,在大量binlog的情况下,可以加快恢复速度。 3)在某些版本可能可以通过MTS来加快增量速度,使恢复更快。 缺点: 1)需要关闭mysqld。

    54651

    使用binlog2sql恢复数据

    对于误操作数据的闪回,我们一般推荐 binlog2sql 或者MyFlash(美团点评开源的) 本篇文章, 我们介绍下 binlog2sql的用法: binlog2sql 【首级推荐使用】 官网:https ://github.com/danfengcao/binlog2sql 注意: binlog必须是row格式,并且是FULL类型的记录。 文件及位移点,然后使用下面命令解析: python /root/binlog2sql/binlog2sql/binlog2sql.py -h192.168.11.20 -P3306 -uflashback *//g' /root/rollback.sql 3 将数据恢复到数据库中: use testdb ; UPDATE `testdb`. Wutong' AND `Age`=100 AND `Gender`='M' AND `ClassID`=3 AND `TeacherID`=1 LIMIT 1; 执行完后,再次看下数据,可以看到已经恢复好了

    27730

    binlog解析出来的日志为何无法恢复

    问题描述 问题来自一位群友,简单说就是用 mysqlbinlog 工具读取 binlog 欲进行恢复,却发现数据并没被恢复。 先一起来看下他是怎么做恢复的。 ,但发现不能正确恢复: $ mysqlbinlog --start-position=4 --stop-position=1512 binlog.000003 | mysql -f yejr 已经指定了读取 之后查询 yejr.t1 表数据还是空的,没有被正确恢复。 在执行 mysqlbinlog 解析binlog并尝试恢复时,观察新的binlog,确认没有写入新数据,说明确实没执行恢复操作。 所以,如果想要从binlog恢复数据,执行mysqlbinlog时,记得加上 --skip-gtids 选项。 全文完。 ----

    26020

    通过MySQL relaylog + SQL_Thread 增量恢复binlog

    而数据量很大的情况下,增量恢复binlog一直是一个苦恼的问题,因为恢复binlog速度十分慢,并且容易出错。 〇 处理思路:     1)重新初始化一个实例,恢复全量备份文件。     2)找到第一个binlog文件的position,和剩下所有的binlog。      +binlog恢复到故障前的最后一个position。 并且在需要增量的binlog文件越大的情况下,效果越明显。 〇 优点:     可以断点恢复,人为控制进度,比如stop slave或者遇到错误时,可以断点恢复。     性能好,在大量binlog的情况下,可以加快恢复速度。     在某些版本可以利用多线程复制来加快增量速度,时恢复更快。 〇 缺点:     需要关闭mysqld。

    76620

    数据恢复binlog2sql--准备工作

    1.确定版本信息和binlog格式 mysql版本:5.7.12 查看binlog格式的命令 mysql> show variables like 'binlog_format'; +--------- 工具 1)解析出标准的SQL python binlog2sql.py -h192.168.1.21 -P30136 -uglon -p'123456' -d xcrm -t edai_binlog2sql -tedai_binlog2sql --start-file=mysql-bin.000001 --start-position=6159262 --stop-pos=6159823 > edai_binlog2sql-new.sql [root@soft binlog2sql]# cat edai_binlog2sql-new.sql INSERT INTO `xcrm`. 6159262 end 6159534 time 2018-11-22 15:15:46 可以看到,我们刚刚的delete语句,被反转为insert语句,update 修改为原来的时间 拿到了具体的恢复语句

    13720

    数据恢复binlog2sql--原理及其使用

    原理及其使用 生产上误删数据、误改数据的现象也是时常发生的现象,作为运维这时候就需要出来补锅了,最开始的做法是恢复备份,然后从中找到需要的数据再进行修复,但是这个时间太长了,对于大表少数数据的修复来讲, 当然还有其他的一些操作方法,binlog2sql使用。 用途 数据回滚 主从切换后数据不一致的修复 从 binlog 生成标准 SQL,带来的衍生功能 闪回原理简析 开始之前,先说说闪回。 binlog 有三种可选的格式: statement:基于 SQL 语句的模式,binlog 数据量小,但是某些语句和函数在复制过程可能导致数据不一致甚至出错; mixed:混合模式,根据语句来选用是 安全,但 binlog 会比其他两种模式大很多; 利用 binlog 做闪回,需要将 binlog 格式设置为 row,因为我们需要最详尽的信息来确定操作之后数据不会出错。 但是,DDL 语句,比如drop,truncate 在整个使用中都是无法被回滚的,这种情况,只能用最近的备份数据+二进制日志恢复 本次实验,更改一条数据,并删除一条数据,然后从解析 binlog 信息,

    22930

    基于binlog二进制日志的MySQL恢复笔记

    基于binlog二进制日志的MySQL恢复笔记 刚好复习到这里,顺手做个小实验,记录下。 ,第10条数据又恢复回来了,但是INSERT的那条数据却没有了,因此我们还要使用二进制日志继续恢复。 step4、继续用二进制日志恢复: mysql -e 'source today.sql;' step5、查看恢复后的结果: 恢复完的效果如下: MariaDB [hellodb]> select * , 误删除的StuID为10的数据也恢复了。 至此,我们的恢复就完成了。

    26230

    Mysql 通过全量备份和binlog恢复整体数据

    某天工作时间,一个二货犯晕登错生产当测试环境了,直接drop了一个数据库,需要紧急恢复!可利用备份的数据文件以及增量的 binlog 文件进行数据恢复。 具体思路归纳几点: 1、恢复条件为 MySQL 要开启 binlog 日志功能,并且要全备和增量的所有数据。 2、恢复时建议对外停止更新,即禁止更新数据库。 (这点很重要) 3、先恢复全量,然后把全备时刻点以后的增量日志,按顺序恢复成 SQL 文件, 4、然后把文件中有问题的SQL语句删除(也可通过时间和位置点),再恢复到数据库。 binlog文件移出,否则恢复过程中,会继续写入语句到 binlog,最终导致增量恢复数据部分变得比较混乱。 Enter password: 再次查看数据库,发现全备份到删除数据库之间的那三条数据也恢复了!!

    2.6K70

    Mysql误删,恢复数据,binlog闪回,宝塔面板

    传统恢复方法是利用备份重搭实例,再应用去除错误sql后的binlog恢复数据。 此法费时费力,甚至需要停机维护,并不适合快速回滚。 也有团队利用LVM快照来缩短恢复时间,但快照的缺点是会影响mysql的性能。 MySQL闪回(flashback)利用binlog直接进行回滚,能快速恢复且不用停机。 本文将简单进行mysql根据binlog闪回数据的实战测试 基础知识准备 binlog是二进制日志文件,用来记录Mysql内部对数据库的改动(只记录对数据的修改操作),主要用于数据库的主从复制以及增量恢复 所以有这种根据binlog得到执行sql语句、闪回sql语句,我们只需要利用根据分析binlog,然后就可以找到准确的数据改动sql,并得到闪回sql,检查无误后执行就可以恢复数据了 准备工作 我们采用 start-file='mysql-bin.000006' -B --start-pos 590075 --stop-pos 590633 就可以得到insert的语句 复制出来,检查无误,就可以执行 恢复数据了

    1.8K20

    数据恢复binlog回放的一个报错问题

    数据恢复binlog回放的一个报错问题 今天早上在线上进行数据恢复的时候,看到了一个报错,发现挺有意思的,就给记录下来了。废话不多说,直接说场景。 01 问题描述 真实的案例如下: 某个数据库在回放binlog的时候,总是回放到一个指定的binlog行数发生报错,报错的信息是: ERROR 2006 (HY000) at line 7610607 根据报错,查看binlog的固定行数的信息,经过查询,发现该位置的binlog里面的内容是一个很大的SQL,SQL内容我这里就不贴出来了,在binlog中,这些内容都被解析成了一些乱码,类似下面这样: BINLOG ' SnlPXg9GjD27dwAAAHsAAAABAAQANS43LjIwLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA mysqldump] quick max_allowed_packet = 512M [mysql] max_allowed_packet = 512M 修改完成之后,重新连接mysql server,重放binlog

    48530

    MySQL通过binlog快速恢复数据

    1.背景 MySQL一旦误删数据库之后恢复数据很麻烦,这里记录一下艰辛的恢复过程。 2.方法 2.1首先在MySQL中查看是否打开bin目录 mysql> show variables like 'log_%'; 这里可以看到log_bin是ON的状态,恢复有望。 2.2显示当前主分支的状态 mysql> show master status; 可以看到binlog文件已经排到17号了 2.3显示mysql-bin.000001文件 mysql> show binlog

    22730

    ROW 格式binlog 在MySQL5.6上的数据恢复实验

    ROW 格式的binlog 在MySQL5.6上的数据恢复实验 5.6和5.7版本的MySQL,有个参数binlog_row_p_w_picpath,默认值为FULL,表示记录的是全部的binlog操作日志 (仅在binlog_format=ROW时候生效)。 此外binlog_row_p_w_picpath还可以是minimal,表示binlog记录的就只是影响后的行。如此一来使用ROW格式就能节约很多的磁盘空间。 因此,我们服务器上就可以直接设置binlog_format=ROW格式了,至于binlog_row_p_w_picpath设置为FULL还是minimal,各位就自行考虑了。 如果数据库多的话,还会增大恢复的难度,如下事例(下面的grant操作实例不够明显,但是差不多就是那个操作步骤): step1  准备一个全量备份: mysqldump --flush-logs -A >

    51640

    【删库跑路】使用Binlog日志恢复误删的MySQL数据

    开个玩笑,今天文章的主题是如何使用Mysql内置的Binlog日志对误删的数据进行恢复,读完本文,你能够了解到: MySQL的binlog日志是什么?通常是用来干什么的? 模拟一次误删数据的操作,并且使用binlog日志恢复误删的数据。 写这篇文章的初衷,是有一次我真的险些把测试数据库的一张表给删除了,当时吓出一身冷汗。 看了上面binlog的定义,大家也应该能大致推理出binlog的三大用途: 恢复数据:今天要说的重点 数据库复制:主从数据库是通过将binlog传给从库,从库有两个线程,一个I/O线程,一个SQL线程, 所以说,想要能够恢复数据,首先,你得打开Mysql的binlog,在平常你自己安装的单机Mysql中,默认情况下不会开启。下面就一步步地实践下如何开启你服务器上的Binlog日志。 当然,看完binlog日志恢复数据的原理,希望大家以后在定期备份数据库的脚本里,也能够加上刷新binlog日志的命令,这样一旦某天丢失数据,可以将当天binlog数据单独拿出来还原,做到清晰可辨,也加快恢复效率

    1.2K20

    使用binlog2sql针对mysql进行数据恢复

    传统恢复方法是利用备份重搭实例,再应用去除错误sql后的binlog恢复数据。此法费时费力,甚至需要停机维护,并不适合快速回滚。 也有团队利用LVM快照来缩短恢复时间,但快照的缺点是会影响mysql的性能。 MySQL闪回(flashback)利用binlog直接进行回滚,能快速恢复且不用停机。 请问多久能恢复数据?”DBA一脸懵逼,沉默十秒后,伸出一根手指。“你的意思是一分钟就能恢复?太好了。”小明终于有些放松,露出了一丝笑容。“不,我们中有个人将会离开公司。”DBA沉痛的说道。 闪回原理 binlog概述 MySQL binlog以event的形式,记录了MySQL server从启用binlog以来所有的变更信息,能够帮助重现这之间的所有变化。 Query OK, 4 rows affected (0.00 sec) 20:28时,tbl表误操作被清空 mysql> select * from tbl; Empty set (0.00 sec) 恢复数据步骤

    36940

    相关产品

    • 云数据库 MySQL

      云数据库 MySQL

      腾讯云数据库MySQL是一种高性能、高可靠、高安全、可灵活伸缩的数据库托管服务,其不仅经济实惠,而且提供备份回档、监控、快速扩容、数据传输等数据库运维全套解决方案,为您简化 IT 运维工作,让您能更加专注于业务发展。

    相关资讯

    热门标签

    活动推荐

    扫码关注腾讯云开发者

    领取腾讯云代金券