# Database Services on SUSE: MariaDB und PostgreSQL Masterclass

TL;DR / Management Summary In der SUSE-Welt ist MariaDB der unangefochtene Standard für relationale Datenbanken (ersetzt das klassische MySQL). Für komplexere Enterprise-Szenarien bietet SUSE hervorragende Unterstützung für PostgreSQL. Ein Senior Admin muss wissen, dass Datenbank-Workloads auf dem Standard-Btrfs-Dateisystem Performance-Probleme verursachen können (CoW-Fragmentation). Wir lernen, wie man Datenbanken unter SUSE installiert, optimiert und sicher betreibt.

# 1. Einführung & Architektur

Die SUSE Datenbank-Philosophie.

SUSE liefert MariaDB und PostgreSQL in stabilen Versionen aus, die eng mit dem System-Logging und der Firewall verzahnt sind.

# Architektur-Übersicht (Mermaid)

graph LR
    A[Applikation] -->|SQL| B[SUSE: MariaDB / PostgreSQL]
    B --> C{Storage Choice}
    C -->|Option A: Btrfs| D[Subvolume with +C NoCoW]
    C -->|Option B: XFS| E[High-Performance Partition]
    B --> F[Logging: Journald / messages]
    G[YaST DB Module] --> B

# 2. MariaDB: Der SUSE Standard

Schnell installiert, sicher konfiguriert.

# Schritt 1: Installation

sudo zypper install mariadb mariadb-client
sudo systemctl enable --now mariadb

# Schritt 2: Hardening

sudo mariadb-secure-installation
# Tipp: Deaktivieren Sie Remote-Root-Logins und löschen Sie die Test-DB.

# 3. PostgreSQL: Die Enterprise Alternative

Kraftvoll und stabil.

# Installation

sudo zypper install postgresql15-server postgresql15-contrib
sudo postgresql-setup --initdb # Initialisiert die DB-Dateien
sudo systemctl enable --now postgresql

# Management via YaST

Für PostgreSQL bietet SUSE ein eigenes YaST-Modul zur Grundkonfiguration (Ports, IP-Binding).

sudo yast2 postgresql

# 4. Day-2 Operations: Performance & Storage

Den Flaschenhals Btrfs bändigen.

Wie in Artikel 153 beschrieben, ist Copy-on-Write (CoW) Gift für Datenbank-Files (Fragmentierung).

# Das NoCoW-Setup

Wenn Ihre Datenbank unter /var/lib/mysql liegt:

# Vor der ersten Daten-Erstellung!
sudo mkdir -p /var/lib/mysql
sudo chattr +C /var/lib/mysql

# Performance Check

Nutzen Sie mysqltuner (für MariaDB) oder pg_activity (für PostgreSQL), um Engpässe live zu identifizieren.

sudo zypper install mysqltuner
mysqltuner

# 5. Troubleshooting & “War Stories”

Wenn die DB steht.

# Story 1: “Der hängende Shutdown”

Symptom: systemctl stop mariadb dauert 10 Minuten oder bricht mit einem Fehler ab. Ursache: Die Datenbank ist sehr groß und hat viele “Dirty Pages” im RAM (Buffer Pool), die erst auf die Disk geschrieben werden müssen. Lösung: Erhöhen Sie den Timeout in der systemd-Unit oder führen Sie manuell SET GLOBAL innodb_fast_shutdown = 0; vor dem Stop aus, um einen sauberen Flush zu erzwingen.

# Story 2: “Postgres Peer Authentication Error”

Symptom: Ein lokaler User kann sich nicht mit psql einloggen, obwohl das Passwort stimmt. Ursache: In RHEL/SUSE steht die pg_hba.conf standardmäßig auf peer. Das bedeutet, der Linux-Username muss exakt zum DB-Usernamen passen. Lösung: Stellen Sie in /var/lib/pgsql/data/pg_hba.conf auf md5 oder scram-sha-256 um, wenn Sie Passwörter nutzen wollen.

# 6. Fazit & Empfehlung

• Dateisystem: Nutzen Sie XFS für dedizierte Datenbank-Partitionen. Es ist performanter als Btrfs für SQL-Workloads.
• Wahl: MariaDB für klassische CMS (WordPress, Drupal) und Web-Apps. PostgreSQL für komplexe Business-Logik und große Datenmengen.
• Backup: Nutzen Sie mysqldump oder pg_dump für logische Backups und VM-Snapshots für Desaster Recovery.

# Anhang: Cheatsheet