📄my.cnf – Zeile anklicken

Beispielkonfiguration für einen Server mit 16 GiB RAM. Die Standardwerte stehen jeweils dabei.

innodb_buffer_pool_size

Standardwert: 128M

Der wichtigste Wert: Cache für Daten- und Indexseiten. Auf einem reinen Datenbankserver oft ein großer Teil des RAM – aber Luft für Betriebssystem, Verbindungen und Dateicache lassen. Seit 10.2 zur Laufzeit änderbar (SET GLOBAL).

Aktiven Wert prüfen: SHOW GLOBAL VARIABLES LIKE 'innodb_buffer%';

RAM des Servers: 16 GiBAnteil für den Buffer Pool: 60 %

innodb_buffer_pool_size = 9G

= 629.145 Seiten à 16 KiB · davon ~37 % Old-Liste = 232.784 Seiten

🛂Benutzer, Rechte und Rollen

Ein Konto besteht aus Benutzer und Host. Rechte gelten global (*.*), pro Datenbank (shop.*) oder pro Tabelle – und kommen direkt oder über eine aktive Rolle.

CREATE USER 'app'@'192.0.2.%' IDENTIFIED BY 'beispiel-passwort';
GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO 'app'@'192.0.2.%';
CREATE USER 'app'@'%' IDENTIFIED BY 'beispiel-passwort';
GRANT SELECT ON shop.produkte TO 'app'@'%';

CREATE ROLE leser;        GRANT SELECT ON shop.* TO leser;
CREATE ROLE buchhaltung;  GRANT SELECT ON shop.* TO buchhaltung;
                          GRANT INSERT, UPDATE ON shop.rechnungen TO buchhaltung;
CREATE USER 'anna'@'%' IDENTIFIED BY 'beispiel-passwort';
GRANT leser, buchhaltung TO 'anna'@'%';
SET DEFAULT ROLE leser FOR 'anna'@'%';

CREATE USER 'admin'@'localhost' IDENTIFIED VIA unix_socket;
GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost';

Wer verbindet sich?

RechtTabelle shop.…

1. Konto finden

'app'@'192.0.2.%'

Beide app-Konten passen auf 192.0.2.17 – das Muster ohne führenden Platzhalter (192.0.2.%) ist spezifischer und gewinnt vor %.

2. Recht prüfen: UPDATE ON shop.rechnungen

✅ erlaubt

GRANT SELECT, INSERT, UPDATE, DELETE ON shop.*

Erlaubt durch direktes Recht.

💡 Rechte ansehen

SHOW GRANTS FOR 'anna'@'%'; · aktuelle Rolle: SELECT CURRENT_ROLE();

💡 unix_socket

Unter Linux legen die Pakete root@localhost meist mit unix_socket an: Wer als Linux-Benutzer root angemeldet ist, kommt ohne Passwort hinein – alle anderen gar nicht.

✅ Minimalprinzip

Die Anwendung bekommt nur die Rechte auf ihre Datenbank (kein GRANT OPTION, kein SUPER). Schemaänderungen über ein getrenntes Migrationskonto.

💾Backup: mariadb-dump vs. mariadb-backup

	📜 mariadb-dump	📦 mariadb-backup
Art	logisch: SQL-Anweisungen (CREATE TABLE, INSERT)	physisch: Kopie der Datendateien + Redo
Werkzeug	mariadb-dump (früher mysqldump)	mariadb-backup (früher mariabackup, Fork von Percona XtraBackup)
Server läuft weiter?	ja – mit --single-transaction konsistent für InnoDB (ein MVCC-Snapshot)	ja – kopiert im laufenden Betrieb, nutzt BACKUP STAGE für kurze Sperren
Geschwindigkeit	langsam bei großen Datenmengen, Wiederherstellen noch langsamer (Indizes neu bauen)	schnell: Dateien kopieren; Wiederherstellen = Dateien zurückkopieren
Größe	klein, gut komprimierbar, lesbar	so groß wie das Datenverzeichnis
Portabel?	ja – auch in andere Versionen oder zu MySQL (mit Anpassungen)	nur dieselbe Hauptversion, gleiche Plattform
Inkrementell	nein (Binlogs ergänzen)	ja (--incremental-basedir)
Typisch	kleine/mittlere Datenbanken, Migration, einzelne Tabellen	große Datenbanken, schnelle Wiederherstellung, neues Replikat aufsetzen

# logisch: konsistenter Snapshot, ohne Tabellen zu sperren
mariadb-dump --single-transaction --routines --triggers \
             shop | gzip > shop.sql.gz
# zurück
gunzip < shop.sql.gz | mariadb shop

# physisch: 1. kopieren  2. vorbereiten (Redo anwenden)  3. zurück
mariadb-backup --backup  --target-dir=/backup/voll
mariadb-backup --prepare --target-dir=/backup/voll
# Server stoppen, Datenverzeichnis leeren, dann:
mariadb-backup --copy-back --target-dir=/backup/voll
chown -R mysql:mysql /var/lib/mysql

⚠️ Warum --prepare?

Beim Kopieren im laufenden Betrieb ändern sich die Dateien. mariadb-backup kopiert deshalb parallel das Redo-Log und wendet es beim Vorbereiten an – genau wie eine Crash-Recovery.

✅ Point-in-Time-Recovery

Letztes Voll-Backup einspielen, dann die Binlogs ab der notierten Position bis kurz vor dem Fehler nachspielen: mariadb-binlog --stop-datetime=… mariadb-bin.000042 | mariadb. Ein Backup gilt erst als Backup, wenn die Wiederherstellung einmal geprobt wurde.