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.
Neo4j is a master-slave cluster.
While you can write to slaves for safety, it will take locks on the master and affect your whole cluster's performance.
Best Answer
Group Replication vs Galera (aka PXC)
Group Replication is only months old; Galera has been around for years. Once GR establishes its worth (which I think it will), the answer may be something like this...
They are very similar. Both do an excellent job of HA -- any single node crashing can be recovered from, usually automatically. Both provide a high degree of read scaling. GR promises to provide more write scaling.
Without knowing your requirements, and your tolerance for various things, I cannot advise on which way to go. Perhaps 90% of MySQL/MariaDB/Percona users on this forum do not use any form of Replication. So, the first question is, do you need any Replication solution?
The architectures are different, but the goals are similar. That is, "there is more than one way to skin a cat".
Fault tolerance, in my opinion, is achievable only if you are willing to put nodes in at least 3 separate geographic locations (think flood/tornado/earthquake/etc). Both allow for that. I use the rule of surviving any single-point-of-failure, and include "datacenter" as a point-of-failure.
GR is a significant improvement over Oracle's previous offering, Fabric.
Since you did not mention Sharding, I did not mention it.
MySQL Cluster
The term "MySQL Cluster" is confusing; technically it refers to "NDB Cluster", which is significantly different than "Group Replication" aka "InnoDB Cluster".
NDB is discussed briefly by Ibrahim, but I would not go so far as to say "best solution ever".
NDB was originally a telco application for very reliable handling of telephone switching. MySQL, Oracle, and SeveralNines have enhanced it _to be somewhat closer to a general RDBMS. It retains its high reliability.
I would limit the use of NDB to applications that need the specific features that it provides.
Advice
For someone starting in the database world with MySQL, I would go with a non-replicated InnoDB-based dataset. When replication / HA / scaling are needed, consider Group Replication or Galera. Move to NDB only if it fits your application better.