Pacemaker und MySQL

© Slawomir Kruz, 123RF

Rettungsschirm für Datenbanken

Der zweite Teil des Workshops zum Cluster-Manager Pacemaker wendet die in der letzten Folge gewonnenen Erkenntnisse praktisch auf eine MySQL-Datenbank an.
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 erste Teil des Workshops vermittelte die grundsätzlichen Fakten zum Thema Hochverfügbarkeit mit Linux und stellte den Pacemaker-Cluster-Manager vor, der zwei Server in einen Cluster verwandeln kann. Fällt einer der beiden Knoten aus, wandern alle seine Dienste automatisch auf den überlebenden Knoten. Pacemaker – auch das diskutierte der vorangegangene Beitrag – kennt zwei verschiedene Möglichkeiten, mit anderen Clusterknoten zu sprechen: Corosync und Heartbeat. Außerdem wurde ein sogenannter Resource Agent vorgestellt, der im Beispiel für die Übernahme von IP-Adressen zuständig war.

Der zweite Teil greift die bereits vorhandene Konfiguration auf und erweitert sie zum ersten Mal so, dass der Cluster für einen echten Dienst ein Fail Over gewährleistet. Dabei kommt auch DRBD zum Einsatz, das die redundante Speicherung der MySQL-Daten erledigt. Schließlich zeigt der vorliegende Artikel, wie man einen echten Aktiv-Aktiv-Cluster baut, der zwei Instanzen von MySQL im Cluster betreibt und dafür sorgt, dass sie stets auf getrennten Hosts laufen.

DRBD für MySQL

Am Anfang eines hochverfügbaren MySQL-Clusters steht natürlich die Installation von MySQL. Alle relevanten Distributionen bringen MySQL in paketierter Form mit, sodass das problemlos gelingen sollte.

Der Betrieb einer redundanten MySQL-Datenbank [1] [2] setzt voraus, dass auf beiden Clusterknoten jeweils die gleichen Daten für MySQL zur Verfügung stehen. Der Artikel zum Thema DRBD im letzten Admin-Magazin [3] geht auf diese Problematik ausführlich ein und erläutert detailliert, wie sich DRBD einrichten und konfigurieren lässt. Dieser Artikel setzt voraus, dass DRBD anhand dieser Anleitung bereits installiert und so konfiguriert ist, dass eine Ressource namens »mysql« mit mindestens 128 Megabyte Größe vorhanden ist Abbildung 1. Sie sollte auch bereits auf einem der beiden Cluster-Knoten im Primary-Modus laufen. Außerdem sollte mittels »mkfs« bereits ein Dateisystem angelegt sein.

Abbildung 1: Der Befehl mysql_install_db legt die wichtigsten Files für eine MySQL-Datenbank an, sodass diese gestartet werden kann.

Eben diese DRBD-Ressource wird später die Dateien der Datenbanken und Tabellen der MySQL-Datenbank enthalten. Um das zu ermöglichen, muss im ersten Schritt ein Mountpoint her: In der Praxis hat sich »/mnt/mysql « bewährt. Das Verzeichnis muss natürlich auf beiden Clusterknoten existieren. Sobald es angelegt ist, lässt sich nun zum ersten Mal die angelegte DRBD-Ressource »mysql« auf dem Knoten, auf dem eben sie gerade Primary ist, unter diesen Mountpoint in das System einhängen.

Basisdatenbank anlegen

Allerdings präsentiert sich das Dateisystem auf der DRBD-Ressource nach dem Mounten jungfräulich. Damit MySQL hier später benutzbare Daten findet, ist mittels »mysql_install_db --datadir=/mnt/mysql« die grundlegende MySQL-Datenbankstruktur anzulegen. Im Anschluss sind die Permissions des Ordners so anzupassen, dass MySQL problemlos darauf zugreifen kann: Der Befehl »chown -R mysql:mysql /mnt/mysql« sorgt dafür, dass der Ordner dem MySQL-Benutzer und der MySQL-Gruppe gehört. Der Befehl ist übrigens auf beiden Clusterknoten auszuführen – auch auf dem, auf dem derzeit die DRBD-Ressource nicht gemountet ist. Schließlich setzt »chmod -R og+rwx /mnt/mysql« die Lese- und Schreibberechtigungen passend.

Im Hinblick auf DRBD ist damit alles erledigt, was für den Betrieb von MySQL notwendig ist. Im nächsten Schritt steht die Integration dieser DRBD-Ressource in den Pacemaker Cluster-Manager an. DRBD-Ressourcen unterscheiden sich von herkömmlichen Ressourcen in Pacemaker dadurch, dass sie aus zwei Teilen bestehen.

Einerseits gehört zu einem DRBD-Laufwerk in Pacemaker nämlich eine ganz normale »primitive« -Ressource, wie sie bereits aus dem ersten Teil des Workshops bekannt ist. Andererseits ist allerdings das dazugehörende Master-Slave-Setup unverzichtbar.

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

Google+

Ausgabe /2019