I was able to reproduce this bug quite easily. One has to deploy percona-xtradb-cluster with 3 nodes (one can use juju with local provider to speed up deployment - once juju with local provider (https://juju.ubuntu.com/docs/config-LXC.html) has been set up just do: juju deploy percona-cluster -n 3). Then set up this database scheme:
Adjust grants for pktest database to reflect your environment and then connect to one of the nodes, firing up 20 or more simultaneous load of INSERT statements:
$> for i in {1..20}; do (yes "INSERT INTO t1 (datafield) VALUES ('mario');" | mysql -h 10.0.0.10 pktest) & done
As soon as you stop any of the nodes, primary key violation will occur.
I confirmed this to fail on percona-xtradb-5.5, and I have confirmed it is fixed in percona-xtradb-5.6.
I was able to reproduce this bug quite easily. One has to deploy percona- xtradb- cluster with 3 nodes (one can use juju with local provider to speed up deployment - once juju with local provider (https:/ /juju.ubuntu. com/docs/ config- LXC.html) has been set up just do: juju deploy percona-cluster -n 3). Then set up this database scheme:
mysql> CREATE DATABASE pktest;
mysql> CREATE TABLE t1 (id INTEGER PRIMARY KEY AUTO_INCREMENT, datafield VARCHAR(20));
Adjust grants for pktest database to reflect your environment and then connect to one of the nodes, firing up 20 or more simultaneous load of INSERT statements:
$> for i in {1..20}; do (yes "INSERT INTO t1 (datafield) VALUES ('mario');" | mysql -h 10.0.0.10 pktest) & done
As soon as you stop any of the nodes, primary key violation will occur.
I confirmed this to fail on percona-xtradb-5.5, and I have confirmed it is fixed in percona-xtradb-5.6.
I also confirmed that the workaround mentioned earlier (https:/ /github. com/codership/ mysql-wsrep/ issues/ 18#issuecomment -63890539) fixes the issue in percona-xtradb-5.5.