Im letzten Schritt findet auch MySQL selbst Eingang in die CIB und wird so zur von Pacemaker verwalteten Ressource. Der Resource-Agent für MySQL ist ein OCF-Agent vom Provider
»heartbeat
«
namens
»mysql
«
. Besondere Bedeutung haben die Parameter, die der Resource-Agent kennt – sie erlauben es, wichtige Parameter für MySQL unmittelbar in Pacemakers CIB zu definieren.
Das folgende Beispiel geht von einem Debian-System aus, bei dem sich
»mysqld.sock und mysql.pid
«
im Ordner
»/var/run/mysql
«
befinden. Das Log-Verzeichnis ist
»/var/log/mysql
«
. Die Konfigurationsdatei heißt
»/etc/mysql/my.cnf
«
– das ist wichtig, weil der MySQL-OCF-RA sie defaultmäßig in
»/etc/my.cnf
«
erwartet und außer einer Fehlermeldung keinen Mucks von sich gibt, wenn er die angegebene Konfigurationsdatei nicht findet. Das MySQL-Binary ist
»/usr/sbin/mysqld
«
. Das
»datadir
«
, in dem MySQL nach seinen Datenbanken sucht, ist wie schon erwähnt
»/mnt/mysql
«
. Unter diesen Voraussetzungen ergibt sich bei Debian diese Ressourcen-Definition für MySQL:
primitive res_mysql ocf:heartbeat:mysqlparams \ config="/etc/mysql/my.cnf" \ datadir="/mnt/mysql" \ log="/var/log/mysql/mysql.log" \ pid="/var/run/mysqld/mysqld.pid" \ socket="/var/run/mysqld/mysqld.sock" \ additional_parameters="--bind-address=192.168.0.3" \ op start interval="0" timeout="60s" \ op stop interval="0" timeout="60s" \ op monitor interval="60s"
Alle notwendigen Ressourcen sind damit in Pacemaker vorhanden. Wie jedoch weiter oben bereits beschrieben ist noch dafür zu sorgen, dass die tatsächlich zueinander gehörenden Ressourcen auch auf dem gleichen Host und außerdem in der richtigen Reihenfolge starten: Zunächst steckt der Admin die Ressourcen
»res_fs_mysql
«
,
»res_ip_mysql
«
sowie
»res_mysql
«
in eine gemeinsame Gruppe namens
»g_mysql
«
:
group g_mysql res_fs_mysql res_ip_mysql res_mysql
Danach verbindet ein Colocation Constraint in Kombination mit einem Order Constraint diese Gruppe mit dem Knoten, auf dem die DRBD-Ressource
»ms_drbd_mysql
«
im Primary-Modus läuft:
colocation co_g_mysql_always_with_ms_drbd_mysql inf: g_mysql ms_drbd_mysql:Master order o_g_mysql_always_after_ms_drbd_mysqlinf: ms_drbd_mysql:promote g_mysql:start
Wenn alle diese Zeilen im
»configure
«
-Abschnitt der CRM-Shell eingetippt sind, beendet
»commit
«
den Kraftakt. Ein Blick in den Cluster-Status mit
»crm_mon -rf
«
auf der Kommandozeile verrät, ob der Versuch erfolgreich war. Das Ergebnis sollte aussehen wie in
Abbildung 6
. Jedenfalls müssen sämtliche angelegten Ressourcen auf dem gleichen Clusterknoten laufen. Tauchen im Cluster-Monitor Ressourcen auf, die als
»failed
«
markiert sind, so empfiehlt es sich, mit
»crm resource cleanup
Name der Resource
«
diese Ressourcen aufzuräumen. Bei DRBD-Ressourcen ist der Cleanup-Befehl grundsätzlich auf das MS-Setting anzuwenden, beispielsweise
»crm resource cleanup ms_drbd_mysql
«
.
Das Pacemaker-Setup wie beschrieben führt zu einem klassischen Aktiv-Passiv-Cluster. Auf einem der beiden Clusterknoten läuft das MySQL mit allem, was dazugehört – der andere Server langweilt sich. Das ist weder sinnvoll noch besonders umweltfreundlich – es besteht durchaus die Option, auch dem anderen Clusterknoten zu Arbeit zu verhelfen. Ein Beispiel wäre ein Szenario, in dem es eine Produktiv-Datenbank und eine Test-Datenbank gibt.
Im Alltag wird das Hauptaugenmerk darauf liegen, die Produktivdatenbank lauffähig zu halten. Solange beide Clusterknoten verfügbar sind, soll auf dem jeweils anderen Knoten eine Test-Datenbank laufen. Stürzt ein Clusterknoten ab, bleibt nur die Produktiv-Datenbank übrig. Pacemaker würde in diesem Falle entweder die Test-Datenbank auf dem Knoten nicht starten, oder die Test-Datenbank – falls sie auf dem noch laufenden Knoten rennt – stoppen und an ihrer Stelle die Produktivdatenbank starten. Das Setup ist sehr leicht zu erreichen.