Falls die Binlogs zu viel Platz wegnehmen, kann man mit Hilfe des MySQL Befehls
PURGE BINARY LOGS TO ‚mysql-bin.01234‘;
alte Binlogs löschen. Dabei werden alle Binlogs bis zum angegebenen gelöscht (das bleibt also erhalten). Sauberer als die Logs einfach im Logordner zu löschen, da so auch der Dienst vom Löschen erfährt.
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
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“
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.“
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
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.
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.
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 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.
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.
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):
Die Werte dabei sind in keiner Weise kritisch, verdeutlichen aber den Unterschied.
update: Eventuell kann ein zu niedriger Wert negative Auswirkungen auf Replikationen haben
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/
Um bei Galera 2.2 mehre Nodes als „first connect“ anzugeben, reicht es die IPs durch Komma getrennt in die wsrep.cnf einzutragen.
wsrep_cluster_address="gcomm://192.168.178.10,192.168.178.11,192.168.178.12"
Ob Galera prüft ob die Nodes tatsächlich aktiv im Cluster sind, muss noch getestet werden. Ich gehe aber davon aus. Dies ist eine der sinnvollsten Verbesserungen der neuen Version.
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.
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:
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.
Galera 23.2.2 ist offiziell released. Einige Änderungen hören sich ganz gut an z.B.
ability to specify several node addresses in gcomm:// URL.
So spart man sich auf die Reihenfolge beim booten eines Clusters zu achten.