Comment 2 for bug 1366997

Hi Jay,

Yep, all our tables have the following definition for primary keys.

  `id` int(11) NOT NULL AUTO_INCREMENT

wsrep_auto_increment_control is left at the default (ON)

mysql> show global variables like 'wsrep_auto_increment_control';
+------------------------------+-------+
| Variable_name | Value |
+------------------------------+-------+
| wsrep_auto_increment_control | ON |
+------------------------------+-------+

I neglected to mention that we currently send all transactions to a single node in the cluster, so we can rule out writeset conflicts.

I posted about this issue the first time it happened on the Codership mailing list: https://groups.google.com/forum/#!topic/codership-team/lDRB9Z6swV8

The suggestion from then was that if we're sending transactions to a single server, we could disable auto increment control, but we would prefer to keep it on for a few reasons. First, we sometimes go multi-master to slowly move application traffic between cluster nodes. Additionally, we like the operational experience of having the cluster manage the increment and offset values when we add/remove nodes.

One other possible interesting setup for our cluster, we have wsrep_causal_reads enabled globally in our my.cnf file. I don't see how that would effect this case, but I know it's something makes us unique from other clusters that might exist.