mysql异常怎么回滚 mysql 异常( 三 )


- Before InnoDB Prepare
事务可能还没执行完 , 因此InnoDB中的状态还没有prepare 。根据2PC的过程,Binlog中也没有该事务的events 。需要通知InnoDB回滚这些事务 。
- 恢复过程
从上面的事务状态可以看出:恢复时事务要提交还是回滚,是由Binlog来决定的 。
- 事务的Xid_log_event 存在,就要提交 。
- 事务的Xid_log_event 不存在,就要回滚 。
恢复的过程非常简单:
- 从Binlog中读出所有的Xid_log_event
- 告诉InnoDB提交这些XID的事务
- InnoDB回滚其它的事务
mysql如何做事件回滚BEGIN//开始COMMIT//如果都成功,MYSQL没错误就执行这个ROLLBACK//事件回滚 不过要注意的是,数据库表要InnoDB这种格式 。MyISAM这个格式不支持回滚的 。
一文详解-MySQL 事务和锁当多个用户访问同一份数据时,一个用户在更改数据的过程中,可能有其他用户同时发起更改请求,为保证数据库记录的更新从一个一致性状态变为另外一个一致性状态,使用事务处理是非常必要的,事务具有以下四个特性:
MySQL 提供了多种事务型存储引擎,如 InnoDB 和 BDB 等,而 MyISAM 不支持事务 。为了支持事务,InnoDB 存储引擎引入了与事务处理相关的 REDO 日志和 UNDO 日志 , 同时事务依赖于 MySQL 提供的锁机制
事务执行时需要将执行的事务日志写入日志文件,对应的文件为 REDO 日志 。当每条 SQL 进行数据更新操作时,首先将 REDO 日志写进日志缓冲区 。当客户端执行 COMMIT 命令提交时,日志缓冲区的内容将被刷新到磁盘,日志缓冲区的刷新方式或者时间间隔可以通过参数 innodb_flush_log_at_trx_commit 控制
REDO 日志对应磁盘上的 ib_logifleN 文件,该文件默认为 5MB,建议设置为 512MB,以便容纳较大的事务 。MySQL 崩溃恢复时会重新执行 REDO 日志的记录,恢复最新数据 , 保证已提交事务的持久性
与 REDO 日志相反,UNDO 日志主要用于事务异常时的数据回滚,具体内容就是记录数据被修改前的信息到 UNDO 缓冲区,然后在合适的时间将内容刷新到磁盘
假如由于系统错误或者 rollback 操作而导致事务回滚,可以根据 undo 日志回滚到没修改前的状态,保证未提交事务的原子性
与 REDO 日志不同的是 , 磁盘上不存在单独的 UNDO 日志文件,所有的 UNDO 日志均存在表空间对应的 .ibd 数据文件中,即使 MySQL 服务启动了独立表空间
在 MySQL 中,可以使用 BEGIN 开始事务,使用 COMMIT 结束事务,中间可以使用 ROLLBACK 回滚事务 。MySQL 通过 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等语句支持本地事务
MySQL 定义了四种隔离级别,指定事务中哪些数据改变其他事务可见、哪些数据该表其他事务不可见 。低级别的隔离级别可以支持更高的并发处理,同时占用的系统资源更少
InnoDB 系统级事务隔离级别可以使用以下语句设置:
查看系统级事务隔离级别:
InnoDB 会话级事务隔离级别可以使用以下语句设置:
查看会话级事务隔离级别:
在该隔离级别,所有事务都可以看到其他未提交事务的执行结果 。读取未提交的数据称为脏读(Dirty Read),即是:首先开启 A 和 B 两个事务,在 B 事务更新但未提交之前,A 事务读取到了更新后的数据,但由于 B 事务回滚,导致 A 事务出现了脏读现象
所有事务只能看见已经提交事务所做的改变,此级别可以解决脏读,但也会导致不可重复读(Nonrepeatable Read):首先开启 A 和 B 两个事务,A事务读取了 B 事务的数据,在 B 事务更新并提交后,A 事务又读取到了更新后的数据,此时就出现了同一 A 事务中的查询出现了不同的查询结果

推荐阅读