MySQL (InnoDB analysis): 44 --- affairs (XA transaction (distributed transactions))

A, MySQL database distributed transaction

• InnoDB storage engine provides support for XA transactions, and by supporting distributed transactions XA transaction implementation
• Distributed Transaction means: allow multiple separate transactional resources to participate in a global transaction. Transactional resources are usually relational database system, but may also be other types of resources
• Global transaction requires all participating transactions which are either committed or rolled back , which for the original ACID transaction requirements, there has been increased. In addition, when using distributed transactions, InnoDB's transaction isolation level must be set to SERIALIZABLE
• XA transaction allows distributed transactions between different databases, such as a server, MySQL database, and the other is an Oracle database, and there may be a server, each node of SQL Server as long as participation in global affairs are XA transaction support
• Distributed Transaction may be more common in the transfer of the banking system, as users need David transferred from Shanghai to Beijing 10 000 users Mariah's bank card:

• In this case, we need to use distributed transactions to ensure data security. If the operation can not take place globally committed or rolled back, then any node problem can lead to serious results. Either David's account is debited, but Mariah did not receive, or is David's account no charge, Mariah has received money

innodb_support_xa parameters

• This parameter is used to control whether to support XA transactions
• The default is ON, expressed support for XA transactions

Second, the composition XA transactions

• XA transaction by the following three parts:
  • Resource Manager (Resource Managers): provides a way to access transactional resources. Usually a database is a resource manager
  • Transaction manager (Transaction Manager): coordinate participation in all affairs global transaction. And require all resource managers involved in global transactions communicate
  • Application (Application Program): operational boundaries, global transaction specified in the definition of affairs
• MySQL databases in a distributed transaction, the resource manager is MySQL database, transaction manager to connect to the MySQL server's client-side
• The following figure shows a distributed transaction model:

• Use two-phase commit distributed transactions are:
  • The first phase, all the nodes of the global transaction parameters are beginning to prepare (PREPARE), tells the transaction manager that they are ready to submit a
  • The second phase, the transaction manager tells Explorer organic ROLLBACK or COMMIT. If you can not submit any node display, all nodes are told to roll back
• Visible and local transaction is different, distributed transactions need more time PREPARE operation after, until you receive the same information for all nodes, and then COMMIT or ROLLBACK operation

Three Grammatical, XA transaction

Examples of single-node operation

• Run on a single node in a distributed transaction is not much practical significance, but to demonstrate a distributed transaction involved multiple nodes in a MySQL database command is not feasible

V. Internal XA transaction

• Distributed Transaction previously discussed external affairs, namely resource manager is MySQL database itself. There is another distributed transaction in a MySQL database, which is between the engine and plug-in storage, or between storage engine and storage engine, called the internal XA transaction

Internal XA transaction guarantee from the main

• The most common internal XA transaction exists between binlog and InnoDB storage engine
• 由于复制的需要，因此目前绝大多数的数据库都开启了binlog的功能。在事务提交时，先写二进制日志，再写InnoDB存储引擎的重做日志。对上述两个操作的要求也是原子的，即二进制日志和重做日志必须同时写入。若二进制日志先写了，而在写入InnoDB存储引擎时发生了宕机，那么slave可能会接收到master传过去的二进制日志并执行，最终导致了主从不一致的情况。如下图所示：
  • 在图中，如果执行完①、②后在步骤③之前MySQL数据库发生了宕机，则会发生主从不一致的情况

• 为了解决这个问题，MySQL数据库在binlog与InnoDB存储引擎之间采用XA事务。当事务提交时，InnoDB会先做一个PREPARE操作，将操作的xid写入，接着进行二进制日志的写入，如下图所示：
  • 如果在InnoDB存储引擎提交前，MySQL数据库发生宕机了，那么MySQL数据库在重启后会先检查准备的UXID事务是否已经提交，若没有，则在存储引擎层再进行一次提交操作