前提:mysql数据库开启了binlog日志,并且有对应的日志文件 起因:今天由于同事对数据库的误操作不小心删除了一条数据 方法一:通过binlog日志文件恢复数据 通过mysqlbinlog恢复MySQL数据的两种方法: (1)时间date回滚    通过cmd运行到binlog所在的目录,再录入如下命令: mysqlbinlog --stop- | mysql -uroot -pxxx (恢复到2018-03-12 17:32:59之前的数据,如果是start-date,即从该时间点后的开始

mysql中bin-log在mysql默认状态下是没有打开的,我们要先打开mysql 开启bin-log功能,然后再通过备份的bin-log进行数据库恢复了. 具体的操作是通过mysqlbinlog这个指令来完成的 /mysql/bin/mysqlbinlog --database=fox --start-date="2013-01-22 5:00:00" --stop-date="2013-01-22 9:00:00" /mysql/data/mysql-bin.

MySQL Binary Log也就是常说的bin-log, ,是mysql执行改动产生的二进制日志文件,其主要作用有两个: * 数据回复 * 主从数据库.用于slave端执行增删改,保持与master同步. 1.开启binary log功能 对于mysql也是支持增量备份,但要打开mysql的bin log功能. 我们修改mysql的配置文件.linux是/etc/my.cnf,windows是mysql的安装目录/my.ini 我们在[mysqld]下面加上log-bin一行代码,如下面.

为保证没有其他参数配置影响,重新安装配置了一台最小化安装的CentOS7虚拟机 1. 基础知识
 安装mysql5.6数据库Mysql binlog初步理解 2. 配置mysql 开启binlog.修改binlog模式为Row Level模式
 [root@localhost ~]# vi /etc/my.cnf 
修改mysql配置文件,在[mysqld]下增加以下内容 # 注释: 开启binlog 文件名以mysql-bin开头 log-bin = mysql-bin # 注释: 备份恢复模

MySQL Binary Log也就是常说的bin-log, ,是mysql执行改动产生的二进制日志文件,其主要作用有两个: * 数据回复 * 主从数据库.用于slave端执行增删改,保持与master同步. 1.开启binary log功能 需要修改mysql的配置文件,本篇的实验环境是win7,配置文件为mysql安装目录\MySQL Server 5.1下的my.ini,添加一句log_bin = mysql_bin即可      eg:      [mysqld]            

模拟数据恢复的案例 有些时候脑瓜就会短路,难免会出错 场景:在生产环境中,我们搭建了mysql主从,备份操作都是在从备份数据库上 前提:有最近一天或者最近的全备 或者最近一天相关数据库的备份 最重要的是,二进制日志必须完整 服务器信息 角色 端口 192.168.1.21 mysql主 30136 192.168.1.21 mysql从 30236 接下来,我们模拟下 案例一.update未加where条件,误操作修改数据 全备命令: mysqldump -uroot -p123456  --s

需求:需要给开发提供一个2018年9月30号的数据,按照我们公司正常备份策略来说,直接找到对应时间的备份数据,解压导入即可,恰好这个时间节点的数据没有,只备份到2018年9月25号的,糟糕了吧 咋办呢,咱们利用binlog日志来恢复吧,如果二进制日志都没有,那还恢复啥呢,运维咋当滴 话不多说,进入正题 一.导入数据 我的源数据:baodian_2018-09-25_.tar.bz2               #这一串数字是pos节点位置,等下利用二进制恢复的时候需要用到,时间:9月 25 01

如果mysql不小心操作失误导致数据错误或者丢失这时候binlog起到了很大的作用 恢复有几种方式 1.按时间恢复--start-datetime   如果确定了时间点,那么按时间恢复是一个再好不过的事,一般是通过日常的定期备份+差异备份(日志) 如果日常备份在4点,出错的时间在12:00点,12:30发现的,首先我们要确认12点出了什么错,12点以后的数据还能不能继续使用,如果不影响,那么我们只需跳过12:00执行的数据即可 首先,恢复4点的备份 然后,通过binlog获取4点到11:59的数

日常开发,运维中,经常会出现误删数据的情况.误删数据的类型大致可分为以下几类: 使用 delete 误删行 使用 drop table 或 truncate table 误删表 使用 drop database 语句误删数据库 使用 rm 命令误删整个 MySQL 实例. 不同的情况,都会有其优先的解决方案: 针对误删行,可以通过 Flashback 工具将数据恢复 针对误删表或库,一般采用通过 BINLOG 将数据恢复. 而对于误删 MySQL 实例,则需要我们搭建 HA 的 MySQL 集群

在前面,我们了解了mysql binlog日志的作用以及使用方法:  http://www.php20.cn/article/237 在后面讲到了,可以通过binlog进行恢复数据,那么,具体步骤是怎么样的呢? 数据库备份 数据库恢复的先决条件是,定时备份数据库,缩小binlog恢复范围.首先我们备份测试数据库数据: 1 mysqldump -uroot -p --database test > testBackSql.sql 假定它为最后一次备份数据. test数据库,test数据表最后一个i

前言 在最近的工作中,由于自己粗(zuo)心(si)误update操作导致几百行的数据出现错误,在心急如焚的同时(那时候我竟然不知道除了备份之后还有binlog日志恢复)立马查资料学习binlog的恢复,随后立马进行了恢复.虽然可以假装自己没出错(emmmmm......最后还是得承认的!),但下班之后心情不能久久平复,立马打开电脑进行一次实验记录才能对得起自己犯的错误. 注:此次实验是在Wnidows下进行的(网上Linux挺多,但是Windows的甚少,加上本身我的电脑也是Win7就简单做一

利用mysql全备 +binlog server恢复方法之伪装master 单实例试验 一.试验环境 10.72.7.40 实例 mysql3306为要恢复的对象,mysql3306的全备+binlog server(目录/data/mysql/mysql3306/backup) 实例mysql3307为伪装master 实例mysql3308为伪装master的slave,在其上恢复数据 1.mysql3306全备 innobackupex --defaults-file=/data/mysq

做了mysql主从也有一段时间了,这两天检查磁盘空间情况,发现放数据库的分区磁盘激增了40多G,一路查看下来,发现配置好主从复制以来到现在的binlog就有40多G,原来根源出在这里,查看了一下my.cnf,看到binlog的size是1G就做分割,但没有看到删除的配置,在mysql里查看了一下variablesmysql>show variables like '%log%';查到了| expire_logs_days                 | 0                  

备份全库 [root@db01 b]# mysqldump -uroot -poldboy123 -A > /b/full.sql Warning: Using a password on the command line interface can be insecure. [root@db01 b]#ll total 656 -rw-r--r-- 1 root root 667860 Mar 11 15:39 full.sql 打开看下都是一些插入类的语句比较容易读懂,可以用awk.sed,

删除误操作有时会意外出现,如果你有备份表数据的好习惯,那么至少你可以追回备份前的那些数据.如果我们打开了mysql的binlog,那么可以通过它的增量操作日志来恢复数据.怎么打开binlog前篇已有说明(参见windows下打开binlog),这里举例说明如何通过binlog进行恢复: 1.看下当前的binlog位置,这里称为位置1: mysql> show master status; +---------------------+----------+--------------+-----

1.mysql命令或者source命令恢复数据 这两个命令在进行恢复数据的时候要检查是否创建数据库.如果数据库不存在,则恢复失败. 数据库迁移 1.相同版本的mysql数据库之间的迁移. mysqldump -h host1 -uroot -ppwd --all-databases | mysql -h host2 -uroot -ppwd 相同版本之间可以使用像管道命令的功能一样传输数据. 2.不同版本的mysql数据库之间的迁移 最常用的方法就是先使用mysqldump命令备份数据库,再使用

备份指定数据库的全部表或指定表 mysqldump -u user -h localhost -p [password] db_name[ tbl_name[,tbl_name.......]]>fileName.sql mysqldump的常用参数 -add-drop-table 在每个CREATE TABLE 语句前添加DROP TABLE 语句,默认打开,-skip-add-drop-table取消 -add-locks 该选项会在INSERT语句中捆绑一个LOCK TABLE 和 UNL

事件: 在生产库执行update时只添加了STATUS(状态)条件,将所有状态为'E'的数据全部改为了'D' 思路: 操作步骤主要参考自文章:https://blog.csdn.net/weixin_43733154/article/details/104675222 结合原作者文章及实际情况,整理解决思路主要概况为: 1.使用show master status 命令查看当前binlog文件: 2.使用mysqlbinlog命令通过误操作时间及误操作表的条件,导出误操作记录文件: 3.查看导出

1. 直接导入数据库 mysqlbinlog --database=testdb mysql-bin. | mysql -uroot -f 2. 导出成SQL文 (1) 从binlog输出为SQL mysqlbinlog -vv --database=testdb --base64-output=decode-rows mysql-bin. > .sql .sql > 0001_#.sql 导出的SQL文如下格式: ### UPDATE `test`.`test_data1` ### WHER

1.一开始通过官方下载有的压缩包安装,碰到各种依赖问题,最后采用YUM安装 1.通过yum安装percona-Xtrabackup 1.1 先安装依赖: yum install perl-DBI yum install perl-DBD-MySQL yum install perl-Time-HiRes yum install perl-IO-Socket-SSL 1.2 配置yum源 创建文件/etc/yum.repos.d/Percona.repo内容如下: [percona] name =

在人工手动进行一些数据库写操作的时候(比方说数据订正),尤其是一些不可控的批量更新或删除,通常都建议备份后操作.不过不怕万一,就怕一万,有备无患总是好的.在线上或者测试环境误操作导致数据被删除或者更新后,想要恢复,一般有两种方法. 方法一.利用最近的全量备份+增量binlog备份,恢复到误操作之前的状态,但是随着数据量的增大,binlog的增多,恢复起来很费时.方法二.如果binlog的格式为row,那么就可以将binlog解析出来生成反向的原始SQL 以下是利用方法二写的一个python脚本b