Deadlock while running ineffective UPDATE query on 5.5.33 with STATEMENT-based binlog format

Bug #1231283 reported by Marko Skender
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MySQL patches by Codership
New
Undecided
Unassigned
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC
Invalid
Undecided
Unassigned

Bug Description

After upgrading cluster nodes to 5.33 we are faced with following issue.

Running this query:

update users set user_agent='Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36', ref_id='45586829' where id=878424

Yields:

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

The error is produced if fields are the same as already committed to database (i.e. running query several times in a row).
If you run the query with different values than those already in the table, the query is successful.
If you run the query again with same values again, the above error is produced every time on every node.

Note that we have single node for read/write over HAProxy, and others are for backup/standby purposes.
We had no issues with this on 5.30. or any other previos versions of MySQL/Percona server (from Mysql 4.x, 5.x, Percona Server 5.5 to XtraDB cluster 5.30).

For testing purposes, I have lowered wsrep_slave_threads to 1, but it didn't help.

I have also tried testing other tables and other databases and updating other kinds of fields (int, varchar, etc) but the problem is persists.

All afflicted databases are INNODB.

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

And let me guess, your effective binlog_format is STATEMENT?

Revision history for this message
Marko Skender (marko-r) wrote :

I feel pretty stupid right now!

Of course, you are correct, I was missing binlog_format in my.cnf from the very day we installed the cluster. :(

Sorry to bother you, I was 100% sure the directive was there from setup (because I know it's a requirement) and didn't bother to check twice.

Revision history for this message
Raghavendra D Prabhu (raghavendra-prabhu) wrote :

In addition to being documented to use ROW binlog_format, I think the binlog_format set to STATEMENT (and/or MIXED) should produce warnings in the error log.

Changed in percona-xtradb-cluster:
status: New → Invalid
Revision history for this message
Alex Yurchenko (ayurchen) wrote :

So this is a bug with wsrep STATEMENT replication. I'd suggest that reference to STATEMENT be put into title.

summary: - Deadlock while running ineffective UPDATE query on 5.33
+ Deadlock while running ineffective UPDATE query on 5.5.33 with
+ STATEMENT-based binlog format
Marko Skender (marko-r)
Changed in percona-xtradb-cluster:
status: Invalid → In Progress
status: In Progress → Invalid
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-1451

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

Other bug subscribers

Remote bug watches

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