MySQL flags a statement inside an XA transaction as unsafe for statement-based replication and stops execution.
ER_BINLOG_UNSAFE_XA appears when MySQL detects a statement inside a distributed XA transaction that cannot be safely replicated with statement logging. Switch the server to row-based logging or move the statement outside the XA block to resolve the problem.
ER_BINLOG_UNSAFE_XA
MySQL raises ER_BINLOG_UNSAFE_XA when a data-changing statement inside an XA transaction cannot be guaranteed to replay correctly on a replica that uses statement-based logging.
The server stops the transaction to protect replication integrity, because concurrent distributed transactions could commit in different orders on replicas, leading to deadlocks or data drift.
The error is triggered when the binlog_format parameter is STATEMENT or MIXED and the server encounters an INSERT, UPDATE, DELETE, or DDL command inside an XA START/END block.
MySQL 5.7.20 and later include extra checks that flag potentially unsafe patterns, especially when multiple XA transactions can interleave.
The safest fix is to switch binary logging to ROW format so every row change is replicated deterministically.
Alternatively, remove the offending statement from the XA transaction or execute the workload on a server dedicated to ROW logging.
Ecommerce applications using two-phase commit across payment and inventory tables often hit the error during peak traffic; setting binlog_format=ROW resolves it without code changes.
Micro-services performing distributed commits across shards can avoid the error by committing locally first, then using XA only for idempotent confirmation records.
Configure new MySQL replicas with ROW logging by default when XA is in use.
Monitor the error log for ER_BINLOG_UNSAFE_XA and alert the data team so fixes can be applied before replication stalls.
ER_BINLOG_UNSAFE_STATEMENT warns about unsafe statements outside XA; switching to ROW logging fixes both issues.
ER_XAER_DUPID indicates duplicate XID usage; ensure unique XIDs to prevent rollback loops.
STATEMENT or MIXED logging cannot guarantee replay order for XA transactions.
Updating non-transactional tables inside the XA block makes replication timing nondeterministic.
Multiple concurrent XA START blocks on the same server increase deadlock risk on replicas.
Unsafe non-XA statement detected with statement logging.
A duplicate XID was used in an XA START call.
An XA transaction exceeded the timeout period during rollback.
If all replicas run ROW logging, the error will not appear; otherwise, ignoring it risks data drift.
The warning appears only when binary logging is enabled, so standalone instances without replication are unaffected.
No. MIXED switches to STATEMENT for many operations, so XA remains unsafe.
Galaxy surfaces server variables and warns developers when XA code runs on a STATEMENT-logged server, promoting early fixes.
.avif)
.avif){kind=logo}
