Egal, um welchen Dienst es sich dreht, den Benutzern geht es immer zu langsam. Der Schwerpunkt des ADMIN-Magazins 05/2011 verrät, mit welchen Tools man ... (mehr)

Der MySQL-Resource-Agent

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« .

Abbildung 6: Fertig – der MySQL-Cluster läuft im Aktiv-Aktiv-Modus; fällt ein Knoten aus, bleibt nur die Datenbank "mysql" übrig.

Sinnvolle Nutzung

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.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2021