Januar 2014 Archive

Was machst Du da?

Ich will wieder anfangen MySQL (besonders) Galera Setups zu ‘benchmarken’. Angefangen wird mit einem einfachen Setup. Die Applikation (sysbench) greift nur auf einen Node des Galera Clusters zu. Das entspricht z.B. einen VIP Setup.

Setup

3 Galera Nodes

  • Virtual Machines (OpenStack) provided by teuto.net
  • VCPU: 4
  • RAM: 4GB
  • OS: Centos 6.4-x86_64
  • MySQL-server-5.6.14wsrep25.1-1.rhel6.x86_64
  • galera-25.3.2-1.rhel6.x86_64

Separater sysbench node

  • Gleiche Specs
  • sysbench 0.5
  • oltp test auf 5 Tabellen a 1000000 Rows (ca. 1.2GB)
  • Jeweils 60 Sekunden Gauss-Verteilter Zugriff.

MySQL Config

[mysqld]
user                          = mysql
binlog_format                 = ROW
default-storage-engine        = innodb

innodb_autoinc_lock_mode      = 2
innodb_flush_log_at_trx_commit= 0
innodb_buffer_pool_size       = 2048M
innodb_log_buffer_size        = 128M
innodb_file_per_table         = 1

query_cache_size              = 0
query_cache_type              = 0
bind-address                  = 0.0.0.0

init_file                     = /etc/mysql/init
max_connections               = 2000

# Galera
wsrep_provider                = "/usr/lib64/galera/libgalera_smm.so"
wsrep_cluster_name            = deadcandance
wsrep_cluster_address         = "gcomm://$useyourown"/
wsrep_slave_threads           =
wsrep_certify_nonPK           = 1
wsrep_max_ws_rows             = 131072
wsrep_max_ws_size             = 1073741824
wsrep_sst_method              = rsync

Tests

Reminder

Es sind nun mal virtuelle Umgebungen. Hier erwarte ich eine höhere Varianz, als richtiger Hardware. Daher sind kleine Differenzen in Puncto Performance zu ignorieren. Das Problem liegt an der Hypervisor Technologie an sich, aber auch daran, dass nicht abzusehen ist, wer in der Cloud gerade wie die Systeme auslastet. Auch haben wir keine Ahnung von dem Storage, Netz etc. etc. etc. :)

1. Test: Wir testen unterschiedliche Werte für wsrep_slave_threads

for i in 1 4 8 16 24 32 48 64; do set wsrep_slave_threads=$i and run; done

galera compared

Das hätte ich nicht erwartet. In einem anderen Test (http://linsenraum.de/erkules/2012/04/galera-4-node-cluster-perfomancetest.html) waren die Unterschiede deutlich zu sehen. Ob es am anderen Testverfahren (oltp) lag oder am virtuellen Environment kann ich derzeit nicht sagen. Aber da haben wir was für neue Tests:)

2. Test: gcs.fc_limit auf 512 erhöhen.

Da wir mit sysbench nur auf einen Node gehen, können wir durch das setzen von gcs.fc_limit etwas am Flow tunen. Siehe: Flow Control.

galera flow_control

Ok der Unterschied ist jetzt ersichtlicher. Schauen wir uns noch die Flow Control Werte im Vergleich an:

galera flow_control

Es ist sehr schön zu sehen, wie durch das Erhöhen des Limits die Galera Replikation seltener gestoppt wird. Andrerseits ist zu sehen, dass die Werte - welche bei 0 liegen sollten - allgemein zu hoch sind. Anders formuliert: Die “Hardware” scheint für diese Tests unterdimensioniert. Grundlegende Eigenschaften sollten aber klar werden.

3. Test

Wir vergleichen (einen der) Galera Läufe mit

  • Einer MySQL Instanz alleine laufend (aber die selbe laxe Konfiguration)
  • Einer MySQL Instanz alleine laufend (mit sync_binlog und innodb_flush_log_at_trx_commit=1)
  • Mit der letzten Konfiguration und einer laufenden semisynchroner Replikation.

Semisynchrone Replikation wird gerne für HA Setups verwendet. Da hier die Vermutung nahe liegt, es würde sichergestellt werden, dass die Daten auf dem Slave ankommen. Dies ist zwar weit gefehlt, aber leider Praxis:

galera flow_control

  • Wir sehen unter anderem den Galera Replikations Overhead.
  • Können es mit einer HA Installation i.e. auf DRBD vergleichen
  • Oder mit der besagten semisynchronen Replikation

Verglichen wir die für ein HA Setup genutzte semisynchrone Replikation mit nun zwei Galera Konfigurationen. Beide haben wsrep_slave_threads=1 und eine zusätzlich gcs.fc_limit=512 gesetzt.

galera flow_control

Das Bild spricht für sich.

Ergo

  • Galera ist schneller
  • Galera ist virtuell synchron
  • Galera bietet Multi-Master (einfaches Failover)
  • Galera garantiert, dass die Daten auf den (beiden) anderen Nodes sind

Fake Semisync

Bei genauerem hinsehen war auch die semisynchrone Replikation mit dem Test überfordert. Während Galera via Flow Control den Durchsatz stoppt fällt die semisynchrone Replikation in den asynchronen Modus zurück.

galera flow_control

:/

Das wars

Das war ein einfaches Setup. Ich habe vor weitere Setups zu testen. Vorschläge werden gerne entgegen genommen. Wer mir echte (RZ) Hardware zur Verfügung stellt, erquickt mich ungemein.

Viel Spaß

Erkan :)

P.S.: Selbstredend werden auch Galera Pakete von MariaDB und Percona benutzt werden :)

Moinsen,
in der ab heute am Kiosk erhältichen iX. Ist ein Artikel über LXC (1.0) von mir erschienen \o/

Wem es gefällt und Bock auf eine Schulung dazu hat: Erkan macht LXC im Linuxhotel 

Viel Spaß
Erkan :)

Zu Galera gibt es viel zu sagen.
Hier möchte ich zwei Begriffe/Phrasen vorstellen, die ich mittlerweile Kunden und Interessierten
aufdrücke.

Galera ist:

  • One Cluster
  • Replication

Hier geht es darum nicht unnötig Werbung für Galera zu machen. Ziel der Schlagworte ist “Limitierungen” zu verdeutlichen. Was meinen diese Schlagworte?

One Cluster

Galera ist ein Cluster. Nodes attachen den Cluster. Anders formuliert: Der langsamste Node führt. Klingt geschwollen, meint aber nur der Cluster ist nicht schneller, als der langsamste Node.
(Alles wird synchron durchgeführt.)

Dies kann auch auf das Netz angewandt werden. Meint: Die langsamste Verbindung führt ;)

Replication

  • Galera bedarf der selben Aufmerksamkeit wie (ROW based) Replication. Vor allem sollten alle Tabellen einen PK haben.
    Ich habe folgenden Featurerequest bei MariaDB eingereicht. Unterstützung/Votes erwünscht :)

  • Galera kennt (nicht ganz streng genommen) keinen Delay. Galera DDLs werden im TOI durchgeführt. (Ist konfigurierbar) Bei der klassischen Replikation führt ein langsames Statement dazu, dass der Slave hinterher hinkt. Der Master ist davon aber nicht betroffen.
    DDLs bringen bei Galera den ( one ) Cluster ;)
    zum stehen. Hint: flow control.

Selbstredend kann gibt es noch weit mehr Phrasen für das Scheunentor, aber das reicht.

Viel Spaß

Erkan

Docker - ein amüsanter LXC Wrapper - erlebt ja einen beängstigenden Zulauf. Folgend ein Dockerfile für MySQL, damit kann sich der geneigte Leser sein Docker Image bauen.

Auch wenn wir auf Docker und Dockerfiles hier nicht eingehen. Der entscheidende Part ist das Erstellen des docker.cnf. Es geht zwar effektiver, aber das Dockerfile soll ja auch die Grundidee vermitteln.

Anpassen nach belieben:

FROM ubuntu
MAINTAINER erkan yanar <erkan.yanar@linsenraum.de>

ENV DEBIAN_FRONTEND noninteractive
RUN apt-get install -y  python-software-properties
RUN apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xcbcb082a1bb943db
RUN add-apt-repository 'deb http://mirror2.hs-esslingen.de/mariadb/repo/10.0/ubuntu precise main'
RUN apt-get update
RUN apt-get install -y mariadb-server
RUN echo "[mysqld]"                       >/etc/mysql/conf.d/docker.cnf
RUN echo "bind-address   = 0.0.0.0"      >>/etc/mysql/conf.d/docker.cnf
RUN echo "innodb_flush_method = O_DSYNC" >>/etc/mysql/conf.d/docker.cnf
RUN echo "skip-name-resolve"             >>/etc/mysql/conf.d/docker.cnf
RUN echo "init_file = /etc/mysql/init"   >>/etc/mysql/conf.d/docker.cnf
RUN echo "GRANT ALL ON *.* TO supa@'%' IDENTIFIED BY 'supa';" >/etc/mysql/init

EXPOSE 3306                                                                                                                                                                                                                
USER mysql
ENTRYPOINT mysqld

Aus dem Dockerfile erstellen wir uns einfach ein Docker Image.

> cat $DOCKERFILENAME | docker build -t mysql -

Der Witz von Docker ist ja die Verwendung von Aufs, das gepaart mit der Geschwindigkeit von LXC ermöglicht hier schnell 51 Container zu starten:

> time for i in $(seq 10 60 ) ; do docker  run -d -p 50$i:3306   mysql ; done
..
real    0m27.446s
user    0m0.264s
sys     0m0.211s

:)

> docker ps | head -2
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS                    NAMES
6d3a5181cd56        mysql:latest        /bin/sh -c mysqld   About a minute ago   Up About a minute   0.0.0.0:5060->3306/tcp   lonely_pare

Viel Spaß :) Erkan

Docker als Wrapper für LXC hat hat einige nette Ideen.
Eine Idee sind die Wegwerfcontainer. Mit lxc-start-ephermal gibt es etwas ähnliches des LXC Projekts, aber das ist imho doof. Da wird der Container ganz gestartet um dann eine Verbindung via ssh aufzubauen um ein Kommando abzusetezen ... Naja

Ok jetzt mal Wegwerfcontainer mit LXC :)

#> mkdir /tmp/diffs                                           
#> mkdir /tmp/clone2                                          
#> vim /tmp/config  # <- 'magische Config'                    
#> mount -t overlayfs -oupperdir=/tmp/diffs,lowerdir=/var/lib/lxc/ubuntu/rootfs none /tmp/clone                                                     
#> lxc-start -n clonewarior -f /tmp/config uptime                                                                                                   
10:05:12 up 5 days,  7:43,  0 users,  load average: 0.00, 0.01, 0.05

Ok nice und nun noch einen weiteren Wegwerfcontainer mit der selben Vorlage :)

#>  mkdir /tmp/diffs2                                         
#>  mkdir /tmp/clone2                                         
#>  vim /tmp/config2  # <-  schon wieder 'magische Config'    
#>  mount -t overlayfs -oupperdir=/tmp/diffs2,lowerdir=/var/lib/lxc/ubuntu/rootfs none /tmp/clone2                                                   
#>  lxc-start -n clonewarior2 -f /tmp/config2 uptime          
10:06:21 up 5 days,  7:44,  0 users,  load average: 0.03, 0.02, 0.05

Selbstredend wieder aufräumen und daraus ein Skript machen etc. \o/

Viel Spaß