<p>The server cannot find the XA transaction identifier (XID) referenced in a COMMIT, ROLLBACK, or PREPARE statement.</p>
<p>ER_XAER_NOTA (MySQL Error 1397: Unknown XID) appears when a COMMIT, ROLLBACK, or PREPARE references an XA transaction ID that the server does not recognize. Verify that the XID was started on the same connection, recover or forget orphaned transactions, and retry the command using the right session.</p>
XAER_NOTA: Unknown XID
Error 1397 fires when you execute XA COMMIT, XA ROLLBACK, or XA PREPARE with an XID the server cannot locate. The condition name ER_XAER_NOTA maps to the XA standard code XAER_NOTA, meaning "Node transaction association does not exist."
The problem usually shows up in distributed transaction managers, message queues, or application servers that rely on MySQLs XA interface. Fixing it fast is critical because dangling transactions lock rows, hold resources, and break two phase commit workflows.
An unknown XID means the server sees no matching transaction in its in-memory XA list or the binary log recovery set. Subsequent COMMIT or ROLLBACK does nothing, leaving participating resources out of sync and risking data inconsistency across systems.
Production environments using microservices and global transactions can cascade failures if one branch silently skips commit while others succeed. Early detection and correction protect atomicity and consistency guarantees.
Most cases trace back to session mis-management or crash recovery gaps. Losing the original connection or forgetting to PREPARE before COMMIT are frequent triggers. Network blips, timeouts, or manual KILL commands also orphan XIDs.
In replication setups, the error may appear on slaves if binary logs include COMMIT for an XID never PREPAREd on that replica. Version mismatches or disabled XA support can contribute.
Start by confirming the XID truly exists. Query performance_schema.xa_transactions (MySQL 8.0+) or run SHOW ENGINE INNODB STATUS to list active XA entries. If absent, the server will always return ER_XAER_NOTA.
Next, ensure COMMIT or ROLLBACK executes on the same connection that ran XA START. Switching sessions clears the XA list, so connection pooling must pin transactions.
When a crash occurs between PREPARE and COMMIT, run XA RECOVER to list pending XIDs, then decide to XA COMMIT 'xid' ONE PHASE or XA ROLLBACK 'xid'.
If the application issued COMMIT without PREPARE, resend XA PREPARE first or restart the whole XA sequence. Galaxy users can trace the statement history per connection to identify the missing step.
Always PREPARE before COMMIT in two phase workflows. Use connection pooling libraries that support stickiness or pinning to keep the same connection until the global transaction finishes.
Monitor performance_schema.xa_transactions for orphaned rows and configure alerts on ER_XAER_NOTA spikes. Galaxy’s query versioning lets teams audit who executed what step when, reducing guesswork.
Error 1398 ER_XAER_INVAL signals an invalid XA argument, often due to malformed XIDs. Validate identifier length and character set.
Error 1399 ER_XAER_RMFAIL indicates the resource manager failed. Check storage engines and crash recovery logs.
The client disconnects or the pool recycles the connection before PREPARE or COMMIT, leaving MySQL unaware of the XID in later calls.
Applications jump directly from XA START to XA COMMIT, so the server never moves the transaction into the prepared list.
MySQL or the host crashes after PREPARE. On restart, the XID lives in recovery but the client issues COMMIT from a new session.
Slaves replay a COMMIT event for an XID that was filtered or failed earlier, producing ER_XAER_NOTA during relay log execution.
Raised when XA commands use an invalid argument or malformed XID. Fix by ensuring XID length and format are correct.
Indicates the resource manager (storage engine) is unavailable or failed to process the XA request. Check engine logs and restart if needed.
Occurs when XA commands are issued outside an XA transaction context. Always wrap statements with XA START and XA END.
No. The error correctly signals that the XID you passed is not in MySQLs XA transaction table.
Ignoring them risks data inconsistency across participating systems. Always investigate and resolve the underlying cause.
Run XA RECOVER or query performance_schema.xa_transactions to list pending or prepared XIDs.
Yes. Galaxy keeps each connection visible in dedicated tabs, making it easier to run XA commands on the correct session and audit the full statement chain.
.avif)
.avif){kind=logo}
