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:
Wir wollen eine HA-Lösung mit
Replikation aufbauen. Hierfür wird Semisync(MySQL/MariaDB) und Galera genommen.
Es wird der Durchsatz gemessen und verglichen.
Sollte Semisync in async Replikation zurückfallen ist der Lauf
ungültig. Dazu wurde nach jedem Lauf einfach geschaut ob die
Ausgabe von
SELECT VARIABLE_VALUE from
information_schema.global_status where
VARIABLE_NAME='Rpl_semi_sync_master_no_times';
sich erhöht hat. [Update2: Ich habe versäumt zu schauen ob semisync überhaupt läuft. (Rpl_semi_sync_master_status,Rpl_semi_sync_slave_status). Daher waren die Messungen für MariaDB falsch und sind korrigiert worden. Zudem war fälschlicher Weise rpl_semi_sync_master_timeout=40 gesetzt. Das sind 40 Millisekunden :). Der Wert wurde auf den Default 10000 gesetzt. Daher kam es nicht mehr zu Abbrüchen.]
Konfiguration MariaDB/MySQL:
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
Aktuelle Kommentare