The Ultimate Guide to High Availability with MariaDB

Question on processing XA Transactions

You are viewing an old version of this question. View the current version here.

Hi, Our program reads a binlog using mariadb_rpl_fetch, and replicates XA transactions.

The problem is that I can't match eacg XA COMMIT to the relevant XA START, which is a must for us.

E.g., assume that 2 clients are are executing concurrently (I removed several events for clarity)

Client 1:

XA START 'TXN1'; insert into table1. XA PREPARE 'TXN1';

wait 1 second

XA COMMIT 'TXN1';

Client 2:

XA START 'TXN2'; insert into table2; XA PREPARE 'TXN2';

XA COMMIT 'TXN2';

Now, mariadb_rpl_fetch returns these events:

GTID_EVENT 0-1-43

WRITE_ROWS_EVENT insert into table1

XA_PREPARE _EVENT 'TXN1'

GTID_EVENT 0-1-44

WRITE_ROWS_EVENT insert into table2

XA_PREPARE_EVENT 'TXN2'

GTID_EVENT 0-1-45

QUERY_EVENT: XA COMMIT 'TXN2';

GTID_EVENT 0-1-46

QUERY_EVENT: XA COMMIT 'TXN1';

So, when I read an XA COMMIT, how do I know to which XA START it refers? As seen in the above, the XA COMMITs are not ordered in the same order as XA STARTs.

XA START and XA COMMIT events have different GTID's, so I cannot match them by GTID.

XA COMMIT specifies the transaction name, e.g. TXN1, but mariadb_rpl_fetch doesn't return the transaction name for XA START.

Our application must correlate each XA START to the correct XA COMMIT. How can I do it with MariaDB Connector/C API?

Thanks in advance

Sruli

Answer

Well, since I haven't got any response, I had to change the libmariadb code. I added this field:

struct st_mariadb_rpl_gtid_event {

:

MARIADB_STRING xid; };

And changed mariadb_rpl_fetch() to also return the xid for XA transactions.

Now, I can match each XA START to XA COMMIT and know whether and when each XA START has been committed, by matching the xid of both.

If anyone is interested, I can post the modified code.

Regards

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.