1、MySQL数据库分布式事务

InnoDB存储引擎提供了对XA事务的支持,并通过XA事务来支持分布式事务的实现。分布式事务指的是允许多个独立的事务资源(transactional resources)参与到一个全局的事务中。事务资源通常是关系型数据库系统,但也可以是其他类型的资源。全局事务要求在其中的所有参与的事务要么都提交,要么都回滚,这对于事务原有的ACID要求又有了提高。另外,在使用分布式事务时, InnoDB存储引擎的事务隔离级别必须设置为SERIALIZABLE。
XA事务允许不同数据库之间的分布式事务,如一台服务器是 MySQL数据库的,另台是 Oracle数据库的,又可能还有一台服务器是 SQL Server数据库的,只要参与在全局事务中的每个节点都支持XA事务。分布式事务可能在银行系统的转账中比较常见,如用户Davd需要从上海转10000元到北京的用户 Mariah的银行卡中:

[SQL] 纯文本查看 复制代码

  # Bank@shanghai:
    UPDATE account SET money=money -10000 WHERE user='David';
    # Bank@Beijing
    UPDATE account SET money=money+ 10000 WHERE user='Mariah';

在这种情况下,一定需要使用分布式事务来保证数据的安全。如果发生的操作不能全部提交或回滚,那么任何一个结点出现问题都会导致严重的结果。要么是David的账户被扣款,但是 Mariah没收到,又或者是Davd的账户没有扣款, Mariah却收到钱了。
XA事务由一个或多个资源管理器(Resource Managers)、一个事务管理器(Transaction Manager)以及一个应用程序(Application Program)组成。

• 资源管理器:提供访问事务资源的方法。通常一个数据库就是一个资源管理器。
• 事务管理器:协调参与全局事务中的各个事务。需要和参与全局事务的所有资源管理器进行通信。
• 应用程序:定义事务的边界,指定全局事务中的操作。
  

在 MySQL数据库的分布式事务中,资源管理器就是 MySQL数据库,事务管理器为连接 MySQL服务器的客户端。图7-22显示了一个分布式事务的模型。

分布式事务使用两段式提交(two- phase commit)的方式。在第一阶段,所有参与全局事务的节点都开始准备( PREPARE),告诉事务管理器它们准备好提交了。在第二阶段,事务管理器告诉资源管理器执行 ROLLBACK还是 COMMIT。如果任何一个节点显示不能提交,则所有的节点都被告知需要回滚。可见与本地事务不同的是,分布式事务需要多一次的 PREPARE操作,待收到所有节点的同意信息后,再进行 COMMIT或是ROLLBACK操作。
MySQL数据库XA事务的SQL语法如下:

[SQL] 纯文本查看 复制代码

XA {START I BEGIN} xid [JOIN I RESUME]
    XA END xid [ SUSPEND [FOR MIGRATE]]
    XA PREPARE xid
    XA COMMIT xid [ONE PHASE]
    XA ROLLBACK xid
    XA RECOVER

在单个节点上运行XA事务的例子:

[SQL] 纯文本查看 复制代码

 mysql> XA START 'a';
    Query OK, 0 rows affected (0.03 sec)

    mysql> insert into t select 11;
    Query OK, 1 row affected (0.04 sec)
    Records: 1  Duplicates: 0  Warnings: 0

    mysql> XA END 'a';
    Query OK, 0 rows affected (0.00 sec)

    mysql> XA PREPARE 'a';
    Query OK, 0 rows affected (0.07 sec)

    mysql> XA RECOVER;
    +----------+--------------+--------------+------+
    | formatID | gtrid_length | bqual_length | data |
    +----------+--------------+--------------+------+
    |        1 |            1 |            0 | a    |
    +----------+--------------+--------------+------+
    1 row in set (0.00 sec)

    mysql> XA COMMIT 'a';
    Query OK, 0 rows affected (0.06 sec)

在单个节点上运行分布式事务没有太大的实际意义,但是要在 MySQL数据库的命令下演示多个节点参与的分布式事务也是行不通的。通常来说,都是通过编程语言来完成分布式事务的操作的。

2、内部XA事务

之前讨论的分布式事务是外部事务,即资源管理器是 MySQL数据库本身。在MySQL数据库中还存在另外一种分布式事务,其在存储引擎与插件之间,又或者在存储引擎与存储引擎之间,称之为内部XA事务。
最为常见的内部XA事务存在于binlog与 InnoDB存储引擎之间。由于复制的需要,因此目前绝大多数的数据库都开启了 binlog功能。在事务提交时,先写二进制日志,再写 InnoDB存储引擎的重做日志。对上述两个操作的要求也是原子的,即二进制日志和重做日志必须同时写入。若二进制日志先写了,而在写人 InnoDB存储引擎时发生了宕机,那么 slave可能会接收到 master传过去的二进制日志并执行,最终导致了主从不一致的情况。如图7-23所示。
在图7-23中,如果执行完①、②后在步骤③之前 MySQL数据库发生了宕机,则会发生主从不一致的情况。为了解决这个问题, MySQL数据库在 binlog与InnoDB存储引擎之间采用XA事务。当事务提交时, InnoDB存储引擎会先做一个PREPARE操作,将事务的xid写人,接着进行二进制日志的写入,如图7-24所示。如果在 InnoDB存储引擎提交前, MySQL数据库宕机了,那么 MySQL数据库在重启后会先检查准备的UXID事务是否已经提交,若没有,则在存储引擎层再进行一次提交操作。

1、MySQL数据库分布式事务

InnoDB存储引擎提供了对XA事务的支持,并通过XA事务来支持分布式事务的实现。分布式事务指的是允许多个独立的事务资源(transactional resources)参与到一个全局的事务中。事务资源通常是关系型数据库系统,但也可以是其他类型的资源。全局事务要求在其中的所有参与的事务要么都提交,要么都回滚,这对于事务原有的ACID要求又有了提高。另外,在使用分布式事务时, InnoDB存储引擎的事务隔离级别必须设置为SERIALIZABLE。
XA事务允许不同数据库之间的分布式事务,如一台服务器是 MySQL数据库的,另台是 Oracle数据库的,又可能还有一台服务器是 SQL Server数据库的,只要参与在全局事务中的每个节点都支持XA事务。分布式事务可能在银行系统的转账中比较常见,如用户Davd需要从上海转10000元到北京的用户 Mariah的银行卡中:

[SQL] 纯文本查看 复制代码

  # Bank@shanghai:
    UPDATE account SET money=money -10000 WHERE user='David';
    # Bank@Beijing
    UPDATE account SET money=money+ 10000 WHERE user='Mariah';

在这种情况下,一定需要使用分布式事务来保证数据的安全。如果发生的操作不能全部提交或回滚,那么任何一个结点出现问题都会导致严重的结果。要么是David的账户被扣款,但是 Mariah没收到,又或者是Davd的账户没有扣款, Mariah却收到钱了。
XA事务由一个或多个资源管理器(Resource Managers)、一个事务管理器(Transaction Manager)以及一个应用程序(Application Program)组成。

• 资源管理器:提供访问事务资源的方法。通常一个数据库就是一个资源管理器。
• 事务管理器:协调参与全局事务中的各个事务。需要和参与全局事务的所有资源管理器进行通信。
• 应用程序:定义事务的边界,指定全局事务中的操作。
  

在 MySQL数据库的分布式事务中,资源管理器就是 MySQL数据库,事务管理器为连接 MySQL服务器的客户端。图7-22显示了一个分布式事务的模型。

分布式事务使用两段式提交(two- phase commit)的方式。在第一阶段,所有参与全局事务的节点都开始准备( PREPARE),告诉事务管理器它们准备好提交了。在第二阶段,事务管理器告诉资源管理器执行 ROLLBACK还是 COMMIT。如果任何一个节点显示不能提交,则所有的节点都被告知需要回滚。可见与本地事务不同的是,分布式事务需要多一次的 PREPARE操作,待收到所有节点的同意信息后,再进行 COMMIT或是ROLLBACK操作。
MySQL数据库XA事务的SQL语法如下:

[SQL] 纯文本查看 复制代码

XA {START I BEGIN} xid [JOIN I RESUME]
    XA END xid [ SUSPEND [FOR MIGRATE]]
    XA PREPARE xid
    XA COMMIT xid [ONE PHASE]
    XA ROLLBACK xid
    XA RECOVER

在单个节点上运行XA事务的例子:

[SQL] 纯文本查看 复制代码

 mysql> XA START 'a';
    Query OK, 0 rows affected (0.03 sec)

    mysql> insert into t select 11;
    Query OK, 1 row affected (0.04 sec)
    Records: 1  Duplicates: 0  Warnings: 0

    mysql> XA END 'a';
    Query OK, 0 rows affected (0.00 sec)

    mysql> XA PREPARE 'a';
    Query OK, 0 rows affected (0.07 sec)

    mysql> XA RECOVER;
    +----------+--------------+--------------+------+
    | formatID | gtrid_length | bqual_length | data |
    +----------+--------------+--------------+------+
    |        1 |            1 |            0 | a    |
    +----------+--------------+--------------+------+
    1 row in set (0.00 sec)

    mysql> XA COMMIT 'a';
    Query OK, 0 rows affected (0.06 sec)

在单个节点上运行分布式事务没有太大的实际意义,但是要在 MySQL数据库的命令下演示多个节点参与的分布式事务也是行不通的。通常来说,都是通过编程语言来完成分布式事务的操作的。

2、内部XA事务

之前讨论的分布式事务是外部事务,即资源管理器是 MySQL数据库本身。在MySQL数据库中还存在另外一种分布式事务,其在存储引擎与插件之间,又或者在存储引擎与存储引擎之间,称之为内部XA事务。
最为常见的内部XA事务存在于binlog与 InnoDB存储引擎之间。由于复制的需要,因此目前绝大多数的数据库都开启了 binlog功能。在事务提交时,先写二进制日志,再写 InnoDB存储引擎的重做日志。对上述两个操作的要求也是原子的,即二进制日志和重做日志必须同时写入。若二进制日志先写了,而在写人 InnoDB存储引擎时发生了宕机,那么 slave可能会接收到 master传过去的二进制日志并执行,最终导致了主从不一致的情况。如图7-23所示。
在图7-23中,如果执行完①、②后在步骤③之前 MySQL数据库发生了宕机,则会发生主从不一致的情况。为了解决这个问题, MySQL数据库在 binlog与InnoDB存储引擎之间采用XA事务。当事务提交时, InnoDB存储引擎会先做一个PREPARE操作,将事务的xid写人,接着进行二进制日志的写入,如图7-24所示。如果在 InnoDB存储引擎提交前, MySQL数据库宕机了,那么 MySQL数据库在重启后会先检查准备的UXID事务是否已经提交,若没有,则在存储引擎层再进行一次提交操作。