The transaction was rolled back during COMMIT because Group Replication detected a conflict that failed certification.
ER_TRANSACTION_ROLLBACK_DURING_COMMIT happens when MySQL Group Replication rejects a transaction at commit time after conflict detection. Check group_replication_consistency, review conflicting writes, and retry the transaction or adjust conflict-handling settings to resolve the issue.
ER_TRANSACTION_ROLLBACK_DURING_COMMIT
MySQL raises error 3101 when the Group Replication plugin aborts a COMMIT because another member reported a conflicting transaction. The server rolls the local transaction back to preserve data consistency across the group.
The error only appears on servers that run MySQL 5.7.6 or later with Group Replication enabled. Stand-alone instances will never emit this code.
Group certification compares writesets from every member. If two writesets touch overlapping primary keys or unique indexes, the later transaction is rejected with error 3101.
Misconfigured group_replication_consistency, clock skew, or network partitions can widen the conflict window and increase the likelihood of certification failures.
First, identify the conflicting rows by examining the writeset history in performance_schema.replication_applier_status_by_worker or the binary log.
Next, replay or retry the rejected transaction on a fresh connection. If conflicts recur, refactor the workload to reduce simultaneous updates on the same keys.
High-throughput OLTP systems often issue concurrent UPDATEs on hot rows like counters. Introducing row-level sharding or using INSERT ... ON DUPLICATE KEY UPDATE with deterministic statements can lower conflicts.
Long-running transactions that lock many rows increase the chance of overlap. Commit in smaller batches to minimize certification failures.
Design applications to keep transactions short and idempotent so that automatic retries succeed safely.
Monitor performance_schema.replication_group_member_stats and enable alerts in Galaxy to flag rising conflict rates before they escalate.
Error 3090 (ER_LOCK_WAS_NOT_GRANTED) surfaces when a transaction cannot obtain local locks, while error 3102 (ER_TRANSACTION_WITH_WRONG_COORD) indicates coordination issues during replication. Their fixes differ but share the need for careful transaction design.
Frequent writes to the same primary key across multiple members cause overlapping writesets and certification rejection.
Transactions that touch many rows stay open longer, widening the window for conflicts.
Out-of-sync clocks or high network latency delay writeset delivery, increasing conflict probability.
Non-deterministic statements without group_replication_consistency = BEFORE_AND_AFTER generate inconsistent writesets that fail certification.
Occurs when local row locks are unavailable, unrelated to group certification.
Indicates the transaction coordinator was not the expected member in the group.
Generated when an external plugin vetoes a transaction, sometimes confused with 3101.
No. The error only affects the local transaction. The cluster stays healthy because the conflict was correctly resolved.
No. Group Replication always certifies transactions to guarantee consistency. You can only reduce conflicts by changing workload patterns.
Most applications succeed within three retries. Monitor your specific workload and adjust the retry limit based on observed conflict rates.
Galaxy highlights rollback-during-commit errors in the query history, suggests retry-safe patterns, and surfaces replication metrics so you can act before conflicts spike.
.avif)
.avif){kind=logo}
