mysql的XA事务恢复过程详解_Mysql

mysql数据库开机报错
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
100224 12:24:20 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Transaction 0 4497755 was in the XA prepared state.
InnoDB: Transaction 0 4468551 was in the XA prepared state.
InnoDB: Transaction 0 4468140 was in the XA prepared state.
InnoDB: 3 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 0 row operations to undo
InnoDB: Trx id counter is 0 5312768
InnoDB: Starting in background the rollback of uncommitted transactions
100224 12:24:20 InnoDB: Rollback of non-prepared transactions completed
100224 12:24:20 InnoDB: Started; log sequence number 0 3805002509
100224 12:24:20 InnoDB: Starting recovery for XA transactions...
100224 12:24:20 InnoDB: Transaction 0 4497755 in prepared state after recovery
100224 12:24:20 InnoDB: Transaction contains changes to 8 rows
100224 12:24:20 InnoDB: Transaction 0 4468551 in prepared state after recovery
100224 12:24:20 InnoDB: Transaction contains changes to 1 rows
100224 12:24:20 InnoDB: Transaction 0 4468140 in prepared state after recovery
100224 12:24:20 InnoDB: Transaction contains changes to 1 rows
100224 12:24:20 InnoDB: 3 transactions in prepared state after recovery
100224 12:24:20 [Note] Found 3 prepared transaction(s) in InnoDB
100224 12:24:20 [Warning] Found 3 prepared XA transactions
100224 12:24:20 [Note] Event Scheduler: Loaded 0 events
100224 12:24:20 [Note] /opt/mysql/bin/mysqld: ready for connections.
Version: '5.1.39' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)
意味着有三个XA的事务没有提交或回滚。
登录到mysql
mysql> xa recover;
+----------+--------------+--------------+------------------------------------------------------------+
| formatID | gtrid_length | bqual_length | data |
+----------+--------------+--------------+------------------------------------------------------------+
| 131075 | 30 | 28 | 1-7f000001:bae5:4b6928eb:f06397f000001:bae5:4b6928eb:f0650 |
| 131075 | 30 | 28 | 1-7f000001:bae5:4b6928eb:fb5c37f000001:bae5:4b6928eb:fb5cd |
| 131075 | 30 | 28 | 1-7f000001:bae5:4b6928eb:f03ea7f000001:bae5:4b6928eb:f0400 |
+----------+--------------+--------------+------------------------------------------------------------+
数据表示信息如下
formatIDis the formatIDpart of the transaction xid
gtrid_lengthis the length in bytes of the gtridpart of the xid
bqual_lengthis the length in bytes of the bqualpart of the xid
datais the concatenation of the gtridand bqualparts of the xid
这是三个XA事务的信息,准备直接回滚。
mysql> xa rollback '1-7f000001:bae5:4b6928eb:fb5c3','7f000001:bae5:4b6928eb:fb5cd',131075;
Query OK, 0 rows affected (0.41 sec)
再启动就正常了。

MySQL XA
I.5. 对XA事务的限制
XA事务支持限于InnoDB存储引擎。
MySQL XA实施是针对外部XA的,其中,MySQL服务器作为资源管理器,而客户端程序作为事务管理器。未实施“内部XA”。这样,就允许MySQL服务器内的单独存储引擎作为RM(资源管理器),而服务器本身作为TM(事务管理器)。处理包含1个以上存储引擎的XA事务时,需要内部XA。内部XA的实施是不完整的,这是因为,它要求存储引擎在表处理程序层面上支持两阶段提交,目前仅对InnoDB实现了该特性。
对于XA START,不支持JOIN和RESUME子句。

对于XA END,不支持SUSPEND [FOR MIGRATE]子句。
在全局事务内,对于每个XA事务,xid值的bqual部分应是不同的,该要求是对当前MySQL XA实施的限制。它不是XA规范的组成部分。

如果XA事务达到PREPARED状态而且MySQL服务器宕机,当服务器重启后,能够继续处理事务。就像原本应当的那样。但是,如果客户端连接中止而服务器继续运行,服务器将回滚任何未完成的XA事务,即使该事务已达到PREPARED状态也同样。它应能提交或回滚PREPARED XA事务,但在不更改二进制日志机制的情况下不能这样。

时间: 2024-08-03 06:05:33

mysql的XA事务恢复过程详解_Mysql的相关文章

mysql的XA事务恢复过程

mysql数据库开机报错: InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 100224 12:24:20 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace

MySQL InnoDB之事务与锁详解_Mysql

引题:为何引入事务? 1>.数据完整性 2>.数据安全性 3>.充分利用系统资源,提高系统并发处理的能力 1. 事务的特征 事务具有四个特性:原子性(Atomiocity).一致性(Consistency).隔离性(Isolation)和持久性(Durability),这四个特性简称ACID特性. 1.1原子性 事务是数据库的逻辑工作单位,事务中包括的所有操作要么都做,要么都不做. 1.2 一致性 事务执行的结果必须是使数据库从一个一致性的状态变到另外一个一致性状态. 1.3 隔离性 一

MySQL 四种事务隔离级别详解及对比_Mysql

MySQL 四种事务隔离级别详解及对比 按照SQL:1992 事务隔离级别,InnoDB默认是可重复读的(REPEATABLE READ).MySQL/InnoDB 提供SQL标准所描述的所有四个事务隔离级别.你可以在命令行用--transaction-isolation选项,或在选项文件里,为所有连接设置默认隔离级别. 例如,你可以在my.inf文件的[mysqld]节里类似如下设置该选项: transaction-isolation = {READ-UNCOMMITTED | READ-CO

MySQL数据库使用mysqldump导出数据详解_Mysql

mysqldump是mysql用于转存储数据库的客户端程序.它主要产生一系列的SQL语句,可以封装到文件,该文件包含有所有重建您的数据库所需要的 SQL命令如CREATE DATABASE,CREATE TABLE,INSERT等等.可以用来实现轻量级的快速迁移或恢复数据库.是mysql数据库实现逻辑备份的一种方式. 在日常维护工作当中经常会需要对数据进行导出操作,而mysqldump是导出数据过程中使用非常频繁的一个工具:它自带的功能参数非常多,文章中会列举出一些常用的操作,在文章末尾会将所有

MySQL binlog中的事件类型详解_Mysql

MySQL binlog记录的所有操作实际上都有对应的事件类型的,譬如STATEMENT格式中的DML操作对应的是QUERY_EVENT类型,ROW格式下的DML操作对应的是ROWS_EVENT类型. 首先,看看源码中定义的事件类型 源码位置:mysql-5.7.14/libbinlogevents/include/binlog_event.h enum Log_event_type { /** Every time you update this enum (when you add a ty

MySQL外键使用及说明详解_Mysql

一.外键约束 MySQL通过外键约束来保证表与表之间的数据的完整性和准确性. 外键的使用条件: 1.两个表必须是InnoDB表,MyISAM表暂时不支持外键(据说以后的版本有可能支持,但至少目前不支持): 2.外键列必须建立了索引,MySQL 4.1.2以后的版本在建立外键时会自动创建索引,但如果在较早的版本则需要显示建立: 3.外键关系的两个表的列必须是数据类型相似,也就是可以相互转换类型的列,比如int和tinyint可以,而int和char则不可以: 外键的好处: 可以使得两张表关联,保证

Mysql事项,视图,函数,触发器命令(详解)_Mysql

事项开启和使用 //修改表的引擎 alter table a engine=myisam; //开启事务 begin; //关闭自动提交 set autocommit=0; //扣100 update bank set money=money-100 where bid=1; //回滚,begin开始的所有sql语句操作 rollback; //开启事务 begin; //关闭自动提交 set autocommit=0; //扣100 update bank set money=money-10

MySQL对数据库数据进行复制的基本过程详解_Mysql

复制      复制是从一个MySQL服务器(master)将数据拷贝到另外一台或多台MySQL服务器(slaves)的过程.复制是异步进行的--slaves服务器不需要持续地保持连接来接收master的数据.依据配置的不同,可以复制所有数据库,或指定的数据库,甚至是某一数据库指定的表.      使用复制功能的目的在于: 向外扩展的解决方案 -- 通过在多台服务器之间分散负载来提高性能.在这种环境下,所有写和更新操作都在master服务器上进行,而读操作则发生在一台或多台slaves服务器上.

oralce数据库恢复过程详解

某客户的数据库出现崩溃,无法正常启动,经过我的远程紧急救援恢复之后,恢复正常,如下是简单的处理过程,供参考! 在open数据库时,发现无法打开,报错如下: SMON: enabling cache recovery ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0000.1d2be1e6): select ctime, mtime, stime from obj$ where obj# = :1 Er