Shulou(Shulou.com)06/01 Report--

1 principle

About the distributed transaction XA of MySQL database, the principle of distributed transaction implementation, see [3]; for the description of MySQL XA, see [1] [2].

MySQL XA is divided into two categories: internal XA and external XA; internal XA are used for transactions across multiple engines under the same instance, with the familiar Binlog as the coordinator; external XA is used for distributed transactions across multiple MySQL instances, which requires application layer intervention as the coordinator (suspended transactions in case of crash, global commit or rollback need to be decided by the application layer, and the implementation of the application layer is more demanding)

In this paper, it is assumed that readers already know the use of external distributed transaction XA in MySQL database, and focus on MySQL database, how to handle the crash recover of external distributed transaction XA, and how applications handle different crash recover situations in order to ensure the consistency of distributed transactions. Finally, this paper briefly analyzes the problems existing in the external XA support of MySQL database and the optional solutions.

The source code analysis is based on MySQL 5.1.49 and MySQL 5.5.16.

2 MySQL processing flow

2.1 MySQL external XA-normal processing flow

The normal processing flow of XA outside the MySQL database is not introduced here. Please refer to [1] [2] [3]. Next, I focus on the crash recovery process of the distributed transaction XA outside the MySQL database, which is closely related to how the application uses the external XA correctly.

2.2 MySQL external XA-crash recovery proc

If a MySQL database node running an external XA distributed transaction crashes, the process of crash recovery after restart involves external XA processing as follows:

Crash recover:

/ / 1. Read the binlog file and save the xid in the file into the commit_list hash table

/ / as the name implies, the so-called commit_list means the xid corresponding to the prepare status in this list

/ / can be committed during crash recovery, and xid that is not in commit_list must be rolled back

/ / the xid in binlog belongs to internal xid and is generated by MySQL and used for internal XA.

Log.cc::TC_LOG_BINLOG::recover

/ / 2. Traverses all the underlying transaction engines and collects all xid in XA_PREPARED state

/ / these xid lists include both internal xid and external xid, and no distinction is made within the storage engine

Handler.cc::ha_recover (commit_list)

/ / execute the recover methods provided at each engine level to collect all the xid in the prepared state

/ / classified according to xid:

/ / 3. If xid belongs to an internal xid, look for this xid in commit_list

/ / if it exists, commit the transaction corresponding to this xid; otherwise, roll back the transaction

/ / 4. If xid belongs to an external xid, then insert xid into the xid_cache hash table

/ / all xid in xid_cache will be returned through the xa recover command, waiting for the external program to make a decision

Handler.cc::xarecover_handlerton

/ / 5. Collect all the xid in the prepare state in the InnoDB storage engine and return

Got = hton- > recover (innobase_xa_recover)

My_xid x = info- > list [I] .get _ my_xid ()

If (! X)

/ / if it is currently an external xid, insert xid into the xid_cache hash table

Xid_cache_insert (& xid_cache, x)

Else

If (x in commit_list)

/ / if it is currently an internal xid and the xid exists in the binlog, submit it

Hton- > commit_by_xid ()

Else

/ / if it is currently an internal xid and the xid does not exist in the binlog, rollback

Hton- > rollback_by_xid ()

Through the above analysis, it can be concluded that:

Inside the MySQL database, xid will be distinguished. The internal xid is generated by the MySQL database itself (MySQL internal xid format, which will be given later in this article) for consistency of transactions between multiple engines, and the external xid is given by the application for distributed transactions across multiple MySQL instances. But the storage engine layer makes no distinction (in the upper layer of MySQL).

When crash recover, the storage engine is responsible for collecting transactions in the prepare state inside the engine and returning them to the upper layer of MySQL.

Binlog acts as the coordinator of the internal XA [5]. When the internal xid appears in the binlog, the binlog is responsible for submitting the crash recover; if the xid does not appear in the binlog, the binlog is responsible for rolling back. (this is because binlog does not prepare, only commit, so the internal xid that appears in binlog must be able to guarantee that it has completed prepare in the underlying storage engines.)

The xid of an external XA transaction is simply inserted into the xid_cache during the crash recover process and no other processing is done. When the user initiates the xa recover command, the xid in the prepare state in the xid_cache is returned.

The flow of the xa recover command is as follows.

Xa recover command processing flow:

Sql_parse.cc::mysql_execute_command

Case SQLCOM_XA_RECOVER:

Mysql_xa_recover ()

/ / traverses the xid_cache, finds out the transactions in which the state is XA_PREPARED, and sends the client

While (xs = hash_element (& xid_cache))

If (xs- > xa_state = = XA_PREPARED)

Protocol- > write ()

According to the xid list returned by each MySQL database instance collected by the xa recover command, and then compare the application-side logs to determine these xid, which global commit, which rollback.

Since there is only one instance of the MySQL database in the test, you can directly select the xid where the commit is in the prepare state.

Note:

MySQL internal xid format: MYSQL_XID_PREFIX + server_id + my_xidMYSQL_XID_PREFIX: MySQLXid (source code written dead) 8 bytesserver_id: id,ulong of MySQL instance, 4 bytesmy_xid: internal self-increasing sequence, ulonglong, 8 bytes for example: "MySQLXid 0004" server_id =''; my_xid = 4

Therefore, you should be careful not to construct this form of xid externally, otherwise the MySQL database will confuse the internal xid with the external xid.

In general, it is difficult to construct an internal xid, because the server_id is generally less than 4 bytes, and the deficiency is made up by ASCI NIL (null), while applications generally do not construct such an external xid.

references

[1] Sergei Golubchik. Distributed Transaction Processing with MySQL XA

[2] http://dev.mysql.com/doc/refman/5.1/en/xa.html

[3] X/Open. Distributed TP: The XA Specification

[4] Chen Silu. Amoeba

[5] MariaDB WorkLog#132: Transaction coordinator plugin

This article is from http://www.searchdatabase.com.cn/showcontent_58646.htm.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.