# Deadlock found when trying to get lock with Magento **URL:** \ **Category:** Percona XtraDB Cluster 5.x\ **Created:** [July 3, 2015, 7:43am UTC](https://forums.percona.com/t/deadlock-found-when-trying-to-get-lock-with-magento/4285 "2015-07-03T07:43:24Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![aerialls](https://avatars.discourse-cdn.com/v4/letter/a/13edae/32.png) [@aerialls](https://forums.percona.com/u/aerialls)\ **Post date:** [July 3, 2015, 7:43am UTC](https://forums.percona.com/t/deadlock-found-when-trying-to-get-lock-with-magento/4285/1 "2015-07-03T07:43:24Z")
Hello! We have some deadlock problems with our new XtraDB Cluster. We have a 3 nodes cluster (2 Percona XtraDB Cluster in version 5.6.24-72.2-56 and a third arbitrer with garbd) hosting a Magento website. The old platform used a standard asynchonous MySQL replication with master/slave and we decided to migrate to a much robust solution witth XtraDB Cluster. Since the migration, we notices some deadlock errors in Magento: a:5:{i:0;s:111:“SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction”;i:1;s:7362:"#0 /var/[…]Varien/Db/Statement/Pdo/Mysql.php(110): Zend\_Db\_Statement\_Pdo-\>\_execute(Array) Those errors was not present before the migration. We tried to tweak the wsrep configuration but without success. We have HAProxy on each frontend servers (3 servers hosting the magento source code) to redirect ALL requests (read and writes) to the single node of the cluster. Our HAProxy configuration is simple: frontend FE-BDD-RW bind 127.0.0.1:3306 mode tcp default\_backend BE-BDD-RW backend BE-BDD-RW mode tcp option httpchk server BDD01 192.168.10.1:3306 check port 9200 inter 12000 rise 3 fall 3 server BDD02 192.168.10.2:3306 check port 9200 inter 12000 rise 3 fall 3 backup The wsrep configuration has been tweaked from several sources to help the deadlock issue but without success. Right now, our wsrep configuration is like that: wsrep\_provider = /usr/lib/libgalera\_smm.so wsrep\_cluster\_address = gcomm://192.168.10.1,192.168.10.2,192.168.10.3 wsrep\_cluster\_name = CLUSTER01 wsrep\_sst\_method = xtrabackup-v2 wsrep\_sst\_auth = xtrabackup:mypassword wsrep\_provider\_options = “gcs.fc\_limit = 256; gcs.fc\_factor = 0.99; gcs.fc\_master\_slave = yes” wsrep\_retry\_autocommit = 4 binlog\_format = ROW default\_storage\_engine = InnoDB innodb\_locks\_unsafe\_for\_binlog = 1 innodb\_autoinc\_lock\_mode = 2 Is that possible to Percona to understand that we are in a master/slave situation to avoid deadlock issues that are related to galera? Right now, we don’t know how to tweak more the Percona configuration. Thanks! ---
**Author:** ![jrivera](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/jrivera/32/13_2.png) [@jrivera](https://forums.percona.com/u/jrivera)\ **Post date:** [July 5, 2015, 6:43pm UTC](https://forums.percona.com/t/deadlock-found-when-trying-to-get-lock-with-magento/4285/2 "2015-07-05T18:43:23Z")
I wonder what the status of the cluster is, can you provide cluster status? mysql -e “show status like ‘wsrep%’” | egrep “cluster|local” ---
**Author:** ![aerialls](https://avatars.discourse-cdn.com/v4/letter/a/13edae/32.png) [@aerialls](https://forums.percona.com/u/aerialls)\ **Post date:** [July 6, 2015, 2:51am UTC](https://forums.percona.com/t/deadlock-found-when-trying-to-get-lock-with-magento/4285/3 "2015-07-06T02:51:51Z")
Hello! Thanks for the answer. You can find the values below: On the first node: wsrep\_local\_state\_uuid df7d0407-1419-11e5-9c09-b2761f45777f wsrep\_local\_commits 233119 wsrep\_local\_cert\_failures 0 wsrep\_local\_replays 0 wsrep\_local\_send\_queue 0 wsrep\_local\_send\_queue\_max 2 wsrep\_local\_send\_queue\_min 0 wsrep\_local\_send\_queue\_avg 0.000102 wsrep\_local\_recv\_queue 0 wsrep\_local\_recv\_queue\_max 1 wsrep\_local\_recv\_queue\_min 0 wsrep\_local\_recv\_queue\_avg 0.000000 wsrep\_local\_cached\_downto 1391316 wsrep\_local\_state 4 wsrep\_local\_state\_comment Synced wsrep\_cluster\_conf\_id 39 wsrep\_cluster\_size 3 wsrep\_cluster\_state\_uuid df7d0407-1419-11e5-9c09-b2761f45777f wsrep\_cluster\_status Primary wsrep\_local\_bf\_aborts 25 wsrep\_local\_index 2 On the second node: wsrep\_local\_state\_uuid df7d0407-1419-11e5-9c09-b2761f45777f wsrep\_local\_commits 142 wsrep\_local\_cert\_failures 0 wsrep\_local\_replays 0 wsrep\_local\_send\_queue 0 wsrep\_local\_send\_queue\_max 2 wsrep\_local\_send\_queue\_min 0 wsrep\_local\_send\_queue\_avg 0.000393 wsrep\_local\_recv\_queue 0 wsrep\_local\_recv\_queue\_max 62 wsrep\_local\_recv\_queue\_min 0 wsrep\_local\_recv\_queue\_avg 0.142113 wsrep\_local\_cached\_downto 1395415 wsrep\_local\_state 4 wsrep\_local\_state\_comment Synced wsrep\_cluster\_conf\_id 39 wsrep\_cluster\_size 3 wsrep\_cluster\_state\_uuid df7d0407-1419-11e5-9c09-b2761f45777f wsrep\_cluster\_status Primary wsrep\_local\_bf\_aborts 0 wsrep\_local\_index 1 ---
**Author:** ![aerialls](https://avatars.discourse-cdn.com/v4/letter/a/13edae/32.png) [@aerialls](https://forums.percona.com/u/aerialls)\ **Post date:** [July 6, 2015, 2:56am UTC](https://forums.percona.com/t/deadlock-found-when-trying-to-get-lock-with-magento/4285/4 "2015-07-06T02:56:31Z")
When we shutdown the second node and the arbiter, the problem is still here (so with only one node). We need to disable the wsrep configuration in the my.cnf file to have a workaround. I think I missing something…