1 - Yes, Galera takes care of auto increments for you, but you will get lots of missed ids, so make sure your fields are big enough (e.g. you might need a smallint somewhere whereas without missing ids you could have got away with a tinyint).
2 - Yes, no changes should be needed to the application, except for occasionally you might get deadlocks. You should come up with a system to check error messages automatically and if you get errors like Deadlock found when trying to get lock; try restarting transaction and Lock wait timeout exceeded; try restarting transaction then redo the query and it should go through ok. The data will remain consistent. There is also a Galera setting for automatic retries, but we found it was better to try them again yourself. Obviously you shouldn't be using mysql_query() at all, but for the purposes of a simple to follow example, you could swap your queries to use something like this instead of your usual query function
function vio_mysql_query_deadlock_safe($query, $db = null) {
$deadlock_retries_done = 0;
$deadlock_retries_max = 10;
while ($deadlock_retries_done < $deadlock_retries_max) {
if (is_null($db)) {
$q = mysql_query($query);
} else {
$q = mysql_query($query, $db);
}
if ($q === false) {
$error = mysql_error();
if ($error == 'Deadlock found when trying to get lock; try restarting transaction' || $error == 'Lock wait timeout exceeded; try restarting transaction') {
$deadlock_retries_done++;
continue;
} else {
throw new Exception($error . '. Query: ' . $query);
}
}
return $q;
}
throw new SQLException($error . '. Re-tried with deadlock ' . $deadlock_retries_done . ' times. Query: ' . $query);
}
You should put everything on a level playing field. How ?
Without proper tuning, it is possible for older versions of MySQL to outrun and outgun new versions.
Before running SysBench on the three environments
- Make sure all InnoDB settings are identical for all DB Servers
- For the Master/Slave, run
STOP SLAVE; on the Slave
- For PXC (Percona XtraDB Cluster), shutdown two Masters
Compare the speeds of just standalone MySQL, Percona, and MariaDB.
ANALYSIS
If MySQL is best (Percona people, please don't throw rotten vegetables at me just yet. This is just conjecture), run START SLAVE;. Run SysBench on the Master/Slave. If the performance is significant slower, you may have to implement semisynchronous replication.
If PXC is best, you may need to tune the wsrep settings or the network itself.
If MariaDB is best, you could switch to MariaDB Cluster (if you have the Money) or setup Master/Slave with MariaDB. Run Sysbench. If the performance is significant slower, you may need to tune the wsrep settings or the network itself.
Why tune wsrep settings ? Keep in mind that Galera wsrep (WriteSet Replication) uses virtually synchronous commits and rollbacks. In other words, either all nodes commit or all nodes rollback. In this instance, the weakest link would have to be
- how fast the communication between Nodes happens (especially true if the Nodes are in different data centers)
- if any one node has underconfigured hardware settings
- if any one node communicates slower than other node
Side Note : You should also make sure tune MySQL for multiple CPUs
UPDATE 2014-11-04 21:06 EST
Please keep in mind that Percona XtraDB Cluster does not write scale very well to begin with. Note what the Documentation says under its drawbacks (Second Drawback):
This can’t be used as an effective write scaling solution. There might be some improvements in write throughput when you run write traffic to 2 nodes vs all traffic to 1 node, but you can’t expect a lot. All writes still have to go on all nodes.
SUGGESTION #1
For PXC, turn off one node. Run SysBench against a two node cluster. If the write performance is better than a three node cluster, then it is obvious that the communication between the nodes is the bottleneck.
SUGGESTION #2
I noticed you have a 42GB Buffer Pool, which is more than half the server's RAM. You need to partition the buffer pool by setting innodb_buffer_pool_instances to 2 or more. Otherwise, you can expect some swapping.
SUGGESTION #3
Your innodb_log_buffer_size is 8M by default. Try making it 256M to increase log write performance.
SUGGESTION #4
Your innodb_log_file_size is 512M. Try making it 2G to increase log write performance. If you apply this setting, then set innodb_log_buffer_size to 512M.
Best Answer
The word "uniform" is being used to describe the fact that each server should have similar or identical resources, in terms of cpu, memory, disk (seek time, I/O bandwidth), etc.
Since a single node can slow down the entire cluster, the slowest node determines the overall capacity of the cluster... so using servers whose performance capabilities are not "uniform" (closely comparable) will mean that resources on the more powerful machines will go underutilized, while the less powerful machines slow down the cluster.