Galera als Replikationsersatz [UPDATE[2]]

2012-03-28T23:05:27Z

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

MariaDB on temporary tables

2011-06-02T21:16:07Z

MariaDB soll laut folgender Page bei temporay tables schneller sein als MySQL. Da:

Our use of the Aria storage engine enables faster complex queries (queries which normally use disk-based temporary tables). The Aria storage engine is used for internal temporary tables, which should give you a speedup when doing complex selects. Aria is usually faster for temporary tables when compared to MyISAM because Aria caches row data in memory and normally doesn't have to write the temporary rows to disk.

Um dies zu testen wurden folgende Versionen installiert:

MySQL 5.5.12
MySQL 5.1.57
MariaDB 5.2.6
MariaDB 5.1.55

Es wurden zwei Tabellen mit jeweils 10000 Rows erstellt:

mysql> desc sort_id;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id    | int(11) | YES |     | NULL    |       |
+-------+---------+------+-----+---------+-------+
1 row in set (0.00 sec)

mysql> desc sort_1;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| id    | int(11) | YES |     | NULL    |       |
| tea   | text    | YES |     | NULL    |       |
+-------+---------+------+-----+---------+-------+
2 rows in set (0.00 sec)

Auf allen Servern wurde zudem tmp_table_size auf 1024 gesetzt um Temptables schnellstmöglich zu erzwingen.
Daraufhin wurde mit mysqlslap die Query SELECT * FROM sort_id group by id 20x3 mal ausgeführt. Dies geschah auch für die Tabelle sort_1.
Hier erst mal der EXPLAIN zu den Queries:

mysql> explain SELECT * from sbtest.sort_id group by id\G
*************************** 1. row ***************************
           id: 1
select_type: SIMPLE
        table: sort_id
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10000
        Extra: Using temporary; Using filesort
1 row in set (0.00 sec)

mysql> explain SELECT * from sbtest.sort_1 group by id\G
*************************** 1. row ***************************
           id: 1
select_type: SIMPLE
        table: sort_1
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10000
        Extra: Using temporary; Using filesort
1 row in set (0.00 sec)

Die (aufgehübschte) Ausgabe sah für SELECT * from sort_1 group by id; wiefolgt aus:

Benchmark [[5.5.12]] Average number of seconds to run all queries: 1.803 seconds Minimum number of seconds to run all queries: 1.791 seconds Maximum number of seconds to run all queries: 1.826 seconds Number of clients running queries: 1 Average number of queries per client: 20 Benchmark [[MariaDB 5.2.6]] Average number of seconds to run all queries: 5.547 seconds Minimum number of seconds to run all queries: 5.542 seconds Maximum number of seconds to run all queries: 5.556 seconds Number of clients running queries: 1 Average number of queries per client: 20 Benchmark [[5.1.57]] Average number of seconds to run all queries: 1.605 seconds Minimum number of seconds to run all queries: 1.603 seconds Maximum number of seconds to run all queries: 1.606 seconds Number of clients running queries: 1 Average number of queries per client: 20 Benchmark [[MariaDB 5.1.55]] Average number of seconds to run all queries: 5.283 seconds Minimum number of seconds to run all queries: 5.214 seconds Maximum number of seconds to run all queries: 5.344 seconds Number of clients running queries: 1 Average number of queries per client: 20

Die (aufgehübschte) Ausgabe sah für SELECT * from sort_id group by id; wiefolgt aus:

Benchmark [[5.5.12]] Average number of seconds to run all queries: 1.146 seconds Minimum number of seconds to run all queries: 1.135 seconds Maximum number of seconds to run all queries: 1.170 seconds Number of clients running queries: 1 Average number of queries per client: 20 Benchmark [[MariaDB 5.2.6]] Average number of seconds to run all queries: 4.359 seconds Minimum number of seconds to run all queries: 4.352 seconds Maximum number of seconds to run all queries: 4.366 seconds Number of clients running queries: 1 Average number of queries per client: 20 Benchmark [[5.1.57]] Average number of seconds to run all queries: 1.049 seconds Minimum number of seconds to run all queries: 1.032 seconds Maximum number of seconds to run all queries: 1.068 seconds Number of clients running queries: 1 Average number of queries per client: 20 Benchmark [[MariaDB 5.1.55]] Average number of seconds to run all queries: 4.261 seconds Minimum number of seconds to run all queries: 4.202 seconds Maximum number of seconds to run all queries: 4.341 seconds Number of clients running queries: 1 Average number of queries per client: 20









Nutzt MariaDB wieder die MyISAM-Engine für die temporay tables ist
laut Serg

Golubchik die Performance wieder vergleichbar mit MySQL. Derzeit muss festgehalten werden, dass die Aussage MariaDB sei bei tmp-tables performanter nicht verifiziert werden kann.

Viel Spaß
Erkan

erkules

Galera als Replikationsersatz [UPDATE[2]]

MariaDB on temporary tables