Kurztipp: MySQL 5.7 Ubuntu 16.04 und max connections werden nicht übernommen

Steht im error.log von MySQL 5.7 etwas in der Art wie:

2018-02-02T13:30:24.539046Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5000)
2018-02-02T13:30:24.539087Z 0 [Warning] Changed limits: max_connections: 214 (requested 800)
2018-02-02T13:30:24.539091Z 0 [Warning] Changed limits: table_open_cache: 400 (requested 1024)

auch diverse Einträge mit „Too many open files“ sind ein Hinweis,

hilft (vielleicht) folgendes

systemctl edit mysql

eintragen:

[Service]
LimitNOFILE=8000

Dadurch wurde nun die Datei /etc/systemd/system/mysql.service.d/override.conf angelegt

systemctl daemon-reload
systemctl restart mysql

Nun sollten die Werte aus der mysqld.conf übernommen werden.

Eventuell nochmal mit

mysql> show variables like '%connections%';

usw. prüfen.

Warum weshalb wieso findet man unter:

https://dev.mysql.com/doc/refman/5.7/en/using-systemd.html

https://stackoverflow.com/questions/39976756/the-max-connections-in-mysql-5-7

https://stackoverflow.com/questions/32760202/buffered-warning-changed-limits-max-connections-214-requested-800/33464069

von 12.04 zu 14.04 und von MySQL 5.5 zu 5.6

Nur ein paar Notizen für mich für ein Update von Ubuntu 12.04 zu 14.04 und von MySQL 5.5 zu 5.6.

MySQL
table_cache gibt es bei MySQL 5.6 nicht mehr, das heißt nun table_open_cache.  Am besten vorher in der my.cnf ändern

ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable
invoke-rc.d apparmor restart
schadet auch nicht.

Pacemaker
apt-get install haveged
braucht man
Pacemaker komplett löschen. Purgen reicht nicht
rm -rf /var/lib/pacemaker
rm -rf /var/lib/heartbeat
rm -rf /var/lib/pengine

Nachdem Update Pacemaker einfach neu installieren. Das sollte inklusive Konfiguration maximal 5 Minuten dauern. Eventuell kurz  root via key zwischen den Nodes erlauben.

update-rc.d pacemaker defaults
kann auch nicht schaden

ssh
Match Blocks werden nicht mehr mit „Match“ geschlossen und müssen immer am Ende der sshd_config  stehen. Eventuell hilft „Match all“

 

 

Kurztipp: proxysql (1.3.4) mit Galera und proxysql_galera_checker.sh

Genauere Informationen zu ProxySQL mit Galera findet man hier. Dort ist auch erklärt wie man das Skript bei proxysql nutzen kann. Das Skript wird vorzugsweise vom ProxySQL Scheduler aufgerufen. Man kann es aber natürlich auch einfach mal auf der Commandline testen.
Meiner Meinung nach wird sich das eh im Laufe der nächsten Versionen nochmal grundlegend ändern. Das ist alles relativ umfangreich,  daher nur ein paar Hinweise.

Das Skript  liegt unter
/usr/share/proxysql/tools/proxysql_galera_checker.sh

Ein Aufruf sieht in etwa so aus

$ ./proxysql_galera_checker.sh 1 0 2 0 /var/lib/proxysql/galerachecker.log

 

Das erste Parameter gibt die Hostgroup für der Writer an, das zweite die Reader Hostgroup. Die 2  ist die Anzahl der genutzten Writers und die letzte 0 gibt an ob Writer auch als Reader agieren sollen wenn sie in der gleichen Hostgroup wie die Reader sind und als letztes Argument der Pfad zum Log.

Schaut man nun in das Logfile findet man folgendes:

Fr 3. Mär 13:22:10 CET 2017 ###### proxysql_galera_checker.sh SUMMARY ######
Fr 3. Mär 13:22:10 CET 2017 Hostgroup writers 1
Fr 3. Mär 13:22:10 CET 2017 Hostgroup readers 0
Fr 3. Mär 13:22:10 CET 2017 Number of writers 2
Fr 3. Mär 13:22:10 CET 2017 Writers are readers 0
Fr 3. Mär 13:22:10 CET 2017 log file /var/lib/proxysql/proxysql_galera_checker.log
Fr 3. Mär 13:22:10 CET 2017 ###### HANDLE WRITER NODES ######
Fr 3. Mär 13:22:10 CET 2017 --> Checking WRITE server 1:galera3:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 1:galera3:3306 is already ONLINE: 1 of 2 write nodes
Fr 3. Mär 13:22:10 CET 2017 --> Checking WRITE server 1:galera4:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 1:galera4:3306 is already ONLINE: 2 of 2 write nodes
Fr 3. Mär 13:22:10 CET 2017 ###### HANDLE READER NODES ######
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera1:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 0:galera1:3306 is already ONLINE
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera2:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 server 0:galera2:3306 is already ONLINE
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera3:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 Changing server 0:galera3:3306 to status OFFLINE_SOFT. Reason: making ONLINE writer node as read OFFLINE_SOFT as well because writers should not be readers
Fr 3. Mär 13:22:10 CET 2017 --> Checking READ server 0:galera4:3306, current status ONLINE, wsrep_local_state 4
Fr 3. Mär 13:22:10 CET 2017 Changing server 0:galera4:3306 to status OFFLINE_SOFT. Reason: making ONLINE writer node as read OFFLINE_SOFT as well because writers should not be readers
Fr 3. Mär 13:22:10 CET 2017 ###### SUMMARY ######
Fr 3. Mär 13:22:10 CET 2017 --> Number of writers that are 'ONLINE': 2 : hostgroup: 1
Fr 3. Mär 13:22:10 CET 2017 --> Number of readers that are 'ONLINE': 2 : hostgroup: 0
Fr 3. Mär 13:22:10 CET 2017 ###### Loading mysql_servers config into runtime ######

Wir haben also 4 Nodes,  Galera3  und 4 aus Hostgroup 1 werden zu Writern und Galera1 und 2 aus Hostgroup 0 werden zu Readern. Galera3 und 4 sind auch in Hostgroup 1, dort werden sie aber Aufgrund des „writes should not be readers“ Arguments deaktiviert.

Wichtig dabei ist:

„…ProxySQL uses a chain of query rules to figure out the routing. If none of the rules apply to a query, query will be routed to the default hostgroup for the user, which created the connection.“

https://severalnines.com/blog/how-proxysql-adds-failover-and-query-control-your-mysql-replication-setup

Das ganze Konstrukt ergibt quasi nur Sinn wenn man auch mit query rules arbeitet.  So kann man aber „bequem“ read/write Anfragen skalieren und die volle Kapazität des Clusters nutzen.

So eine richtige Meinung zu ProxySQL habe ich noch nicht. Diese Sache mit den Hostgruppen finde ich jedenfalls ziemlich gut.  Ob  nun MaxScale oder ProxySQL die bessere Lösung ist kann ich nicht ohne weiteres sagen, sondern das hängt sicherlich von der jeweiligen Anforderung ab.  Für genauere Aussagen müsste man sich das mal in einer Produktivumgebung anschauen und sich ausführlicher mit den beiden Tools beschäftigen. Die Lizenz von ProxySQL ist natürlich deutlich sympathischer.

Link:
http://www.proxysql.com/compare

 

Kurztipp: ProxySQL…missed 3 heartbeats

Tauchen bei ProxySQL in der Logdatei immer wieder Einträge in der Art

...MySQL_Monitor.cpp:1126:monitor_ping(): [ERROR] Server db7:3306 missed 3 heartbeats, shunning it and killing all the connections

auf, liegt es eventuell daran, dass kein mysql-monitor_username mit dem mysql-monitor_password auf den Nodes eingerichtet ist.  Als Folge davon unterbricht ProxySQL die Verbindung zu den Nodes. Einfach mal bei ProxySQL schauen was dort eingetragen ist. Default ist monitor/monitor (jedenfalls in der 1.3.3er).

mysql> SELECT * FROM global_variables WHERE variable_name IN ('mysql-monitor_username','mysql-monitor_password','mysql-monitor_connect_interval','mysql-monitor_ping_interval','mysql-monitor_history');

+--------------------------------+------------------+
| variable_name                  | variable_value   |
+--------------------------------+------------------+
| mysql-monitor_connect_interval | 60000            |
| mysql-monitor_history          | 600000           |
| mysql-monitor_password         | monitor          |
| mysql-monitor_ping_interval    | 10000            |
| mysql-monitor_username         | monitor          |
+--------------------------------+------------------+
5 rows in set (0.01 sec)


Ändern kann man das Passwort einfach mit

mysql> UPDATE global_variables SET variable_value="GEHIRNSABOTAGE" WHERE variable_name="mysql-monitor_password";
Query OK, 1 row affected (0.00 sec)

mysql> LOAD MYSQL VARIABLES TO RUNTIME;
Query OK, 0 rows affected (0.00 sec)

mysql> SAVE MYSQL VARIABLES TO DISK;
Query OK, 46 rows affected (0.00 sec)

und fertig. Der Monitoraccount muss natürlich auch auf den Nodes eingetragen werden. Dann sollten auch Tests mit Sysbench & Co funktionieren.

Über

http://proxysql.blogspot.de/2015/09/proxysql-tutorial-setup-in-mysql.html

bin ich drauf gekommen.

Kurztipp: MySQL Benutzer Connections beschränken

Die Anzahl der Connections kann man einfach global über die my.cnf beschränken.

max_connections = 500

Man kann auch pro Benutzer diverse Limits setzen (Connections pro Stunde, Updates pro Stunde usw.).

Will man einfach generell für jeden Benutzer ein Connection Limit setzten tut es der Eintrag

max_user_connections = 400

in der my.cnf. Der sollte natürlich unter der Anzahl von max_connections liegen, damit eine falsch konfigurierte Anwendung nicht die gesamte Anzahl der Connections belegt. Nach der Änderung natürlich den Dienst neu starten. Zur Laufzeit geht es auch via mysql mit

mysql> set global max_connections = 500;

mysql> set global max_user_connections = 400;

Mit

mysql> show variables like "%connections";


+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| max_connections        | 500 |
| max_user_connections   | 400 |
+----------------------+-------+

kann man nochmal die Einstellung überprüfen. Die Werte sind natürlich nur Beispiele und sollten je nach System angepasst werden.

 

 

 

 

 

Kurztipp: MySQL auf eine andere Partition verschieben (Debian 7)

Montag im Büro und die Data Partition eines MySQL Servers ist fast voll gelaufen.

0. Neue (LVM) Partiton einbinden.

1. Rsync des Datadirs

rsync -avh --progress --stats /var/lib/mysql/ /mnt/mysql/data/

2. MySQL stoppen

3. nochmal rsync

rsync -avh --progress --stats /var/lib/mysql/ /mnt/mysql/data/

4. Verschieben des alten Datadirs und Symlink anlegen

mv /var/lib/mysql /var/lib/mysql_old
ln -s /mnt/mysql/data /var/lib/mysql

5. MySQL starten und fertig

6. Irgendwann mal das mysql_old löschen

Schöner ist natürlich man ändert die Pfade in der my.cnf, aber manchmal muss es einfach schnell gehen. Falls man Apparmor nutzt, anpassen der Pfade nicht vergessen.

MySQL Master <-> Master Replikation aufsetzen

MySQL kann keine Master <-> Master Replikation. Wir machen das trotzdem mal mit Ubuntu 12.04 und MySQL 5.5 und hoffen, dass es funktioniert und wir in keine Split Brain Situation laufen. Wir sprechen der Einfachheit halber von db1 und db2 als unterschiedliche MySQL Server Instanzen.

Wir legen auf db1 einen Benutzer mit Replikationsrechten an

GRANT REPLICATION SLAVE , REPLICATION CLIENT ON * . * TO 'repuser'@'%' IDENTIFIED BY 'superpassword'; 

Jetzt passen wir die beiden MySQL Konfigurationen an. log_bin muss auf beiden natürlich aktiviert sein.

my.cnf auf db1:

server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
auto-increment-increment = 2
auto-increment-offset = 2

my.cnf auf db2:

server-id               = 2
log_bin                 = /var/log/mysql/mysql-bin.log
auto-increment-increment = 1
auto-increment-offset = 2

Diese auto-increment Optionen dienen dazu, dass es keine Probleme bei Primärschlüsseln, die automatisch hochgezählt werden, gibt.

Jetzt sind wir Faul. Wir stoppen MySQL auf db1 und db2.

$ service mysql stop

Dann löschen oder verschieben wir das MySQL Datadir auf db2. Default liegt das in /var/lib/.

Dann auf db1 als root:

$ rsync -avh --progress --stats /var/lib/mysql db2:/var/lib/

Fein, damit haben jetzt beide Instanzen den gleichen Datenbestand. Da wir als root kopiert haben sollten die Dateirechte stimmen.
Nun starten wir beide Instanzen

$ service mysql start

Wir connecten uns via mysql auf db1 und db2 und schauen mit

mysql> SHOW MASTER STATUS\G
*************************** 1. row ***************************
            File: mysql-bin.000003
        Position: 107
    Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

an welcher Stelle sich db1 und db2 befinden und merken uns das. Es sollte zu der Zeit niemand anderes auf db1 und db2 arbeiten. Dann gehen wir via mysql auf db1 und tippen folgendes ein

CHANGE MASTER TO MASTER_HOST='db2', MASTER_USER='repuser', MASTER_PASSWORD='superpassword', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=107;

bei den Daten MASTER_LOG_FILE und MASTER_LOG_POS geben wir die Daten ein, die wir vorher bei db2 ausgelesen haben.

Dann sind wir mutig und machen ein

mysql> start slave;

mit

mysql> show slave status\G

schauen wir ob die Replikation läuft. Da sollte dann

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

auftauchen. Nun gehen wir via mysql auf db2 und machen dort das gleiche

CHANGE MASTER TO MASTER_HOST='db1', MASTER_USER='repuser', MASTER_PASSWORD='superpassword', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=107;

MASTER_LOG_FILE und MASTER_LOG_POS ist der „SHOW MASTER STATUS\G“ von db1.

dann starten wir auch dort den slave mit

mysql> start slave;

und schauen mit

mysql> show slave status\G

ob die Slave Prozesse laufen

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Fertig, jetzt testen wir ein bisschen und legen auf beiden MySQL Instanzen Datenbanken und Benutzer und und schauen ob diese repliziert werden.

Bemerkungen:
So geht das theoretisch. Auf Sicherheit wurde kein Wert gelegt, da geht eh jeder einen anderen Weg. Slave_IO_Running, Slave_SQL_Running und Seconds_Behind_Master sollte muss man mit Nagios & Co überwachen. Geschrieben werden sollte immer nur auf eine MySQL Instanz, nicht auf die Idee kommen mit mysql-proxy oder so was ein write scale out umsetzen zu wollen.  Man kann eine Instanz auf read only setzen so verhindert man ungewollte Manipulation auf dem „Slave“. Der Replikationsuser und root dürfen aber schreiben, sollte man im Hinterkopf behalten.  Davor am besten noch pacemaker packen, so das im Notfall problemlos auf den „Slave“ geschwenkt werden kann. Ist man sich sicher was man da tut kann man auch das read only weg lassen. Sollten die Datenbanken irgendwie Inkonsitent werden ist das der Replikation egal solange kein Replikationsfehler geworfen wird.

Mir ist bekannt das es andere und bessere Lösungen gibt, ich wollt es nur mal aufgeschrieben haben.

Bugfix Release für Galera

Es gibt ein Galera Update. Primär ein Bugfix Release. Ein neues Feature klingt aber recht viel versprechend:

„Plus new experimental feature: weighted quorum (lp:1010225). Weight can be an integer in the range 0-255. Nodes with zero weight don’t participate in quorum calculation. By default all nodes have weight 1.“

http://www.codership.com/content/mysql-wsrep-5529-2373-and-galera-2324-released

Updaten lief ohne Probleme.

Kurztipp: zu viele sleeping connections bei MySQL

Hat man zu viele sleeping Connections bei MySQL, hilft eventuell ein Heruntersetzen des Wertes für die wait_timeout Variable. Default ist diese auf stolze 28800 Sekunden gesetzt. Vorher anschauen ob es überhaupt Probleme mit der Anzahl der Connections gibt, denn der Aufbau einer neuen Connection kostet  immer etwas mehr als eine bestehende zu nutzen. Ein einfaches Erhöhen der max_connections Variable ist eventuell sinnvoller. Im laufenden Betrieb kann man den wait_timeout  einfach mit

 mysql> set global wait_timeout = 3600;

hoch setzen. Das ist natürlich nur eine „Schraube“ an der man drehen kann. Je nach Anwendung ist es auch sinnvoll sich die MySQL Einstellungen in der /etc/php5/apache2/php.ini anzuschauen,  also mysql.allow_persistent & co.
Die Auswirkungen der Einstellungen könnten dann z.B. so aussehen (kurz nach 11 Uhr):

screenshot13

Die Werte dabei sind in keiner Weise kritisch, verdeutlichen aber den Unterschied.

 

update: Eventuell kann ein zu niedriger Wert negative Auswirkungen auf Replikationen haben

Nagios Plugin für Galera wsrep_flow_control_paused

Ein sehr (sehr, sehr…) einfaches Plugin für den wsrep_flow_control_paused Wert bei Galera. Vielleicht hilft es irgendwem.

#!/bin/bash
if [ $# != 4 ]; then
        echo "Bitte IP,Port, MySQLuser und Passwort eines Galera Nodes angeben"
        exit 1
else
gstat1=$(mysql -h$1 -P$2 -u$3 -p$4 -e "show status like 'wsrep_flow_control_paused'"|grep wsrep_flow_control_paused|cut -f 2)
 if [ $gstat1 == "0.000000" ]
        then
                echo "OK flow_control_paused:$gstat1 | flow_control_paused=$gstat1"
                exit 0
        else
                echo "Achtung flow_control_paused:$gstat1 | flow_control_paused=$gstat1"
                exit 1
 fi
fi

Die wichtigen Werte findet man unter:
http://www.codership.com/wiki/doku.php?id=monitoring&s[]=monitoring

siehe auch:

http://exdc.net/2012/08/24/galera-cluster_size-nagios-check/
http://exdc.net/2012/09/14/galera-nagios-plugin/

Nagios Plugin Slave Status

Wer ein gutes Nagiosplugin zur Überwachung einer MySQL Slave Instanz sucht, sollte sich mal das Plugin von Claudio Kuenzler unter

http://www.claudiokuenzler.com/nagios-plugins/check_mysql_slavestatus.php

anschauen. Gefällt mir deutlich besser als alle bisherigen Slave Status Plugins, die ich dafür genutzt habe. Alternativ kann man natürlich die Percona Plugins nutzen.  Dazu ist das Plugin noch recht kurz und verständlich geschrieben. Ich teste das mal auf vier Instanzen und falls es gut läuft wird es auch für den Rest genutzt.

Galera Cluster mit Ubuntu 12.04 64bit und MySQL 5.5 – Teil 3 IP Failover

Nun haben wir unseren 4 Node Mysql Galera Cluster (hier sollte man besser eine ungerade Zahl wählen, wegen des Quorum Problems). Wir haben auch einen Loadbalancer auf 2 VMs laufen. Nun wollen wir aber noch einen IP Failover haben, falls eine der LB VMs ausfällt, sei es geplant oder ungeplant. Pacemaker ist meiner Meinung nach ein fantastisches Stück Software. Basis Funktionen, wie IP Failover bekommt man relativ unkompliziert ans Laufen, will man jedoch etwas mehr, wird schnell klar, wie komplex Pacemaker/Corosync ist, aber auch welche sinnvollen Funktionen zur Verfügung stehen. Ich beschränke mich auf das Nötigste, weil ich 1. noch nicht mehr weiß und 2. es für mein Projekt vollkommen ausreicht. Die Links am Ende sollte man sich auf jeden Fall anschauen, ich verspreche es lohnt sich. Ich spare mir in die Tiefe zu gehen, da die angefügten Links eigentlich alles erklären und dies deutlich besser tun, als ich es hier kurz zusammenfassen kann.
Fangen wir also mit den Zutaten an:

  • 3 IPs
  • 2 Server minimum (lb1, lb2)
  • Zeit

Nun gehen wir auf einen der Server, nehmen wir lb1:

aptitude install pacemaker

Danach passen wir /etc/corosync/corosync.conf  an:

interface {
 # The following values need to be set based on your environment
 ringnumber: 0
 bindnetaddr: 123.123.123.0
 mcastaddr: 226.94.1.1
 mcastport: 5405
}

Wobei bindnetaddr ein Netz angibt und keine Rechneradresse. Danach führen wir

corosync-keygen

aus. Das dauert etwas und kann durch etwas i/o beschleunigt werden. Danach

chown root:root /etc/corosync/authkey
chmod 400 /etc/corosync/authkey
scp /etc/corosync/authkey lb2:/etc/corosync/authkey
/etc/init.d/corosync start

Sollte corosync seltsamerweise nicht starten, hat bei mir bei ein reboot geholfen. Wo der Fehler dabei lag, kann ich nicht sagen. Schauen wir uns erst mal den aktuellen Zustand an

crm_mon --one-shot -V

Dabei sollte nicht viel erscheinen.

Legen wir also unsere erste Ressource an:

crm configure primitive FAILOVER-ADDR ocf:heartbeat:IPaddr2 params ip="123.123.123.123" nic="eth0" op monitor interval="10s" meta is-managed="true"

Wobei 123.123.123.123 hier die Cluster IP ist.
Stonit und Quorum brauchen wir bei zwei Hosts eigentlich nicht, besonders wenn beide Maschinen auf gleicher Hardware virtualisiert sind ;-).

crm configure property stonith-enabled=false
crm configure property no-quorum-policy=ignore

Soll die IP automatisch wieder auf den aktiven Host zurückspringen oder beim aktuellen  bleiben?

crm_attribute --type rsc_defaults --attr-name resource-stickiness --attr-value 100

default-resource-stickiness=100 ist vergleichbar mit autofailback=false. Default ist der Wert auf 0 gesetzt, bedeutet die Ressource, bei uns FAILOVER-ADDR, springt automatisch wieder  auf den ursprünglichen Host zurück, sobald dieser verfügbar, bzw. Pacemaker gestartet ist.

Das Thema mit der Stickiness ist etwas komplexer, daher verweise ich auf diesen Link, wo der Punkt ausführlich erklärt wird. Der Punkt ist sehr wichtig, da man eventuell nicht immer will, dass die IP sofort wieder auf den Host zurückspringt der z. B. grad rebootet werden musste.

Verschiebt man die IP jedoch von Hand, setzt Pacemaker eine Location Regel für den jeweiligen Host

crm configure show
...
location cli-prefer-FAILOVER-ADDR FAILOVER-ADDR \
rule $id="cli-prefer-rule-FAILOVER-ADDR" inf: #uname eq lb1
...

Diese muss man dann von Hand wieder löschen. Ansonsten wird die Ressource wieder auf den node aus der Location Regel springen, wenn dieser verfügbar ist.
Ein

crm resource unmigrate FAILOVER-ADDR

Löscht die Location Regel.

Mit

crm configure show

können wir uns die  Konfiguration anzeigen lassen. Und mit

crm_mon --one-shot -V

sehen wir den aktuellen Zustand unseres Pacemaker Systems

crm_mon --one-shot -V
============
Last updated: Fri Nov  2 14:09:16 2012
Last change: Mon Sep 10 13:34:26 2012 via crm_attribute on lb1
Stack: openais
Current DC: lb1 - partition with quorum
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ lb1 lb2 ]

Resource Group: Balancer
FAILOVER-ADDR    (ocf::heartbeat:IPaddr2):    Started lb1
GLBD    (lsb:glbd):    Started lb1

Nun testen wir mit

crm resource migrate FAILOVER-ADDR lb2

Ob sich unsere  Ressource verschieben lässt. Danach sollte in etwa folgendes erscheinen:

crm_mon --one-shot -V
============
Last updated: Fri Nov  2 14:15:16 2012
Last change: Fri Nov  2 14:15:12 2012 via crm_resource on lb1
Stack: openais
Current DC: lb1galera - partition with quorum
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ lb1 lb2 ]

Resource Group: Balancer
FAILOVER-ADDR    (ocf::heartbeat:IPaddr2):    Started lb2
GLBD    (lsb:glbd):    Started lb2

Unsere FAILOVER-ADDR Ressource wurde also erfolgreich auf lb2 migriert. Mit dem Befehl

ip addr show

auf beiden Maschinen, können wir das nochmal unabhängig von Pacemaker überprüfen.
Dies GLBD, was erscheint, kann vorerst ignoriert werden. GLBD ist bei mir der MySQL Loadbalancer, der mit FAILOVER-ADDR zu der Gruppe „Balancer“ hinzugefügt wurde. Wie man den glbd Loadbalancer  mit in das Konstrukt aufnimmt, schreibe ich dann hoffentlich in Teil 4 (Pacemaker, Loadbalancer und Nagios) .

Pacemaker bitte eine ganze Reihe von praktischen Befehlen, Funktionen und Möglichkeiten zum anpassen der Konfiguration. Ich spare mir das mal alles und verweise auf die Links am Ende und auf google.

Link zu Teil 1:
http://exdc.net/2012/08/15/galera-cluster-mit-ubuntu-12-04-64bit-und-mysql-5-5-teil-2-loadbalancerproxy/

Links, die man sich auf jeden Fall anschauen will:
http://earlruby.org/corosync-pacemaker-notes/
http://blog.foaa.de/2010/10/intro-to-pacemaker-on-heartbeat/
http://blog.foaa.de/2010/10/intro-to-pacemaker-part-2-advanced-topics/
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/
http://wiki.techstories.de/display/IT/Pacemaker+HA-Cluster+Schulung+GFU+Koeln

update:

glbd kann sich auch an jedes beliebige Interface binden. Dazu reicht es einfach nur den listening Port anzugeben oder 0.0.0.0:port.