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
While an application-independent solution could be possible, in general, a replication-aware application could be much better, because you can use the high performance of asynchronous replication for most of the time, and only revert back to (slower) synchronous replication when it is needed.
This is not a theoretical method, we at Wikipedia use this model with specific code called "chronology protector", which only gets triggered when an important event happens (e.g. an edit) and you don't want the user to be served outdated results.
In order to do this, after doing your master writes, you should keep your master replication file and position (if not using GTID), or the GTID coordinates (if using GTID) after your write (once the transactions has been commited on the master), and then on the replica connections, wait until the server reaches those positions or higher. There is some extra details to consider, such as when exactly to wait (on write or on read), for how long until you give a timeout (e.g. if replica breaks or lags), but that is highly dependent on your environement.
In terms of implementation,
MASTER_POS_WAIT()
/WAIT_FOR_EXECUTED_GTID_SET()
are the functions commonly used for this.Some of the clusters you mention give you shortcuts to perform this easier (e.g. Galera's causal reads), but the logic is similar- you don't want to be on fully consistent mode all the time; just forcing it when necessary.