Galera: 4-Node Cluster Perfomancetest [Update]

| Keine Kommentare | Keine TrackBacks
Im letzten Blogpost wurde Galera als Replikationsersatz (im Vergleich zu MySQL 5.5.21 und MariaDB 5.5.20) gemessen.
GroupCommit von MariaDB ist sehr performant und beeindruckend. Der Vergleich zu MySQL ist legitim aber zu Galera unpassend, da Galera eben mehr bietet, als das Ankommen im relay-log eines Slaves.
Folgend wir mit Galera ein 4-Node Cluster aufgebaut. Hier garantiert Galera, dass alle Änderungen auf allen anderen Nodes (im Gegensatz zu Semisync) ankommen und appliziert werden.

Der Test wurde auf einem Knoten der des 4-node Clusters durchgeführt. Im folgenden Blogpost wird auf zwei der vier Knoten der Lasttest durchgeführt.
Galera bietet zwei Kommuniktionsmöglichkeiten der Knoten an.
  1. Unicast
    Das ist der Default
  2. Multicast
    Einfach Konfiguriert mit.

wsrep_provider_options="gmcast.mcast_addr=239.192.0.11"

Das ist der erste Freiheitsgrad unseres Tests, der zweite ist die Anzahl der Applierthreads welcher im Default 1 ist. Gerade Galera ist in der Lage Änderungen parallel zu applizieren, so scheint hier 1 denkbar schlecht. Konfiguriert wird dies mit:

wsrep_slave_threads=64

Achtung: Es scheint, als könnte dies dynamisch geändert werden. SET/SHOW GLOBAL funktioniert einwandfrei. De Facto passiert da nichts.

1. Test Unicast

Galera Unicast

2. Test Multicast

Galera Multicast
Egal ob Multicast oder Unicast 1 Applierthread ist immer die schlechteste Wahl.
In der folgenden Grafik wird die Differenz der beiden Tests abgebildet. Bei positiven Werten ist Multicast schneller, sonst Unicast.
Galera Diff Multi- Unicast
Das Interpretieren überlasse ich dem geneigtem Leser. Comments welcome.

[UPDATE: Hartmut wollte noch einen anderen Graphen haben: ]
. Galera Diff Multi- Unicast

Viel Spaß
Erkan

Keine TrackBacks

TrackBack-URL: http://linsenraum.de/mt/mt-tb.cgi/218

Jetzt kommentieren