MySQL 5.5 Replikation

Bei MySQL 5.5 haben sich 1-2 Sachen im Bezug auf die „normale“ Replikation geändert:

master-host
master-user
master-password
master-port

werden nicht mehr in der my.cnf gesetzt, sondern müssen direkt via MySQL gesetzt werden. Das fällt schnell auf, da MySQL ansonsten mit

unknown variable master-host

den Start verweigert.

Ansonsten alles wie immer:

Master:

create user 'slave_user'@'slavehost' identified by 'slavepassword';
GRANT REPLICATION SLAVE ON *.* to 'slave_user'@'slavehost' identified by 'slavepassword';
GRANT REPLICATION CLIENT ON *.* to 'slave_user'@'slavehost' identified by 'slavepassword';
FLUSH PRIVILEGES;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
UNLOCK TABLES;

Slave:

change master to  MASTER_HOST='masterhost', MASTER_PORT=3306, MASTER_USER ='slave_user', MASTER_PASSWORD='slavepassword', MASTER_LOG_FILE='mysql-bin.000045', MASTER_LOG_POS=730;
START SLAVE;
SHOW SLAVE STATUS \G;

Das GRANT REPICATION CLIENT ist nicht unbedingt nötig. Tatsächlich sind das sinnige Änderungen, auch wenn es sich nicht sofort erschließt.

Linux Cluster Management Console

Für zwischendurch.

Linux Cluster Management Console is a GUI that helps to configure Pacemaker, DRBD and KVM clusters.

Damit ist eigentlich alles gesagt. Habe ich nicht zum Einrichten von Pacemaker genutzt, ist aber nett um sich das Ergebnis anzuschauen. Bei größeren Umgebungen, kann so ein Tool sicherlich sehr nützlich sein. Bei mir läuft auf den Nodes nur Pacemaker&co und glbd als MySQl Proxy. Bei der 1.3er Version war das Anlegen der Hosts nicht besonders intuitiv, vielleicht ist es bei der neuen 1.4er verbessert worden. DRBD ist natürlich nicht nötig, aber möglich.

httpvh://youtu.be/nEPn5RJA1Ig

p.s. damit teste ich auch gleich mal ob der osbn feed funktioniert

Galera cluster_size Nagios check

Ein kleiner Nagios Check für MySQL / Galera.  Die Variable wsrep_cluster_status habe ich nur als zusätzliche Information mit rein genommen. Sobald mehr Zeit, erweitere ich das um die anderen wichtigen Variablen ( wsrep_ready, wsrep_connected, wsrep_flow_control_paused usw.)  und unterscheide ein paar mehr Fälle. Natürlich sind mit dem Skript kaum Fälle abgefangen, aber für so auf die schnelle funktioniert es. Nett wäre es, wenn die Galera Leute direkt ein Plugin zur Verfügung stellen würden, die kennen sich immerhin am besten damit aus.

#!/bin/bash
if [ $# != 1 ]; then
 echo "Bitte Anzahl der erwarteten MySQL Galera Nodes angeben"
 exit 1
else

 mysqlhost=127.0.0.1
 port=3306
 mysqluser=mysqluser
 password=mysqlpassword
 gstat1=$(mysql -h$mysqlhost -P$port -u$mysqluser -p$password -e "show status like 'wsrep_cluster_size'"|grep wsrep_cluster_size|cut -f 2)
 gstat2=$(mysql -h$mysqlhost -P$port -u$mysqluser -p$password -e "show status like 'wsrep_cluster_status'"|grep wsrep_cluster_status|cut -f 2)

  if [ $gstat2 == "Primary" ]
   then
    if [ "$gstat1" == "$1" ]
     then
     echo "OK wsrep_cluster_size:$gstat1 wsrep_cluster_status:$gstat2"
     exit 0
    else
     echo "Achtung wsrep_cluster_size:$gstat1 wsrep_cluster_status:$gstat2"
     exit 1
    fi
  else
   echo "Achtung wsrep_cluster_status:$gstat2"
   exit 2
  fi
fi

Link:
http://www.codership.com/wiki/doku.php?id=monitoring&s[]=monitoring

Galera Cluster mit Ubuntu 12.04 64bit und MySQL 5.5 – Teil 2 Loadbalancer/Proxy

Nun da Galera mittlerweile auf vier Nodes läuft, wäre ein Loadbalancer eine gute Sache. HAProxy fand ich etwas zu mächtig für mein Anliegen, obwohl er  von vielen Benutzern als Option präferiert wird . Getestet habe ich mysql-proxy direkt von Mysql und glbd von Galera. Beides scheint größtenteils problemlos zu laufen. Bei einfachen Benchmarks, konnte ich bisher keine gravierenden Unterschiede erkennen, dazu aber mehr in Teil 4. Mysql-proxy ist seit längerer Zeit im Alphastatus und glbd liegt in der Version 0.7.5 vor. Also beides ausbaufähig ;-). Mein Favorit ist glbd, weil er genau das tut, was er soll und nicht unnötig viele Einstellung benötigt oder bietet. Die Syntax ist recht einfach:

glbd --daemon --threads 8 --control 127.0.0.1:4041 123.123.123:4040 node1:3306:3 node2:3306:3 node3:3306:3 node4:3306:1 

Ein –help zeigt alle Optionen:

glbd --help
Usage:
glbd [OPTIONS] LISTEN_ADDRESS [DESTINATION_LIST]
OPTIONS:
--help                  this help message.
--daemon                run as a daemon.
--fifo <fifo name>      name of the FIFO file for control.
--control [HOST:]PORT   listen for control requests on this address.
--threads N             number of working threads (connection pools).
--source_tracking       turn on source tracking: route connections from one
source to the same destination.
--verbose               turn on verbose reporting.
--version               print program version.
LISTEN_ADDRESS:
[IP:]PORT               where to listen for incoming TCP connections.
DESTINATION_LIST:
[H1[:P1[:W1]]] [H2[:P2[:W2]]]...  - a space-separated list of destinations
in the form address:port:weight.

Die Optionen nach Bedarf anpassen. Meiner Meinung nach empfiehlt es ich das weight eines nodes relativ niedrig anzusetzen. Dieser kann dann primär für Backups oder als Donor  fuer zusätzliche Nodes dienen, da er während des Syncs mit einem neuen Node im readonly mode ist. Statusabfragen von glbd macht man z.B. mit:

# echo "getinfo" | nc -q 1 127.0.0.1 4041
Router:
----------------------------------------------------
Address       :   weight   usage   conns
node1:3306  :    3.000   0.000     0
node2:3306  :    3.000   0.000     0
node3:3306  :    3.000   0.000     0
node4:3306  :    1.000   0.000     0
----------------------------------------------------
Destinations: 4, total connections: 0

Weiter Informationen finden sich im Readme.  Sehr gute Informationen und eine deutlich detaillierte Anleitung zu glbd findet man unter fromdual.com/mysql-and-galera-load-balancer. Dort ist auch ein Skript hinterlegt um glbd zu administrieren. Bricht ein Node weg, leitet glbd die Anfrage transparent an einen verfügbaren Node weiter. Leider ist die Dokumentation von glbd etwas dürftig, daher werden sich viele Verhaltensweisen erst im Laufe von diversen Tests zeigen. Probleme können eventuell auftauchen wenn man mit Pacemaker/Corosync arbeitet, da glbd sich (zu Recht) weigert,  an ein nicht existierendes Interface gebunden zu werden (Stichwort „crm colocation“), dazu mehr in Teil 3.

Mysql-Proxy ist als Paket bei Ubuntu 12.04 dabei, zwar „nur“ die 0.8.1, dafür  genießt man die Vorteile der Paketverwaltung. Konfiguriert wird mysql-proxy in der

/etc/default/mysql-proxy:

ENABLED="true"
OPTIONS="--proxy-skip-profiling --proxy-address=123.123.123.123:4040 --proxy-backend-addresses=node1:3306 --proxy-backend-addresses=node2:3306 --proxy-backend-addresses=node3:3306 --proxy-backend-addresses=node4:3306 --admin-username=superadmin --admin-password=imnotshyijustdontlikeu --admin-lua-script=/usr/lib/mysql-proxy/lua/admin.lua"

Damit läuft  erst mal die Proxyfunktion. Mysql-proxy kann deutlich mehr als nur  Proxy sein. So kann er zum Beispiel die Mysqlanfragen nach read-write selektieren und mit der --proxy-read-only-backend-addresses Option auf dedizierte Readonly „Slaves“ leiten. Die Dokumentation ist sehr gut, dank auch der  MySQL Integration. MySQL Anfragen können mit Hilfe von Lua Skripten direkt manipuliert  werden. Zum lesen nochmal zwei Links zu mysql-proxy, hier und hier. Der Beitrag von mysqlperformanceblog.com  ist von Juni 2009, daher wurde noch die 0.7.1 getestet. Zu eigenen Benchmarks komme ich in Teil 4.

Ob nun glbd, mysql-proxy, pen oder haproxy, hängt vom Einsatzzweck und System ab. Sicherlich gibt es noch etliche andere Lösungen für ein Mysql Proxy/Loadbalancer Szenarien. Schaut man sich kommerzielle Anbieter an, wird man sicherlich hinter all den Webinterfaces, Firmenlogos und Gedöhns, häufig ein Programm aus der Open Source Welt finden, was dort still und unscheinbar seinen Dienst verrichtet. Teil 3 handelt von Pacemaker und IP Failover und Teil 4 schließlich von Benchmaks zu unterschiedlichen Konfigurationen. Ein wesentlicher Faktor beim Einrichten einer solchen Umgebungen ist natürlich die Zeit, die man dafür zur Verfügung hat. Sollte ich komplett auf dem Holzweg sein, sind Kommentare natürlich willkommen, ansonsten natürlich auch.

Link zu Teil 1:

http://exdc.net/2012/08/06/galera-cluster-mit-ubuntu-12-04-64bit-und-mysql-5-5-teil-1/

Galera Cluster mit Ubuntu 12.04 64bit und MySQL 5.5 – Teil 1

Warum  Ubuntu? Weil ich mal etwas einigermaßen aktuelles Testen wollte ;-). Tatsächlich lief mein erster Test mit Galera und MySQL 5.1 unter drei Debian Nodes ohne großen Aufwand. Ich beschränke mich auf die Installation des ersten Nodes, da die Installation eines weiteren Nodes nur minimal abweicht. Zum Testen sollte man 3-4 Maschinen zur Verfügung haben.

Einige Daten über Galera von der Entwicklerseite:

MySQL/Galera is synchronous multi-master cluster for MySQL/InnoDB database, having features like:

  • Synchronous replication
  • Active-active multi-master topology
  • Read and write to any cluster node
  • Automatic membership control, failed nodes drop from the cluster
  • Automatic node joining
  • True parallel replication, on row level
  • Direct client connections, native MySQL look & feel

Benefits

These features yield un-seen benefits for a DBMS clustering solution:

  • No slave lag
  • No lost transactions
  • Both read and write scalability
  • Smaller client latencies

Von codership.com/products/mysql_galera die benötigten Pakete laden, zur Zeit:

galera-23.2.1-amd64.deb
mysql-server-wsrep-5.5.23-23.6-amd64.deb

Das System vorbereiten:

aptitude install libaio1 libssl0.9.8 libdbi-perl libdbd-mysql-perl mysql-client libmysqlclient18 mysql-common libplrpc-perl libnet-daemon-perl

Galera und Mysql installieren:

dpkg -i galera-23.2.1-amd64.deb mysql-server-wsrep-5.5.23-23.6-amd64.deb

In der /etc/mysql/my.cnf

bind-address           = 127.0.0.1

anpassen bzw. auskommentieren.

Mysql starten

/etc/init.d/mysql start

mysqladmin -u root password 'superpassword'

mysqladmin -u root -p -h hostname password 'superpassword'

Ich habe einen User fuer die Repliaktion auf jedem Node angelegt. Zum testen kann man natürlich auch einfach den Mysqladminuser nehmen


mysql> SET wsrep_on = OFF; grant all on *.* to replikator@'%' identified by 'thisisnotfacebookandimnotyourfriend';

In der /etc/mysql/conf.d/wsrep.cnf

# Full path to wsrep provider library or 'none'
#wsrep_provider=none
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Logical cluster name. Should be the same for all nodes.
wsrep_cluster_name="imnotshyijusdontlikeyou_cluster"

# Group communication system handle
wsrep_cluster_address="gcomm://" #Dies nur beim ersten Server, bei den anderen trägt man dort die Adresse eines anderen Nodes ein. Spaeter sollte man die IP auch beim ersten Node anpassen

# Group communication system handle# SST authentication string. This will be used to send SST to joining nodes.
# Depends on SST method. For mysqldump method it is root:
wsrep_sst_auth=replikatior:thisisnotfacebookandimnotyourfriend #hier muss natuerlich ein user mit den benötigten Rechten eingetragen werden, im Zweifel root

wsrep_cluster_address sollte später nicht leer bleiben.

Danach

/etc/init.d/mysql restart 

Am besten tail -f /varlog/syslog auf den einzelnen Maschinen laufen lassen um zu schauen ob Fehler auftauchen. Zum testen Datenbanken auf den einzelnen Nodes anlegen und mit Daten füllen.

Größtenteils habe ich mich an http://blog.causal.ch/2012/02/installing-mysql-galera-on-debian-60.html orientiert. Empfehlen kann man natürlich generell die Galera Seite und den Artikel im Admin -Magazin 04/2012 über Galera Cluster für Mysql. Die einzelnen Optionen in der/etc/mysql/conf.d/wsrep.cnf sollte man sich nochmal genauer anschauen.    Teil 2 folgt dann (hoffentlich) mit garbd, pen, HAproxy, Splitbrain Problem und ein-zwei mehr Erfahrungen.

mysql logs und Replikation

Kommt man in die Situation, dass man raus finden will, was man denn nun genau fuer Mysql Kommandos in den letzten Tagen so ausgefuehrt hat, helfen die binlog Dateien in /var/log/mysql/.

mysqlbinlog mysql-bin.000001

Vorausgesetzt man nutzt log_bin und  STATEMENT als logging Format in der my.cnf . Vorher aber den Zeitstempel der Logdateien anschauen, um die Datensuche etwas einzugrenzen. Nutzt man row-based als Replikationsvefahren hat man keine  Logdateien zum ueberpruefen. Die Frage ob man nun row-based oder statement-based als Verfahren nutzt ist eine andere.  Beide Verfahren, row- und statement-based, haben Ihre Vor- und Nachteile. Man kommt also nicht drumherum sich damit etwas ausgiebiger zu beschaeftigen.

Links zum Thema row-based Replkation:

http://www.databasejournal.com/features/mysql/article.php/3922266/Comparing-MySQL-Statement-Based-and-Row-Based-Replication.htm

http://dev.mysql.com/doc/refman/5.1/de/replication-row-based.html

http://dev.mysql.com/doc/refman/5.1/en/replication-sbr-rbr.html

http://albertech.net/2011/10/upgrading-debian-lenny-to-squeeze-with-mysql-for-row-based-replication/

http://www.ovaistariq.net/528/statement-based-vs-row-based-replication/

http://www.mysqlperformanceblog.com/2010/05/06/debugging-problems-with-row-based-replication/

MyISAM zu InnoDB

Die DB fuer den Blog von MyISAM auf InnoDB umgestellt (alter table tablename ENGINE=innodb;) Mal abwarten ob Probleme auftauchen.
Man  muss sich darueber im klaren sein, dass sich durch die Umstellung einiges and der Dateistruktur aendert. Mysql legt die komeplette Datenbank nicht mehr in /var/lib/myql/datenbank ab, sondern splittet sie auf.
Ein einfaches kopieren der Datenbankdateien auf eine andere Maschine, ohne den Weg ueber einen Dump zu gehen, funktioniert dann nicht mehr. Wer das haben will muss

innodb_file_per_table=1

in seine /etc/mysql/my.cnf in die [mysqld] Sektion eintragen und erneut

alter table tablename ENGINE=innodb;

fuer die jeweiligen Tables ausfuehren. Ich muss zu geben, ich habe wenig Ahnung von Mysql und alle Tips, die ich dazu geben, sollten mit Vorbehalt uebernommen werden.

Links:
http://dev.mysql.com/doc/refman/5.1/en/innodb-multiple-tablespaces.html
http://highervisibilitywebsites.com/convert-your-mysql-database-myisam-innodb-and-get-ready-drupal-7-same-time
http://forums.cpanel.net/f43/innodb_file_per_table-converting-per-table-data-innodb-167942.html

Mysql Slave stoppen

Da ich grad bei der Mysqlreplikation Master und Slave gewechselt habe:
um den Slave zu entfernen (die entsprechenden Eintraege der /etc/mysql/my.cnf anpassen):

  1. STOP SLAVE;
  2. RESET SLAVE;

bei show slave status sollte dann nur noch ein

mysql> show slave status\G;
Empty set (0.00 sec)

kommen. Natuerlich auf dem Slave ausfuehren.