MySQL-MariaDB — Server-Kit für DTM

Projekt der Arbeitsgruppe 5424 IT-Basis-Dienste der Landeshauptstadt Potsdam.

Alles, was auf einem MariaDB- oder MySQL-Server eingerichtet werden muss, damit DTM ihn verwalten kann — plus die beiden Läufe, die der Server selbst erledigen sollte: nächtliche Sicherung und wöchentliche Tabellen-Wartung.

---

Das Wichtigste zuerst: hier wird kein Modul installiert

Wer FOC-SQL kennt, erwartet an dieser Stelle ein PowerShell-Modul, das auf den Server gehört. Das gibt es hier nicht, und es wird es nicht geben.

DTM spricht MariaDB und MySQL direkt über das Netz an (MySqlConnector, Port 3306). Es gibt keinen Agenten, kein Modul, keinen Dienst, der auf dem Server laufen müsste. Auch die Werkzeuge mariadb-dump und mariadb, mit denen DTM sichert und zurückspielt, laufen auf dem Arbeitsplatz und nicht auf dem Server.

Was auf dem Server gebraucht wird, ist deshalb nur dreierlei:

1. ein Dienstkonto mit genau den Rechten, die DTM benutzt,
2. ein paar Server-Einstellungen, ohne die DTM gar nicht erst herankommt,
3. Sicherung und Wartung als Timer — damit beides auch dann läuft, wenn niemand DTM geöffnet hat.

Punkt 3 ist kein Ersatz für DTM, sondern die Grundlast. DTM sichert zusätzlich auf Zuruf, in sein eigenes Verzeichnis auf dem Arbeitsplatz. Die beiden kommen sich nicht in die Quere.

---

Einrichtung in fünf Schritten

Geprüft für MariaDB ab 10.5 und MySQL ab 8.0 unter Debian, Ubuntu und Rocky Linux. Alle Befehle als root bzw. mit sudo.

1. Repository auf den Server holen

git clone https://github.com/LHP542/MySQL-MariaDB.git
cd MySQL-MariaDB

Kein Git auf dem Server? Dann das ZIP herunterladen und auspacken — es sind nur Skripte und Textdateien.

2. Dienstkonto anlegen

In setup/01-dtm-benutzer.sql oben die vier Variablen anpassen:

Variable	Bedeutung
@dtm_user	Name des Kontos, Vorgabe dtm
@dtm_host	Von wo aus DTM sich verbindet. % erlaubt jeden Host — besser der Arbeitsplatz oder das Subnetz, z. B. 192.168.10.%
@dtm_password	Passwort. Nur für die Einrichtung eintragen, danach nicht mit gesetztem Wert einchecken
@erlaube_restore	1 = DTM darf auch zurückspielen, 0 = nur ansehen, warten und sichern

Dann einspielen:

mariadb -u root -p < setup/01-dtm-benutzer.sql

Das Skript gibt am Ende die vergebenen Rechte aus. Jedes einzelne gehört zu einer Funktion in DTM — die Datei erklärt bei jedem Block, wozu.

Zwei Rechte, die gern vergessen werden und deren Fehlen nicht nach einem Rechtefehler aussieht:

• PROCESS — ohne das sieht DTM nur seine eigene Verbindung und meldet dauerhaft „0 aktive Sitzungen". Das sieht aus wie eine unbenutzte Datenbank.
• EVENT und TRIGGER — ohne die fehlen Events und Trigger im Dump. Der Dump läuft durch, die Datei sieht normal aus, und erst beim Zurückspielen fällt auf, dass die Datenbank unvollständig ist.

3. Server-Einstellungen setzen

# Debian / Ubuntu
sudo install -m 0644 setup/02-dtm-server.cnf /etc/mysql/mariadb.conf.d/60-dtm.cnf
# RHEL / Rocky / SUSE
sudo install -m 0644 setup/02-dtm-server.cnf /etc/my.cnf.d/60-dtm.cnf

sudo systemctl restart mariadb

Der wichtigste Eintrag ist bind-address. Auf Debian und Ubuntu steht der Standard auf 127.0.0.1; der Server lauscht dann nur lokal, und DTM kommt gar nicht erst heran. Der Fehler sieht dabei aus wie ein falsches Passwort.

Nicht nachträglich anfassen: lower_case_table_names. Unter Linux ist der Standard 0, Datenbank- und Tabellennamen sind also case-sensitiv, weil sie auf Verzeichnis- und Dateinamen abgebildet werden. DTM kommt damit zurecht. Wer den Wert nachträglich auf 1 stellt, findet bestehende Tabellen mit Großbuchstaben im Namen nicht mehr wieder. Die Zeile steht in der Datei deshalb auskommentiert — als Erinnerung, nicht als Empfehlung.

4. Prüfen

./check/pruefe-server.sh -u dtm -p

Das Skript ändert nichts. Es meldet pro Punkt ok, hinweis oder fehlt und endet mit der Zahl der Beanstandungen — damit lässt es sich auch in einen Timer oder eine Monitoring-Prüfung hängen.

Vom Arbeitsplatz aus, um gleich den Zugang von außen mitzuprüfen:

./check/pruefe-server.sh -h db01 -u dtm -p

5. Sicherung und Wartung einrichten

sudo install -m 0755 backup/dtm-dump.sh      /usr/local/sbin/
sudo install -m 0755 wartung/dtm-wartung.sh  /usr/local/sbin/
sudo install -m 0644 backup/dtm-dump.conf    /etc/dtm-dump.conf

# Zugangsdaten, Rechte 600 — die Skripte brechen sonst ab
sudo install -m 0600 backup/dtm-dump-zugang.cnf.vorlage /etc/dtm-dump-zugang.cnf
sudo nano /etc/dtm-dump-zugang.cnf

sudo install -m 0644 systemd/*.service systemd/*.timer /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now dtm-dump.timer dtm-wartung.timer

Erster Lauf von Hand, ohne auf die Nacht zu warten:

sudo systemctl start dtm-dump.service
journalctl -u dtm-dump.service -n 50 --no-pager

---

Was die Timer tun

Timer	Wann	Was
dtm-dump.timer	täglich 02:00 (±15 min)	Dump jeder Nutzdatenbank nach /var/backups/mariadb/<db>/, gzip-gepackt, Aufbewahrung 14 Tage
dtm-wartung.timer	sonntags 03:00 (±15 min)	CHECK und ANALYZE TABLE über alle Tabellen; OPTIMIZE nur mit --optimize

Beide laufen mit Nice=10 bzw. 15 und IOSchedulingClass=idle — sie sollen den laufenden Betrieb nicht ausbremsen. Die Streuung von 15 Minuten verhindert, dass mehrere Server gleichzeitig loslegen und sich auf einem gemeinsamen Sicherungsziel in die Quere kommen. Persistent=true holt einen Lauf nach, wenn der Rechner zur geplanten Zeit aus war.

Einstellen lässt sich das in /etc/dtm-dump.conf (Ziel, Aufbewahrung) und über systemctl edit dtm-dump.timer (Zeitpunkt).

OPTIMIZE ist bewusst nicht voreingestellt. Es baut jede Tabelle neu auf und sperrt sie dabei. Wer es will, trägt es in der Service-Datei ein:

sudo systemctl edit dtm-wartung.service
# [Service]
# ExecStart=
# ExecStart=/usr/local/sbin/dtm-wartung.sh --optimize

Drei Dinge, die die Skripte bewusst anders machen

Das Passwort steht nie auf der Kommandozeile. Prozessargumente kann auf dem Rechner jeder lesen, der die Prozessliste sieht — ein --password=geheim wäre dort im Klartext sichtbar. Beide Skripte übergeben stattdessen eine Optionsdatei als --defaults-extra-file und brechen ab, wenn diese Datei nicht 600 gehört.

Ein abgebrochener Dump löscht seine halbe Datei. Sie sähe aus wie eine Sicherung und ließe sich nicht einspielen — das ist schlimmer als gar keine. Dabei wird der Rückgabewert des Dumps ausgewertet und nicht der der Pipeline: dump | gzip meldet sonst Erfolg, wenn nur gzip gut lief.

Aufgeräumt wird erst nach erfolgreicher Sicherung. Andersherum stünde man nach einem gescheiterten Lauf ganz ohne Sicherung da.

---

Zurückspielen

Aus einer Sicherung dieses Kits, von Hand auf dem Server:

gunzip -c /var/backups/mariadb/kunden/kunden-20260924_0200.sql.gz \
  | mariadb --defaults-extra-file=/etc/dtm-dump-zugang.cnf kunden

Aus DTM heraus: Browser in der Gruppe SICHERUNG, Datei wählen, Restore. DTM greift dabei auf seine eigenen Dumps auf dem Arbeitsplatz zu, nicht auf die des Servers.

Unterschied zu MSSQL: DTM beendet beim Restore keine offenen Verbindungen. Laufende Schreibzugriffe können den eingespielten Stand sofort wieder verändern. Wer sichergehen will, beendet die Sitzungen vorher über den Sitzungs-Dialog.

---

Versionen

Die Datei VERSION enthält die Version dieses Kits. DTM prüft beim ersten Dump, ob das gefundene Dump-Werkzeug zu ihm und zum Server passt, und meldet in der Statusleiste, wenn nicht — nach demselben Muster, mit dem FOC-SQL eine veraltete MSSQL-Modulversion meldet.

Geprüft wird zweierlei:

1. Werkzeug gegen Mindestversion. DTM hat eine hinterlegte Untergrenze für mariadb-dump. Darunter fehlen Optionen, auf die sich DTM verlässt.
2. Werkzeug gegen Server. Ein Dump-Werkzeug, das älter ist als der Server, erzeugt Dumps, die sich nicht zuverlässig zurückspielen lassen. Der Klassiker ist mysqldump aus MySQL 5.7 gegen eine MariaDB 10.11: der Lauf meldet Erfolg, der Restore scheitert.

Deshalb gehören die Client-Werkzeuge auf dem Arbeitsplatz zur Server-Version. Unter Windows liefert das der MariaDB-Installer mit („Client Programs"); es reicht, die Werkzeuge ohne den Server zu installieren.

---

Fehlersuche

Beobachtung	Wahrscheinliche Ursache
DTM zeigt keine Datenbanken	SELECT global fehlt, oder das Konto ist für diesen Herkunftshost nicht angelegt
„Aktive Sitzungen: 0", obwohl jemand arbeitet	PROCESS fehlt
„Sitzungen beenden" scheitert	weder SUPER noch CONNECTION ADMIN
Verbindung läuft in einen Zeitüberlauf	bind-address steht auf 127.0.0.1, oder Port 3306 ist durch eine Firewall geblockt
Dump bricht bei einer bestimmten Tabelle ab	max_allowed_packet zu klein — die Tabelle hat große BLOBs
Restore meldet fehlende Prozeduren	Dump ohne EVENT/TRIGGER-Recht erstellt, also unvollständig
Timer läuft nicht	systemctl list-timers dtm-*, dann journalctl -u dtm-dump.service

Für den schnellen Rundumblick immer zuerst:

./check/pruefe-server.sh -u dtm -p

---

Verzeichnisse

setup/     Dienstkonto (SQL) und Server-Einstellungen (cnf)
check/     Prüfskript — liest und meldet, ändert nichts
backup/    Dump-Skript, Konfiguration, Vorlage für die Zugangsdatei
wartung/   CHECK / ANALYZE / OPTIMIZE über alle Datenbanken
systemd/   Service- und Timer-Dateien für beide Läufe
VERSION    Version dieses Kits

---

Lizenz

MIT — siehe LICENSE.