前言:      继上一篇MySQL[Delete误操作]回滚之后,现在介绍下Update回滚,操作数据库时候难免会因为“大意”而误操作,需要快速恢复的话通过备份来恢复是不太可能的,因为需要还原和binlog差来恢复,等不了,很费时.这里说明因为Update 操作的恢复方法:主要还是通过binlog来进行恢复,前提是binlog_format必须是Row格式,否则只能通过备份来恢复数据了.和上一篇的条件一样.方法:     条件:开启Binlog,Format为Row.     步骤:1.通过M

本文转自http://www.cnblogs.com/dfcao/p/6147970.html#undefined 感谢作者 基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了.误操作后,能快速回滚数据是非常重要的. binlog2sql快速回滚 首先,确认你的MySQL server开启了binlog,设置了以下参数: [mysqld] serv

在数据库日常维护中,开发人员是最让人头痛的,很多时候都会由于SQL语句 写的有问题导致服务器出问题,导致资源耗尽.最危险的操作就是在做DML操作的时候忘加where条件,导致全表更新,这是作为运维或者DBA的我们改如 何处理呢?下面我分别针对update和delete操作忘加where条件导致全表更新的处理方法. 一. update 忘加where条件误操作恢复数据(binglog格式必须是ROW) 1.创建测试用的数据表 create table t1 ( id int unsigned no

基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了.误操作后,能快速回滚数据是非常重要的. binlog2sql快速回滚 首先,确认你的MySQL server开启了binlog,设置了以下参数: [mysqld] server- log_bin = /var/log/mysql/mysql-bin.log max_binlog_size = 10

基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了.误操作后,能快速回滚数据是非常重要的. 传统解法 用全量备份重搭实例,再利用增量binlog备份,恢复到误操作之前的状态.然后跳过误操作的SQL,再继续应用binlog.此法费时费力,不值得再推荐. 利用binlog2sql快速闪回 首先,确认你的MySQL server开启了binlog,设置了

摘要: 利用binlog闪回误操作数据. 基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了.误操作后,能快速回滚数据是非常重要的. 传统解法 用全量备份重搭实例,再利用增量binlog备份,恢复到误操作之前的状态.然后跳过误操作的SQL,再继续应用binlog.此法费时费力,不值得再推荐. 利用binlog2sql快速闪回 首先,确认你的MySQ

参考:http://wubx.net/?s=mysqlbinlog mysql官方的mysqlbinlog没有回滚的功能,淘宝大牛对官方代码进行了修改使之能够将binlog中的DML操作变成互逆的语句,比如delete变为insert,update的set和where的互换.不过注意前提是binlog的格式必须是binlog_format=ROW 另外注意导入回滚数据较多时,需要调整超时时间和最大package的大小: binlog_format=ROW max_allowed_packet=1

add by zhj: 看来我对MySQL的理解还有待深入,水还是挺深的啊,MySQL给记录加锁时,可以通过innodb_lock_wait_timeout参数设置超时时间, 如果加锁等待超过这个时间,就会回滚,但回滚的话有两种方式:第一种:回滚当前加锁的这条语句:第二种:回滚整个事务.这两种方式是通过参数 innodb_rollback_on_timeout来控制的.如果是OFF,表示加锁超时回滚时,只回滚加锁超时的那条SQL语句:如果是ON,表示回滚整个事务.默认 是OFF.在<MySQL

应用场景:   银行取钱,从ATM机取钱,分为以下几个步骤       1 登陆ATM机,输入密码:    2 连接数据库,验证密码:    3 验证成功,获得用户信息,比如存款余额等:    4 用户输入需要取款的金额,按下确认键:    5 从后台数据库中减掉用户账户上的对应金额:    6 ATM吐出钱:    7 用户把钱拿走.    对于上面的取钱这个事情,如果有一步出现错误的话,那么就会取消整个取钱的动作,但是如果在第5步,系统后台已经把钱减了,但是ATM机没有取出来,那么就应用到m

一.起因 begin或者START TRANSACTION开始一个事务 rollback事务回滚 commit 事务确认 人们对事务的解释如下:事务由作为一个单独单元的一个或多个SQL语句组成,如果其中一个语句不能完成,整个单元就会回滚(撤销),所有影响到的数据将返回到事务开始以前的状态.因而,只有事务中的所有语句都成功地执行才能说这个事务被成功地执行.  这句话本身没有什么问题,问题是我给理解错了,我测试中问题描述为如下: mysql事务中有两条insert语句,其中第二条语句是错误的,在运行

主要内容: ***数据定义语言DDL重点 ***数据操纵语言DML重点 数据查询语言DQL重点 ---事务控制语言TCL ---数据库控制语言DCL ---主键(primary key) ---数据冗余(另外建表,把某个外建与另一个表的主键建立关系联系起来) ---事务 ***数据定义语言DDL重点 定义:DDL(Data Definition Language):负责数据结构定义与创建数据库对象的语言. 负责数据结构定义与创建数据库对象的语言. 常用的有create alter drop  

用存储过程处理复杂的业务时,可能涉及到对多张表格的操作,在任一个步骤出了问题,就需要对前面的操作回滚.举例实现: DROP PROCEDURE IF EXISTS pro_test; CREATE PROCEDURE pro_test ( para_a ), para_b ) ) BEGIN ; -- 定义返回结果并赋初值0 ; -- 在执行过程中出任何异常设置result_code为1 ; -- 如果表中没有下一条数据则置为2 START TRANSACTION; -- 开始事务 /* * 这

提交 为了演示效果,需要打开两个终端窗口,使用同一个数据库,操作同一张表 step1:连接 终端1:查询商品分类信息 select * from goods_cates; step2:增加数据 终端2:开启事务,插入数据 begin; insert into goods_cates(name) values('小霸王游戏机'); 终端2:查询数据,此时有新增的数据 select * from goods_cates; step3:查询 终端1:查询数据,发现并没有新增的数据 select * f

在数据库日常维护中,开发人员是最让人头痛的,很多时候都会由于SQL语句写的有问题导致服务器出问题,导致资源耗尽.最危险的操作就是在做DML操作的时候忘加where条件,导致全表更新,这是作为运维或者DBA的我们改如何处理呢?下面我分别针对update和delete操作忘加where条件导致全表更新的处理方法. 一. update 忘加where条件误操作恢复数据(binglog格式必须是ROW) 1.创建测试用的数据表 mysql> create table t1 ( -> id int un

注意: 本文的恢复,并不是基于恢复某个时间点的全量备份后的增量恢复,而是指在现有数据库基础上基于binlog的恢复.适用于较小的数据误操作. 提取日志文件为sql语句: /usr-ext/local/mysql/bin/mysqlbinlog --database=db_name --base64-output=decode-rows -v mysql-bin.000418 > /home/mysqllog.txt 报错: Error writing file '/tmp/tmp.Tt5I62'

最近碰到“TOO DEEP OR LONG SEARCH IN THE LOCK TABLE WAITS-FOR GRAPH, WE WILL ROLL BACK FOLLOWING TRANSACTION”. 重新温习下受益良多,其中死锁的判定规则,其实我们早在5年前解决秒杀场景的第一个版本就已经涉及,并且思路很相似,如果有时间的话,我会补充上一批文章说下如果关闭死锁检测对单行更新能提升多少性能. 下面这一段代码展示的是: “ If the LATEST DETECTED DEADLOCK s

如图查看表的属性: InnoDB 支持事务. MyISAM 不支持事务,不过性能更优越.

事务回滚后,自增ID仍然增加,回滚后,自增ID仍然增加.比如当前ID是7,插入一条数据后,又回滚了.然后你再插入一条数据,此时插入成功,这时候你的ID不是8,而是9.因为虽然你之前插入回滚,但是ID还是自增了. 如果你认为自增ID不应该被事务化,那么其他事务不得不等待着,检查自增ID是被使用还是被回滚,这就导致阻塞. 比如下面的例子,A表使用自增ID. User ------------ begin transaction insert into A ... insert into B ...

下面直接上代码(copy到你的数据库里面直接就可以运行): CREATE PROCEDURE [dbo].[SP_UPDATE_LOG] ) AS BEGIN SET NOCOUNT ON; IF NOT EXISTS(SELECT * FROM sys.tables WHERE NAME = @TABLENAME AND TYPE = 'U' ) BEGIN PRINT'ERROR:not exist table '+@TABLENAME RETURN END IF (@TABLENAME L

从MySQL binlog解析出你要的SQL.根据不同选项,你可以得到原始SQL.回滚SQL.去除主键的INSERT SQL等. 用途=========== * 数据快速回滚(闪回)* 主从切换后新master丢数据的修复* 从binlog生成标准SQL,带来的衍生功能 项目状态===正常维护.应用于部分公司线上环境. * 已测试环境    * Python 2.7, 3.4+    * MySQL 5.6, 5.7 安装============== ```shell> git clone ht