Galera als Replikationsersatz [UPDATE[2]]

Es wird wieder Zeit, sich mit Galera zu beschäftigen. Den Auftakt von mehreren Posts zu Galera macht eine Wiederholung des Tests aus einem früherem  Blogpost. Diesmal mit aktuellen Versionen (MySQL 5.5.21, MariaDB 5.5.20, Galera(MySQL 5.5.21 mit 23.2.1beta ).

Hardware:

• 2xQuadcore X5550
• 96GB Ram
• Raid10 XFS

Idee:

innodb_buffer_pool_size     = 8GB
innodb_buffer_pool_instances= 8
innodb_purge_threads        = 1
innodb_log_file_size        = 128M
innodb_log_files_in_group   = 3
innodb_file_per_table
innodb_adaptive_flushing    = 1
innodb_io_capacity          = 1000
innodb_doublewrite=0
innodb_locks_unsafe_for_binlog=1
innodb_autoinc_lock_mode=2

Konfiguration Galera:

wsrep_slave_threads=64

Das ist die Anzahl der 'Applierthreads' für Galera.

Verwendet wurde diesmal sysbench. So wurde der Test mit 10 Tabellen a 50000 Rows durchgeführt.
Für einen schnellen Test wurden je 100.000 Transaktionen mit einer Concurrency von 1,8,16,32,64,128, 256 und 512 gefahren.
Eine Transaktion bestand schlicht aus:

                 1089 Query     BEGIN
                 1089 Query     UPDATE sbtest7 SET c='25883440901-70070313541-17142115205-43175972628-35853834861-09785327216-66363106714-83869798964-358398406
16-91707322347' WHERE id=25108
                 1089 Query     DELETE FROM sbtest7 WHERE id=24792
                 1089 Query     INSERT INTO sbtest7 (id, k, c, pad) VALUES (24792, 25041, '34062177881-28188734657-68032246195-58652219795-64480874925-94656605
246-86334788207-61788576849-66682272200-23433875748', '11856908939-86365001688-81484136798-76782671560-49448389421')
                 1089 Query     COMMIT

Also einem Update, Delete und Insert (variable Werte). Hier der selbst sprechende Graph:


MySQL 5.5.21 konnte ab einer Concurrency von 128 nicht mehr durchgängig im Semisync-Modus bleiben. Daher bricht hier die Messreihe für MySQL ab. Das Fabelhafte Ergebnis von MariaDB ist dem GroupCommit von MariaDB zu verdanken. [Update: Das hat nichts mit GroupCommit zu tun. Da er hier laut Doku nicht zuschlagen kann.Infos sind im Link gleich im ersten Absatz.] MySQL 5.6.x wird auch  mit einer Implementierung kommen.
Galera schlägt sich hier hervorragend. Gerade wenn man bedenke, dass Galera auch Master-Master ermöglicht und damit HA-Lösungen implementiert werden können, welche eben nicht hoffen müssen, dass zum Zeitpunkt des Failovers Semisync aktiv war. Aber selbst das  würde nur heißen, dass die Daten im relay-log des Slaves sind :)

[UPDATE]
Nach einem Chat mit Alexey von Codership den Entwicklern. Wurde eine Kleinigkeit geändert.



Zum einen wurde Percona XtraDB Cluster genommen (eine Schande, dass Galera nicht im Namen vorkommt, wo es doch das essentielle Bestandteil ist.) zum anderen auf dem "Slave"
SET GLOBAL wsrep_provider_options='gcs.fc_limit=1024; gcs.fc_factor=0.9999;';
gesetzt. Jedes für sich hat zu obigem Performancegewinn beigetragen \o/
(BTW: Es gibt noch vieelllle Stellschrauben :)

[Update2]
Fazit: Galera ist nicht nur eine schnellere Replikationstechnik, sondern liefert auch Master-Master. Eine Schmach sich damit nicht näher zu beschäftigen1

Viel Spaß
Erkan