Eine Datenbank läuft oft jahrelang unauffällig im Hintergrund. Sie speichert Blogbeiträge, Benutzerkonten, Kommentare, Einstellungen und sämtliche Informationen, die moderne Webanwendungen benötigen. Solange alles funktioniert, beschäftigen sich viele Administratoren kaum mit der Datenbankwartung.
Doch genau das kann langfristig zum Problem werden. Wachsende Tabellen, fehlgeschlagene Backups, unbemerkte Fehlermeldungen oder langsame SQL-Abfragen können die Leistung und Zuverlässigkeit eines Systems beeinträchtigen.
Die gute Nachricht: Unter Debian und Ubuntu lassen sich viele Wartungsarbeiten für MySQL und MariaDB automatisieren. Mit Bash-Skripten, Cron, Logrotation und E-Mail-Benachrichtigungen entsteht eine zuverlässige Wartungsumgebung, die den Administrator bei Problemen informiert.
Dabei ist allerdings eine wichtige Unterscheidung erforderlich: Eine kleine Blogdatenbank mit wenigen Hundert Megabyte benötigt eine andere Wartungsstrategie als eine produktive Datenbank mit mehreren Hundert Gigabyte und zahlreichen gleichzeitigen Zugriffen.
Dieser Beitrag zeigt Schritt für Schritt, wie eine automatisierte Datenbankwartung eingerichtet wird, welche Aufgaben regelmäßig ausgeführt werden sollten und welche Maßnahmen besser ausschließlich nach einer gezielten Analyse erfolgen.
1. Grundlagen der automatisierten Datenbankwartung
Eine gute Datenbankwartung besteht nicht darin, möglichst häufig Optimierungsbefehle auszuführen.
Vielmehr geht es darum, den Zustand des Systems regelmäßig zu kontrollieren, Probleme frühzeitig zu erkennen und notwendige Maßnahmen kontrolliert durchzuführen.
Typische Wartungsaufgaben sind:
- Erreichbarkeit des Datenbankservers überprüfen
- Datenbankversion und Serverstatus erfassen
- Speicherplatz überwachen
- Datenbankgrößen analysieren
- Fehlerprotokolle kontrollieren
- Langsame SQL-Abfragen erkennen
- Backups erstellen und überprüfen
- Tabellenstatistiken bei Bedarf aktualisieren
- Wartungsprotokolle automatisch verwalten
- Bei Fehlern eine E-Mail-Benachrichtigung versenden
Nicht jede dieser Aufgaben muss täglich ausgeführt werden.
Insbesondere OPTIMIZE TABLE, CHECK TABLE und umfangreiche Löschoperationen sollten nicht ohne konkrete Notwendigkeit automatisiert werden.
Kleine und große Datenbanken unterscheiden
Bei kleineren Blogdatenbanken stehen vor allem einfache Administration, geringer Ressourcenverbrauch und zuverlässige Datensicherung im Vordergrund.
Bei großen produktiven Datenbanken sind dagegen zusätzliche Anforderungen zu berücksichtigen. Dazu gehören hohe Verfügbarkeit, kurze Wartungsfenster, umfangreiche Überwachung und möglichst geringe Auswirkungen auf laufende Anwendungen.
Die folgende Anleitung verwendet deshalb zunächst ein gemeinsames, möglichst schonendes Wartungsskript. Anschließend werden die Besonderheiten beider Einsatzszenarien erläutert.
2. Voraussetzungen unter Debian und Ubuntu
Für die Einrichtung wird ein Linux-Server mit Debian oder Ubuntu benötigt.
Außerdem sollten folgende Voraussetzungen erfüllt sein:
- MySQL oder MariaDB ist bereits installiert.
- Der Datenbankdienst funktioniert ordnungsgemäß.
- Administrative Berechtigungen sind vorhanden.
- Bash und Cron stehen zur Verfügung.
- Ein E-Mail-Versand über einen SMTP-Relay oder einen lokalen Mailserver ist eingerichtet.
- Es existiert bereits eine Datensicherungsstrategie.
Zunächst wird überprüft, welches Datenbanksystem installiert ist.
mariadb --version
Alternativ:
mysql --version
Den Status des MariaDB-Dienstes überprüfen:
sudo systemctl status mariadb
Bei MySQL:
sudo systemctl status mysql
Falls Cron noch nicht installiert ist:
sudo apt update sudo apt install cron
Anschließend wird der Dienst aktiviert:
sudo systemctl enable --now cron
Für den E-Mail-Versand verwenden wir das Programm mail.
sudo apt install mailutils
Das Paket stellt die benötigte Kommandozeilenschnittstelle bereit. Für einen funktionierenden E-Mail-Versand muss zusätzlich ein geeigneter Mailtransport konfiguriert sein. Die Installation allein garantiert noch keine Zustellung.
3. Verzeichnisstruktur für die Wartung erstellen
Damit Skripte, Konfigurationen und Protokolle übersichtlich bleiben, empfiehlt sich eine feste Verzeichnisstruktur.
Die Wartungsskripte werden unter /usr/local/sbin gespeichert.
Die Konfiguration liegt unter /etc/db-maintenance.
Die Protokolle werden unter /var/log/db-maintenance abgelegt.
Zunächst werden die Verzeichnisse erstellt:
sudo install -d -m 700 /etc/db-maintenance sudo install -d -m 750 /var/log/db-maintenance
Das Wartungsskript erhält später folgenden Speicherort:
/usr/local/sbin/db-maintenance.sh
Die Konfigurationsdatei:
/etc/db-maintenance/config
Und die Protokolldatei:
/var/log/db-maintenance/maintenance.log
Die Konfiguration sollte ausschließlich von berechtigten Administratoren verändert werden können.
4. Sichere Datenbankanmeldung einrichten
Ein häufiges Problem bei automatisierten Datenbankskripten ist die Speicherung von Zugangsdaten.
Passwörter sollten nicht direkt in Bash-Skripten oder Cron-Einträgen hinterlegt werden.
Bei Debian- und Ubuntu-Installationen mit MariaDB ist häufig bereits eine lokale Anmeldung über Unix-Socket-Authentifizierung eingerichtet.
In diesem Fall kann der administrative Benutzer beispielsweise folgenden Befehl ausführen:
sudo mariadb
Für unser Wartungsskript ist das besonders praktisch, da keine Datenbankpasswörter im Skript hinterlegt werden müssen.
Bei MySQL hängt die verfügbare Authentifizierung von der Installation ab.
Falls eine passwortbasierte Anmeldung erforderlich ist, kann eine geschützte Client-Konfigurationsdatei verwendet werden. Alternativ sind die vom jeweiligen System bereitgestellten sicheren Anmeldeverfahren vorzuziehen.
Für produktive Umgebungen empfiehlt sich grundsätzlich ein dediziertes Datenbankkonto mit möglichst eingeschränkten Berechtigungen.
Unser Beispiel verwendet die lokale Socket-Authentifizierung und wird über Root-Cron ausgeführt.
Wichtig: Die hier eingesetzten SQL-Abfragen benötigen hauptsächlich Leserechte auf Status- und Metadaten. Ein dauerhaft privilegierter Datenbankzugang ist für eine professionelle Produktionsumgebung nicht automatisch die beste Wahl.
5. Zentrale Konfigurationsdatei erstellen
Zunächst wird eine Konfigurationsdatei angelegt:
sudo nano /etc/db-maintenance/config
Inhalt:
# Allgemeine Einstellungen DB_CLIENT="/usr/bin/mariadb" LOGDIR="/var/log/db-maintenance" LOGFILE="$LOGDIR/maintenance.log" # Warnschwelle für Datenträgerbelegung in Prozent DISK_WARNING=85 # E-Mail-Benachrichtigung MAIL_ENABLED=1 MAIL_TO="admin@example.com" # Anzeigename des Systems SERVER_NAME="DB-Server-01" # Maximale Laufzeit in Sekunden TIMEOUT=120
Bei MySQL wird der Clientpfad entsprechend angepasst:
DB_CLIENT="/usr/bin/mysql"
Die tatsächlich vorhandenen Programme lassen sich überprüfen:
command -v mariadb command -v mysql
Anschließend werden die Berechtigungen gesetzt:
sudo chmod 600 /etc/db-maintenance/config sudo chown root:root /etc/db-maintenance/config
Die Konfigurationsdatei wird später vom Bash-Skript eingelesen.
Da es sich um eine ausführbare Shell-Konfiguration handelt, darf sie ausschließlich durch vertrauenswürdige Administratoren bearbeitet werden.
6. Das eigentliche Bash-Wartungsskript erstellen
Jetzt wird das zentrale Wartungsskript erstellt.
sudo nano /usr/local/sbin/db-maintenance.sh
Das Skript übernimmt mehrere Aufgaben:
Es überprüft die Datenbankverbindung, ermittelt die Serverversion, kontrolliert die Datenträgerbelegung, erfasst die Datenbankgrößen und informiert bei Fehlern oder kritischen Zuständen per E-Mail.
#!/bin/bash
set -Eeuo pipefail
CONFIG="/etc/db-maintenance/config"
if [[ ! -r "$CONFIG" ]]; then
echo "Konfiguration nicht gefunden: $CONFIG" >&2
exit 1
fi
source "$CONFIG"
# Sichere Standardumgebung
umask 027
export LC_ALL=C
# Keine parallelen Wartungsläufe
exec 9>/run/lock/db-maintenance.lock
if ! flock -n 9; then
echo "Eine Wartung läuft bereits."
exit 0
fi
mkdir -p "$LOGDIR"
ERRORS=0
WARNINGS=0
MESSAGES=""
log() {
local message="$1"
printf '%s %s\n' \
"$(date '+%Y-%m-%d %H:%M:%S')" \
"$message" | tee -a "$LOGFILE"
}
warning() {
WARNINGS=$((WARNINGS + 1))
MESSAGES+="WARNUNG: $1"$'\n'
log "WARNUNG: $1"
}
error() {
ERRORS=$((ERRORS + 1))
MESSAGES+="FEHLER: $1"$'\n'
log "FEHLER: $1"
}
send_mail() {
if [[ "${MAIL_ENABLED:-0}" != "1" ]]; then
return
fi
if [[ $ERRORS -eq 0 && $WARNINGS -eq 0 ]]; then
return
fi
if ! command -v mail >/dev/null 2>&1; then
log "WARNUNG: mail ist nicht installiert."
return
fi
local subject="Datenbankwartung: $SERVER_NAME"
if ! printf '%s\n' "$MESSAGES" |
mail -s "$subject" "$MAIL_TO"; then
log "FEHLER: E-Mail konnte nicht übergeben werden."
fi
}
log "======================================"
log "Datenbankwartung gestartet"
log "Server: $SERVER_NAME"
# 1. Datenbankverbindung prüfen
if timeout "$TIMEOUT" "$DB_CLIENT" \
--batch --skip-column-names \
-e "SELECT 1;" >/dev/null 2>&1; then
log "Datenbankverbindung erfolgreich."
else
error "Datenbankverbindung fehlgeschlagen."
send_mail
exit 1
fi
# 2. Datenbankversion
VERSION=$(
timeout "$TIMEOUT" "$DB_CLIENT" \
--batch --skip-column-names \
-e "SELECT VERSION();" 2>&1
) || VERSION="Version konnte nicht ermittelt werden"
log "Datenbankversion: $VERSION"
# 3. Datenträgerbelegung
DISK_USAGE=$(
df -P "$LOGDIR" |
awk 'NR==2 {gsub("%","",$5); print $5}'
)
log "Datenträgerbelegung: ${DISK_USAGE}%"
if (( DISK_USAGE >= DISK_WARNING )); then
warning "Datenträgerbelegung bei ${DISK_USAGE}%"
fi
# 4. Aktuelle Datenbankverbindungen
CONNECTIONS=$(
timeout "$TIMEOUT" "$DB_CLIENT" \
--batch --skip-column-names \
-e "SHOW GLOBAL STATUS LIKE 'Threads_connected';" |
awk '{print $2}'
) || CONNECTIONS="unbekannt"
log "Aktive Datenbankverbindungen: $CONNECTIONS"
# 5. Datenbankgrößen erfassen
log "Datenbankgrößen werden ermittelt."
if ! timeout "$TIMEOUT" "$DB_CLIENT" \
--batch \
-e "
SELECT
table_schema AS Datenbank,
ROUND(
SUM(data_length + index_length)
/ 1024 / 1024, 2
) AS Groesse_MB
FROM information_schema.tables
GROUP BY table_schema
ORDER BY SUM(data_length + index_length) DESC;
" >> "$LOGFILE" 2>&1; then
warning "Datenbankgrößen konnten nicht ermittelt werden."
fi
# 6. Abschluss
log "Warnungen: $WARNINGS"
log "Fehler: $ERRORS"
log "Datenbankwartung abgeschlossen"
log "======================================"
send_mail
if (( ERRORS > 0 )); then
exit 1
fi
exit 0
Das Skript führt bewusst keine destruktiven Aktionen aus. Es werden weder Datensätze gelöscht noch Tabellen automatisch reorganisiert.
Es ist damit grundsätzlich für die regelmäßige Überwachung kleiner und größerer Datenbanken geeignet.
Eine Einschränkung ist allerdings zu beachten: Die Datenträgerprüfung bezieht sich auf das Dateisystem des Logverzeichnisses. Liegt das Datenbankverzeichnis auf einem anderen Datenträger, muss dessen Belegung zusätzlich überwacht werden.
Außerdem werden Fehler bei einzelnen Statusabfragen nicht in jedem Fall als kritischer Fehler bewertet. Für hochverfügbare Produktionsumgebungen sollte das Skript um eine strengere Fehlerbehandlung und externe Überwachung ergänzt werden.
7. Skript ausführbar machen und testen
Nach dem Speichern werden die Berechtigungen gesetzt:
sudo chown root:root \ /usr/local/sbin/db-maintenance.sh sudo chmod 750 \ /usr/local/sbin/db-maintenance.sh
Vor der ersten Ausführung empfiehlt sich eine Syntaxprüfung:
sudo bash -n \ /usr/local/sbin/db-maintenance.sh
Anschließend kann das Skript manuell gestartet werden:
sudo /usr/local/sbin/db-maintenance.sh
Die Protokolldatei wird angezeigt mit:
sudo tail -n 100 \ /var/log/db-maintenance/maintenance.log
Eine erfolgreiche Ausführung sollte Informationen zur Datenbankversion, zur Datenträgerbelegung und zu den Datenbankgrößen enthalten.
8. Automatische Ausführung mit Cron
Nachdem das Skript erfolgreich getestet wurde, kann die regelmäßige Ausführung eingerichtet werden.
Dazu wird die Root-Crontab geöffnet:
sudo crontab -e
Für eine tägliche Prüfung um 03:15 Uhr:
15 3 * * * /usr/local/sbin/db-maintenance.sh
Für eine wöchentliche Prüfung am Sonntag um 03:15 Uhr:
15 3 * * 0 /usr/local/sbin/db-maintenance.sh
Für kleine Blogdatenbanken ist eine tägliche Kontrolle normalerweise unproblematisch.
Bei größeren produktiven Datenbanken sollte die Ausführung an vorhandene Monitoring- und Wartungskonzepte angepasst werden.
Das Skript verwendet flock, um parallele Ausführungen zu verhindern.
Dadurch wird vermieden, dass beispielsweise eine noch laufende Wartung mit dem nächsten geplanten Durchlauf kollidiert.
Cron übernimmt allerdings keine automatische Wiederholung fehlgeschlagener Aufgaben. Auch eine Überwachung ausgebliebener Ausführungen ist nicht enthalten. Dafür können zusätzliche Monitoring-Systeme oder systemd-Timer eingesetzt werden.
9. Logrotation mit logrotate einrichten
Ein Wartungsskript erzeugt bei jeder Ausführung neue Protokolleinträge.
Ohne Begrenzung können diese Dateien mit der Zeit erheblich wachsen.
Unter Debian und Ubuntu übernimmt logrotate die automatische Verwaltung solcher Protokolldateien.
Installation:
sudo apt install logrotate
Anschließend wird eine Konfigurationsdatei erstellt:
sudo nano /etc/logrotate.d/db-maintenance
Inhalt:
/var/log/db-maintenance/maintenance.log {
weekly
rotate 12
compress
delaycompress
missingok
notifempty
create 0640 root root
}
Die Optionen haben folgende Bedeutung:
weekly sorgt für eine wöchentliche Rotation.
rotate 12 bewahrt zwölf ältere Protokollgenerationen auf.
compress komprimiert ältere Protokolldateien.
delaycompress verschiebt die Komprimierung um einen Rotationszyklus.
missingok verhindert Fehler, wenn die Protokolldatei nicht vorhanden ist.
notifempty überspringt leere Dateien.
create erstellt nach der Rotation eine neue Protokolldatei mit den angegebenen Berechtigungen.
Konfiguration testen
sudo logrotate -d \ /etc/logrotate.d/db-maintenance
Der Parameter -d aktiviert den Debug-Modus und führt keine tatsächliche Rotation durch.
Da das Wartungsskript die Protokolldatei bei jedem Schreibvorgang neu öffnet, ist für dieses Beispiel normalerweise kein zusätzlicher Neustart oder ein Signal an einen Prozess erforderlich.
10. E-Mail-Benachrichtigungen konfigurieren
Ein automatisiertes Wartungssystem sollte nicht nur Protokolle erstellen, sondern bei Problemen aktiv informieren.
Das Bash-Skript unterstützt bereits eine entsprechende Funktion.
In der Konfigurationsdatei wird dazu folgende Einstellung verwendet:
MAIL_ENABLED=1 MAIL_TO="admin@example.com"
Für einen ersten Test kann eine Nachricht versendet werden:
echo "Test der Datenbanküberwachung" | mail -s "MariaDB Wartungstest" \ admin@example.com
Wird die Nachricht erfolgreich zugestellt, ist der grundlegende E-Mail-Versand eingerichtet.
Bei Servern ohne eigenen Mailserver empfiehlt sich die Verwendung eines SMTP-Relays.
Das kann beispielsweise ein vorhandener Unternehmensmailserver oder ein dafür vorgesehener SMTP-Dienst sein.
Dabei sollten verschlüsselte Verbindungen, sichere Zugangsdaten und geeignete Absenderadressen verwendet werden.
Wichtig: Das Wartungsskript versendet standardmäßig nur bei Warnungen oder Fehlern eine Nachricht. Ein fehlender Wartungslauf würde daher nicht automatisch auffallen. Für produktive Systeme sollte zusätzlich eine externe Überwachung prüfen, ob das Skript regelmäßig erfolgreich ausgeführt wurde.
11. Kleine Blogdatenbanken automatisch warten
Bei kleineren Datenbanken, beispielsweise für WordPress oder selbst entwickelte PHP-Anwendungen, ist eine einfache Wartungsstrategie häufig ausreichend.
Typische Merkmale solcher Systeme sind eine überschaubare Datenbankgröße, wenige gleichzeitige Zugriffe und eine vergleichsweise geringe Änderungsrate.
Hier empfiehlt sich folgende Vorgehensweise.
Tägliche Aufgaben
Täglich sollten die Erreichbarkeit des Datenbankservers, der verfügbare Speicherplatz und der Backup-Status überprüft werden.
Das zuvor erstellte Bash-Skript übernimmt bereits einen Teil dieser Aufgaben.
Wöchentliche Aufgaben
Einmal pro Woche können Datenbankgrößen, Fehlerprotokolle und auffällige Abfragen kontrolliert werden.
Wenn eine Anwendung ungewöhnlich langsam geworden ist, sollte zunächst geprüft werden, ob ineffiziente SQL-Abfragen oder fehlende Indizes die Ursache sind.
Monatliche Aufgaben
Einmal monatlich kann überprüft werden, ob Tabellen ungewöhnlich stark wachsen oder nicht mehr benötigte Daten vorhanden sind.
Nach umfangreichen Änderungen kann eine Aktualisierung der Tabellenstatistiken sinnvoll sein:
ANALYZE TABLE tabellenname;
Eine regelmäßige pauschale Ausführung von OPTIMIZE TABLE ist dagegen auch bei kleinen Blogdatenbanken nicht notwendig.
Besonderheiten bei WordPress
WordPress speichert unter anderem Beiträge, Revisionen, Kommentare und temporäre Informationen in seiner Datenbank.
Die Bereinigung sollte bevorzugt über WordPress selbst oder geeignete Verwaltungswerkzeuge erfolgen.
Direkte SQL-Löschaktionen können problematisch sein, wenn dadurch Beziehungen zwischen Datensätzen beschädigt werden.
Vor jeder Bereinigung sollte deshalb ein aktuelles Backup vorhanden sein.
12. Große produktive Datenbanken warten
Bei großen Datenbanken ändern sich die Anforderungen deutlich.
Eine Datenbank mit mehreren Hundert Gigabyte kann nicht ohne Weiteres mit denselben Maßnahmen behandelt werden wie eine kleine WordPress-Datenbank.
Insbesondere Operationen, die Tabellen neu aufbauen, können erhebliche Auswirkungen auf die Verfügbarkeit haben.
Monitoring statt pauschaler Optimierung
Bei großen produktiven Datenbanken sollte die laufende Überwachung im Vordergrund stehen.
Dazu gehören insbesondere CPU- und Speicherauslastung, Datenträger-I/O, Verbindungszahlen, Abfragezeiten, Replikationsstatus und das Wachstum einzelner Tabellen.
Werkzeuge wie Prometheus, Grafana oder spezialisierte Datenbank-Monitoring-Systeme können diese Informationen kontinuierlich erfassen.
Das Bash-Skript aus diesem Beitrag eignet sich in solchen Umgebungen eher als ergänzende Kontrollinstanz.
Tabellenoptimierung nur nach Analyse
Eine Anweisung wie:
OPTIMIZE TABLE grosse_tabelle;
kann bei einer großen InnoDB-Tabelle erheblichen zusätzlichen Speicherplatz benötigen und lange laufen.
Auch wenn bestimmte Operationen online durchgeführt werden können, sind Sperren und Performanceeinbußen nicht grundsätzlich ausgeschlossen.
Solche Maßnahmen gehören deshalb in ein geplantes Wartungsfenster.
Statistiken gezielt aktualisieren
Eine Aktualisierung der Statistiken kann beispielsweise nach umfangreichen Importen oder Löschaktionen sinnvoll sein.
ANALYZE TABLE grosse_tabelle;
Auch hier sollten mögliche Auswirkungen auf den laufenden Betrieb berücksichtigt werden.
Daten in kleinen Chargen bereinigen
Bei sehr großen Tabellen sollten Löschaktionen nicht unnötig große Transaktionen erzeugen.
Stattdessen kann die Bereinigung in begrenzten Chargen erfolgen:
DELETE FROM application_logs WHERE created_at < NOW() - INTERVAL 90 DAY ORDER BY created_at LIMIT 1000;
Diese Anweisung löscht höchstens 1.000 passende Datensätze.
Für wiederholte Ausführungen sollte ein geeigneter Index vorhanden sein. Außerdem müssen Aufbewahrungsfristen und gegebenenfalls Replikationsanforderungen berücksichtigt werden.
Bei besonders großen Datenbeständen können Partitionierung oder Archivierung geeigneter sein.
13. Automatische Backups ergänzen
Eine Wartungsautomatisierung ersetzt keine Datensicherung.
Für kleinere InnoDB-Datenbanken kann ein logisches Backup beispielsweise mit mariadb-dump erstellt werden:
mariadb-dump \ --single-transaction \ --routines \ --events \ --triggers \ datenbankname | gzip > /backup/datenbankname.sql.gz
Das Zielverzeichnis muss vorher vorhanden und ausreichend geschützt sein.
Bei MySQL kann entsprechend mysqldump verwendet werden.
Die Option --single-transaction ermöglicht bei InnoDB eine konsistente Sicherung, sofern währenddessen keine problematischen Schemaänderungen stattfinden.
Bei größeren produktiven Datenbanken können physische Backupverfahren sinnvoller sein, beispielsweise MariaDB Backup oder MySQL Enterprise Backup, abhängig vom eingesetzten Datenbanksystem und dessen Version.
Für eine zuverlässige Sicherungsstrategie sollten außerdem die Wiederherstellungszeit, die gewünschte maximale Datenverlustspanne und gegebenenfalls Binärlogs für Point-in-Time-Recovery berücksichtigt werden.
Ein besonders wichtiger Punkt ist die Prüfung der gesamten Backup-Pipeline. Ohne set -o pipefail kann ein Fehler des Dump-Programms bei einer Pipeline unbemerkt bleiben.
Backups sollten außerdem nicht nur erstellt, sondern regelmäßig auf einem getrennten System wiederhergestellt und getestet werden.
14. Empfohlener Wartungsplan für kleine und große Datenbanken
Nicht jede Datenbank benötigt denselben Wartungsumfang. Entscheidend sind die Größe des Datenbestands, die Anzahl gleichzeitiger Zugriffe, die Bedeutung der gespeicherten Informationen und die Anforderungen an die Verfügbarkeit.
Tägliche Wartung kleiner Blogdatenbanken
Bei kleinen Blogdatenbanken sollte täglich überprüft werden, ob der Datenbankserver erreichbar ist und ausreichend freier Speicherplatz zur Verfügung steht.
Außerdem sollte kontrolliert werden, ob die vorgesehenen Datensicherungen erfolgreich abgeschlossen wurden.
Das Bash-Skript aus diesem Beitrag kann diese Kontrollen teilweise automatisieren. Ergänzend empfiehlt sich eine Überwachung der Backup-Ergebnisse.
Bei ungewöhnlichen Zuständen sollte eine E-Mail-Benachrichtigung ausgelöst werden.
Wöchentliche Wartung kleiner Blogdatenbanken
Einmal wöchentlich empfiehlt sich eine Überprüfung der Fehlerprotokolle und der Datenbankgrößen.
Dabei sollte besonders auf ungewöhnlich stark wachsende Tabellen geachtet werden.
Auch langsame SQL-Abfragen können ausgewertet werden, sofern das Slow Query Log aktiviert wurde.
Bei kleineren Blogs genügt häufig bereits eine einfache regelmäßige Kontrolle, um mögliche Probleme frühzeitig zu erkennen.
Monatliche Wartung kleiner Blogdatenbanken
Einmal monatlich sollten die Tabellenstruktur, die Entwicklung des Speicherbedarfs und gegebenenfalls nicht mehr benötigte Anwendungsdaten überprüft werden.
Nach umfangreichen Änderungen kann eine Aktualisierung der Tabellenstatistiken mit ANALYZE TABLE sinnvoll sein.
Eine Tabellenoptimierung mit OPTIMIZE TABLE sollte dagegen nur erfolgen, wenn dafür ein konkreter Anlass besteht.
Zusätzlich empfiehlt sich ein regelmäßiger Wiederherstellungstest der Datenbanksicherungen.
Kontinuierliche Überwachung großer produktiver Datenbanken
Bei großen produktiven Datenbanken reicht eine tägliche Kontrolle häufig nicht aus.
Hier sollten wichtige Betriebsparameter kontinuierlich überwacht werden.
Dazu gehören insbesondere die Erreichbarkeit des Datenbankservers, die Anzahl aktiver Verbindungen, CPU- und Arbeitsspeicherauslastung, Datenträgerbelegung und I/O-Wartezeiten.
Auch langsame SQL-Abfragen, Fehlerprotokolle und gegebenenfalls der Replikationsstatus sollten fortlaufend ausgewertet werden.
Geeignete Monitoring-Systeme können bei kritischen Zuständen automatisch Alarmierungen auslösen.
Tägliche Wartung großer produktiver Datenbanken
Täglich sollte überprüft werden, ob sämtliche vorgesehenen Backups erfolgreich erstellt wurden.
Außerdem empfiehlt sich eine Auswertung des Datenbankwachstums und auffälliger Performance-Veränderungen.
Besonders wichtig ist die Kontrolle, ob sich einzelne Tabellen ungewöhnlich schnell vergrößern oder die Anzahl langsamer SQL-Abfragen zunimmt.
Bei Datenbanken mit Replikation sollten zusätzlich mögliche Verzögerungen und Fehler überprüft werden.
Monatliche Wartung großer produktiver Datenbanken
Monatlich oder in einem individuell festgelegten Wartungsintervall sollten die Datenbankstruktur, die vorhandenen Indizes und die Ausführungspläne besonders ressourcenintensiver Abfragen überprüft werden.
Auch die Aktualität der Tabellenstatistiken sollte berücksichtigt werden.
Größere Bereinigungsmaßnahmen, Tabellen-Rebuilds oder strukturelle Änderungen sollten ausschließlich nach einer vorherigen Analyse und möglichst innerhalb eines Wartungsfensters erfolgen.
Regelmäßige Wiederherstellungstests
Unabhängig von der Datenbankgröße müssen Datensicherungen regelmäßig getestet werden.
Bei kleinen Blogdatenbanken kann dies beispielsweise durch die Wiederherstellung in einer separaten Testumgebung erfolgen.
Bei großen produktiven Datenbanken sollten Wiederherstellungstests Bestandteil eines dokumentierten Backup- und Notfallkonzepts sein.
Dabei sollte auch geprüft werden, wie lange eine vollständige Wiederherstellung tatsächlich dauert.
Die Wartungsintervalle sind grundsätzlich an die jeweiligen betrieblichen Anforderungen anzupassen.
15. Sicherheit der Wartungsautomatisierung
Auch ein Wartungsskript gehört zur sicherheitsrelevanten Infrastruktur.
Insbesondere auf produktiven Datenbankservern sollten deshalb einige Grundregeln eingehalten werden.
Skripte und Konfigurationsdateien dürfen nicht durch unberechtigte Benutzer verändert werden. Datenbankzugänge sollten nur die tatsächlich erforderlichen Rechte besitzen.
Passwörter gehören weder direkt in Skripte noch in Cron-Einträge oder Protokolldateien.
Wartungsprotokolle können sensible Informationen enthalten und sollten entsprechend geschützt werden.
Auch E-Mail-Benachrichtigungen sollten möglichst keine vollständigen SQL-Abfragen, personenbezogenen Datensätze oder Zugangsdaten enthalten.
Zusätzlich empfiehlt sich eine zentrale Überwachung der Skriptausführung. Damit lässt sich feststellen, wenn Wartungsaufgaben unerwartet ausfallen oder überhaupt nicht mehr gestartet werden.
16. Häufige Fehler bei der automatisierten Datenbankwartung
Ein häufiger Fehler besteht darin, sämtliche Tabellen regelmäßig automatisch optimieren zu lassen.
Das verursacht unnötige Last und kann bei großen Datenbanken erhebliche Auswirkungen auf den Betrieb haben.
Ein weiteres Problem sind Wartungsskripte, die ohne Laufzeitbegrenzung arbeiten oder mehrfach parallel gestartet werden können.
Auch unkontrolliert wachsende Logdateien sind eine typische Fehlerquelle.
Besonders kritisch sind automatisierte Löschaktionen ohne ausreichende Prüfung und Datensicherung.
Nicht zuletzt wird häufig übersehen, dass ein erfolgreich beendetes Backup-Programm noch keinen erfolgreichen Wiederherstellungstest bedeutet.
Die beste Wartungsautomatisierung arbeitet deshalb nach dem Prinzip: Automatisch überwachen, kontrolliert eingreifen und jede wichtige Änderung nachvollziehbar dokumentieren.
Fazit: Automatisierte Datenbankwartung mit Augenmaß
MySQL und MariaDB lassen sich unter Debian und Ubuntu mit überschaubarem Aufwand zuverlässig überwachen und pflegen.
Bash übernimmt die eigentlichen Prüfungen, Cron startet die Aufgaben regelmäßig, logrotate begrenzt die Größe der Protokolldateien und E-Mail-Benachrichtigungen informieren bei auffälligen Zuständen.
Für kleinere Blogdatenbanken ist diese Kombination häufig bereits eine gute Grundlage.
Bei großen produktiven Datenbanken sollte sie dagegen in eine umfassendere Monitoring-, Backup- und Wartungsstrategie eingebunden werden.
Entscheidend ist, zwischen ungefährlichen Routinekontrollen und potenziell belastenden Wartungsmaßnahmen zu unterscheiden.
Denn eine gut gepflegte Datenbank zeichnet sich nicht dadurch aus, dass ständig an ihr gearbeitet wird, sondern dadurch, dass sie zuverlässig funktioniert und notwendige Eingriffe rechtzeitig, gezielt und nachvollziehbar erfolgen.
