MySQL patches by Codership

transaction does not rollback after max write set size was exceeded

Bug #1280557 reported by Seppo Jaakola
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
MySQL patches by Codership
Status tracked in 5.6
5.5
Fix Released
High
Seppo Jaakola
MySQL patches by Codership 5.5.37-25.10
5.6
Fix Released
High
Seppo Jaakola
MySQL patches by Codership 5.6.16-25.5
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC
Status tracked in 5.6
5.5
Fix Released
Undecided
Unassigned
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC 5.5.37-25.10
5.6
Fix Released
Undecided
Unassigned
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC 5.6.15-25.5

Bug Description

If transaction size exceeds the wsrep_max_ws_size limit, there will appear a warning message in error log and replication is skipped. However, the transaction is committed in the master node, and cluster will render in inconsistent state.

Seppo Jaakola (seppo-jaakola)
Changed in codership-mysql:
assignee: nobody → Seppo Jaakola (seppo-jaakola)
importance: Undecided → High
status: New → In Progress
Revision history for this message
Seppo Jaakola (seppo-jaakola) wrote :

exceeding of wsrep_max_ws_size was detected, but necessary error code (WSREP_SIZE_EXCEEDED) was not returned, and therefore the transaction did not rollback. This issue has been fixed in revision:

wsrep-5.5: http://bazaar.launchpad.net/~codership/codership-mysql/wsrep-5.5/revision/3950

Revision history for this message
Seppo Jaakola (seppo-jaakola) wrote :

FIx was merged in wsrep-5.6, in revision: http://bazaar.launchpad.net/~codership/codership-mysql/5.6/revision/4042

Revision history for this message
Seppo Jaakola (seppo-jaakola) wrote :

With current fix, the client will get back deadlock error, when transaction size grows too large. Deadlock error is not good error code here, as it guides the client to retry the transaction, and retrying will never succeed, if transaction limits remain the same.
Therefore, the fix should be modified to use some other error code. Unfortunately there is no good choices for too large transaction error among MySQL server error codes. One potential error code could be:

ERROR 1180 (HY000): Got error # during COMMIT

Revision history for this message
Seppo Jaakola (seppo-jaakola) wrote :

fix for better error code was pushed in revision:
wsrep-5.5: http://bazaar.launchpad.net/~codership/codership-mysql/wsrep-5.5/revision/3953

Revision history for this message
Seppo Jaakola (seppo-jaakola) wrote :

here's a way to reproduce the issue:
mysql> create table L (i int primAry key auto_increment, s varchar(1024));
mysql> set global wsrep_max_ws_size=1024;
mysql> insert into L (s) values (repeat('i',1024));
ERROR 1180 (HY000): Got error 5 during COMMIT

Revision history for this message
Seppo Jaakola (seppo-jaakola) wrote :

Merged the fix into wsrep-5.6, in revision:
http://bazaar.launchpad.net/~codership/codership-mysql/5.6/revision/4055

Revision history for this message
Ovais Tariq (ovais-tariq) wrote :

Is this in anyway related to https://bugs.launchpad.net/percona-xtradb-cluster/+bug/1309669

Revision history for this message
Alex Yurchenko (ayurchen) wrote :

It sure is, as well as to https://bugs.launchpad.net/codership-mysql/+bug/1270920

I.e. you should check lp:1309669 after both of these fixes.

Revision history for this message
Ovais Tariq (ovais-tariq) wrote :

Sounds good.

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-1621

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.