XA with wsrep replication plugin

We are finally ready to move to Percona cluster, but out IIS website fails with these errors.

[MySqlException (0x80004005): Percona-XtraDB-Cluster doesn’t recommend using SERIALIZABLE isolation with pxc_strict_mode = ENFORCING]

(I had to set pxc_strict_mode=DISABLED, just to move on at see if I could get it working.)

Next error we recieve after disabling strict_mode:

[AutomaticMigrationsDisabledException: Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.]

Our database is now created during the first access on the webpage, but a refresh of the webpage then shows this error:

[MySqlException (0x80004005): This version of MySQL doesn’t yet support ‘XA with wsrep replication plugin’]

Does anyone have suggestions on what we can do…


Hi @staun , thank you for posting your question to the Percona forums!
Unfortunately PXC does not support XA transactions, as per the PXC limitations page: Percona XtraDB Cluster Limitations

XA transactions are not supported
Due to possible rollback on commit.

1 Like

Hi @staun,
As Michael said, PXC does not support XA transactions, and also does not support SERIALIZABLE either. You will need to disable XA in your application and switch to REPEATABLE-READ or READ-COMMITTED. Unfortunately there is no workaround for this other than application changes; these are direct limitations of PXC as clearly stated in the documentation.

1 Like

Thanks for your input, I read about the limitations. Just wasn’t 100% sure this was the issue and maybe there was a workaround. Had hoped we could just move from our current production MySQL to Percona Cluster… But it looks like my work was wasted… I had really looked forward for this cluster setup for all our locations.

1 Like

Hi @staun,
XA transactions and their implementation are very rare (in my 14+ years of mysql experience). Are you sure your application actually needs them, or is your app just using them because some developer thought that was the only way? If you find out that you actually need them, then you’ll have to stay with regular MySQL. I would suggest turning your attention to GitHub - openark/orchestrator: MySQL replication topology management and HA to assist with making your async replication easier to manage and handle failure promotions.

1 Like