本文整理自网络,侵删。
MySQL 的一致性日志
如果 MySQL 数据库断电了,未提交的事务怎么办?
答案:依靠日志。
因为在执行一个操作之前,数据库会首先把这个操作的内容写入到文件系统日志里,然后再进行操作。当宕机或者断电的时候,即使操作并没有执行完,但是日志在操作前就已经写好了,我们仍然可以根据日志的内容来进行恢复。
MySQL InnoDB 引擎中和一致性相关的有重做日志(redo log)、回滚日志(undo log)和二进制日志(binlog)。
redo log
每当有操作执行前,在数据真正更改前会先把相关操作写入 redo 日志。这样当发生断电等意外导致后续任务无法完成时,待系统恢复后就可以继续完成这些更改。
undo log
和 redo 日志对应,也叫撤消日志,记录事务开始前数据的状态。
当一些更改在执行一半时发生意外而无法完成,就可以根据撤消日志恢复到更改之前的状态。
举个例子,事务 T1 更新数据 X,对 X 执行 Update 操作,从 10 更新到 20,对应的 Redo 日志为 <T1, X, 20>,Undo 日志为 <T1, X, 10>。
binlog
是 MySQL sever 层维护的一种二进制日志,MySQL 最重要的日志之一,它记录了所有的 DDL 和 DML 语句,除了数据查询语句 select、show 等,还包含语句所执行的消耗时间。
binlog 与 InnoDB 引擎中的 redo/undo log 不同,主要目的是复制和恢复,用来记录对 MySQL 数据更新或潜在发生更新的 SQL 语句,并以事务日志的形式保存在磁盘中。
binlog 主要应用在 MySQL 的主从复制过程中,MySQL 集群在 Master 端开启 binlog,Master 把它的二进制日志传递给 slaves 节点,再从节点回放来达到 master-slave 数据一致的目的。
你可以连接到 MySQL 服务器,使用下面的命令查看真实的 binlog 数据:
//查看binlog文件的内容 show binlog events; //查看指定binlog文件的内容 show binlog events in 'MySQL-bin.000001'; //查看正在写入的binlog文件 show master status\G //获取binlog文件列表 show binary logs;
XA 规范是如何定义的
XA 是由 X/Open 组织提出的分布式事务规范,XA 规范主要定义了事务协调者(Transaction Manager)和资源管理器(Resource Manager)之间的接口。
事务协调者(Transaction Manager)
因为 XA 事务是基于两阶段提交协议的,所以需要有一个协调者,来保证所有的事务参与者都完成了准备工作,也就是 2PC 的第一阶段。
如果事务协调者收到所有参与者都准备好的消息,就会通知所有的事务都可以提交,也就是 2PC 的第二阶段。
之所以需要引入事务协调者,是因为在分布式系统中,两台机器理论上无法达到一致的状态,需要引入一个单点进行协调。
资源管理器(Resource Manager)
负责控制和管理实际资源,比如数据库或 JMS 队列。
目前,主流数据库都提供了对 XA 的支持,在 JMS 规范中,即 Java 消息服务(Java Message Service)中,也基于 XA 定义了对事务的支持。
XA 事务的执行流程
XA 事务是两阶段提交的一种实现方式,根据 2PC 的规范,XA 将一次事务分割成了两个阶段,即 Prepare 和 Commit 阶段。
Prepare 阶段
TM 向所有 RM 发送 prepare 指令,RM 接受到指令后,执行数据修改和日志记录等操作,然后返回可以提交或者不提交的消息给 TM。
如果事务协调者 TM 收到所有参与者都准备好的消息,会通知所有的事务提交,然后进入第二阶段。
Commit 阶段
TM 接受到所有 RM 的 prepare 结果,如果有 RM 返回是不可提交或者超时,那么向所有 RM 发送 Rollback 命令。
相关阅读 >>
《阿里巴巴java开发手册》里面写超过三张表禁止join,这是为什么?
更多相关阅读请进入《mysql》频道 >>
数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。