Using Ubuntu Server 14.04.1 and Percona XtraDB 5.6.20-68.0-56.
When the cluster is running with all three servers and we do a set of inserts (~800,000 of them) we see
a through put of around 150 inserts/second.
If I shut down servers two and three and now run the same transactions we see a through put of 6,000
to 12,000 inserts/second. It jumps around a bit.
It just seems wrong for the cluster to be that much slower. My my.cnf from the first server is below.
All three servers are the same, Intel Xeon E3-1270 @ 3.5Ghz, 32 Gb memory, and a single 256
Samsung SSD, dual gigabit nics bonded in balance-rr mode and all on the same gigabit switch.
Any thoughts are deeply appreciated
Larry
[mysqld]
datadir=/var/lib/mysql/
user=mysql
#Skip reverse DNS lookup of clients
skip-host-cache
skip-name-resolve
Have all the nodes identical MySQL configuration? Can you see any network related errors, maybe double check bonding properties?
Also what if you do asynchronous replication from this node that is capable of doing over 6k inserts/s to the two other nodes - do they keep up with replication?
I can see there is some fundamental confusion here about how Galera works and what is the difference between traditional asynchronous MySQL replication and Galera replication.
Ovi, this is not entirely true about PXC/Galera being asynchronous by default. The way Galera based replication (so the one existing in PXC) is completely different from the way how MySQL replication (available since very early MySQL days) works.
Galera is synchronous in a meaning that each transaction must reach all the nodes on commit, and only applying those transactions against real data is later asynchronous. In the same time, cluster won’t allow any node to stay too much behind in applying transactions, and will pause if there is a need. This is also called “virtually synchronous”. Please read the first chapter here:
[url]http://galeracluster.com/documentation-webpages/[/url]
Also this is true that enabling wsrep_sync_wait forces kind of full synchronous mode, however this makes sense in only very special use cases.
Now the standard MySQL replication, regardless what topology you will choose, so whether it will be master->slave or master<->master, is completely asynchronous and also does not have mechanism to take care about what the slaves are doing (with small exception of semi-sync mode). In standard replication, the slaves are allowed to be lagged in replicating from master and the master does not really care about that.