regards
erkan
--
�ber den grenzen muss die freiheit wohl wolkenlos sein
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
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)