A little test with galera vs. semisync
erkan yanar
galera with semisync-repl.
A simple test just inserting 100.000 rows in different concurrencies is shown here
http://linsenraum.de/erkules/2011/06/momentum-galera.html
Just take a look for the graph, as the blog is in german:/
Of course galera is offering more than traditional replication. But it is great to see
galera even tops the most advanced (regarding HA) replicationtechnique of MySQL \o/
regards
erkan
--
�ber den grenzen muss die freiheit wohl wolkenlos sein
Alexey Yurchenko
Thanks for posting this. This is perhaps the first independent Galera
benchmark. Even though it is synthetic and simplistic, exactly because
of those properties it gives certain insights.
If I understood correctly, you have not modified any wsrep parameters,
so there was no parallel applying on the slave Galera node. But what
about MySQL 5.5 configuration, specifically
innodb_flush_log_at_trx_commit and sync_binlog? Those two guys could
easily cause 10x performance degradation. Galera does away with them
and, theoretically, MySQL semi-sync could do too.
Also MySQL-5.1.53 uses built-in InnoDB by default. I guess to make
comparison more fair you might want to enable InnoDB plugin there.
Would be great to see the same sort of benchmark against standalone
server and Galera cluster with wsrep_slave_threads=<4*CPU_cores>
Thanks,
Alex
erkan yanar
On Mon, Jul 04, 2011 at 05:48:10PM -0700, Alexey Yurchenko wrote:
> Hi Erkan,
>
> Thanks for posting this. This is perhaps the first independent Galera
> benchmark. Even though it is synthetic and simplistic, exactly because
> of those properties it gives certain insights.
>
> If I understood correctly, you have not modified any wsrep parameters,
> so there was no parallel applying on the slave Galera node. But what
> about MySQL 5.5 configuration, specifically
> innodb_flush_log_at_trx_commit and sync_binlog? Those two guys could
> easily cause 10x performance degradation. Galera does away with them
> and, theoretically, MySQL semi-sync could do too.
5.5 got the same config (regarding innodb) as galera.
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=4G
innodb_log_file_size=100M
innodb_doublewrite=0
innodb_locks_unsafe_for_binlog=1
innodb_autoinc_lock_mode=2
>
> Also MySQL-5.1.53 uses built-in InnoDB by default. I guess to make
> comparison more fair you might want to enable InnoDB plugin there.
So change the defaults;)
It is just a start of comparing them. Having a problem to compare things
hard to compare anyway.
The focus of this test was/is.
Imagine I want to have something that guarantees changes are on the "slave".
I could/would take semisync from MySQL and the galera-package.
Im quite impressed, that galera - even having more features - is much better than MySQL.
>
> Would be great to see the same sort of benchmark against standalone
> server and Galera cluster with wsrep_slave_threads=<4*CPU_cores>
>
As Im going to be on holiday next weeks. I would be glad to test some workloads afterwards.
So you wan't to compare a standalone server against a cluster?
Do you want to show there is (nearly) no overhead using galera?
Do you expect the standalone/galera to have binlog enabled (for pitr)?
regards
erkan
--
�ber den grenzen mu� die freiheit wohl wolkenlos sein
Alexey Yurchenko
> 5.5 got the same config (regarding innodb) as galera.
concurrent replication, that is, it can replicate only one transaction
at a time. Which is no surprise given that semi-sync seems to be a
hack over the regular asynchronous MySQL replication, but that would
make it unsuitable for use in WANs (where you will have this infamous
rate=1/RTT law)
This is just an educated guess, however. We didn't have time to look
into how MySQL semi-sync works, and hardly will ever have (for obvious
reasons ;)). Once again, thanks for doing it.
> > Also MySQL-5.1.53 uses built-in InnoDB by default. I guess to make
> > comparison more fair you might want to enable InnoDB plugin there.
>
> So change the defaults;)
have not make it a default, perhaps that's for a reason...
> So you wan't to compare a standalone server against a cluster?
> Do you want to show there is (nearly) no overhead using galera?
increased CPU usage and replication latencies. Yet, comparing cluster
to standalone server at a low number of connections (1, 2, 4, 8 -
before CPU saturation) would allow to see how replication latency
compares to that of client-server communication. There is a common
concern that in synchronous replication the latency would
significantly impact the performance. I suspect that in most use cases
replication latency must be not that high compared to the overall
transaction execution time. It'd be interesting to see how it goes in
your environment.
> Do you expect the standalone/galera to have binlog enabled (for pitr)?
replication performance, so I would use the same innodb settings even
though it is unsafe in case standalone server.
Regards,
Alex
Alexey Yurchenko
Well, then your results suggest that MySQL semi-sync is incapable of
concurrent replication, that is, it can replicate only one transaction
at a time. Which is no surprise given that semi-sync seems to be a
hack over the regular asynchronous MySQL replication, but that would
make it unsuitable for use in WANs (where you will have this infamous
rate=1/RTT law)
Well, now with http://www.mysqlperformanceblog.com/2012/06/14/comparing-percona-xtradb-cluster-with-semi-sync-replication-cross-wan/ we have quite a solid confirmation to this hypothesis.
