Docker MySQL vollständiger Leitfaden: Von Datenspeicherung bis Master-Slave-Replikation

Die Fehlermeldung im Terminal traf ins Mark – zwei Wochen Testdaten, einfach weg. Am Nachmittag hatte ich den MySQL-Container neu gestartet, gedacht, es wäre ein ganz normaler Neustart. Stattdessen waren die Daten mit dem Container verschwunden.

MySQL mit Docker bereitzustellen wirkt einfach: docker run -e MYSQL_ROOT_PASSWORD=123456 mysql – und schon läuft es. Doch Datenverlust nach Neustart, Config-Mounts, die nicht greifen, Verbindungsfehler von lokalen Apps und Master-Slave-Replikation in Produktion – diese Fallstricke merkt man erst, wenn man drin steckt. Dieser Artikel führt Sie von der Datenspeicherung bis zur Replikation Schritt für Schritt durch jede relevante Konfiguration.

Grundlagen: MySQL standalone mit Docker

Der einfachste Start (und warum er nicht reicht)

Zuerst ein häufiges Missverständnis. Viele starten MySQL beim ersten Mal mit Docker so:

docker run --name mysql-test -e MYSQL_ROOT_PASSWORD=123456 -d mysql:8.0

Der Container läuft, der Status ist grün, Sie können die Datenbank bedienen – alles wirkt perfekt. Das ist aber eine Zeitbombe.

Warum? Container sind von Natur aus flüchtig. Löschen Sie den Container oder starten Sie ihn irgendwann neu, sind alle Daten weg. MySQL speichert standardmäßig unter /var/lib/mysql im Container. Wird der Container entfernt, verschwindet dieses Verzeichnis mit.

Als ich in diese Falle tappte, dachte ich zuerst, MySQL selbst wäre defekt. Später wurde klar: Das Problem war fehlende Datenspeicherung.

Datenspeicherung: Volumes richtig mounten

Kurz gesagt: Datenspeicherung bedeutet, das MySQL-Datenverzeichnis auf den Host zu mappen – der Container kann weg, die Daten bleiben.

Docker bietet drei Mount-Arten:

1. Bind Mount: Direktes Mapping eines Host-Verzeichnisses, z. B. /home/mysql/data
2. Named Volume: Von Docker verwaltetes Volume, Speicherort egal
3. tmpfs: Speicher im RAM, nach Neustart weg – praktisch nie genutzt

Seit 2024 empfiehlt Docker offiziell Named Volumes; die Performance unterscheidet sich kaum mehr von Bind Mounts. Ich nutze beides je nach Szenario: Named Volumes in der Entwicklung, Bind Mounts in Produktion für einfachere Backups.

Der vollständige Befehl:

docker run --name mysql-persistent \
  -e MYSQL_ROOT_PASSWORD=rootpwd123 \
  -p 3306:3306 \
  -v mysql-data:/var/lib/mysql \
  -d mysql:8.0

Entscheidend ist -v mysql-data:/var/lib/mysql. mysql-data ist der Volume-Name (Docker legt ihn an), /var/lib/mysql das Datenverzeichnis im Container.

So prüfen Sie, ob die Persistenz wirklich funktioniert:

# In den Container gehen und eine Datenbank anlegen
docker exec -it mysql-persistent mysql -uroot -prootpwd123 -e "CREATE DATABASE testdb;"

# Container stoppen und löschen
docker stop mysql-persistent
docker rm mysql-persistent

# Mit demselben Volume neu starten
docker run --name mysql-persistent \
  -e MYSQL_ROOT_PASSWORD=rootpwd123 \
  -p 3306:3306 \
  -v mysql-data:/var/lib/mysql \
  -d mysql:8.0

# Prüfen, ob testdb noch da ist
docker exec -it mysql-persistent mysql -uroot -prootpwd123 -e "SHOW DATABASES;"

Wenn testdb noch existiert, sind Ihre Daten sicher. Dieses Gefühl ist beruhigend.

Config-Mount: MySQL-Parameter anpassen

Datenspeicherung erledigt – als Nächstes: Wie ändern Sie MySQL-Einstellungen?

Zeichensatz auf utf8mb4 setzen oder max_connections erhöhen? Ohne Config-Mount müssen Sie jedes Mal im Container manuell ändern – und nach jedem Neustart von vorn.

MySQL liest zusätzliche Configs aus /etc/mysql/conf.d/. Dort mounten Sie Ihre my.cnf.

Zuerst auf dem Host anlegen:

mkdir -p /home/mysql/conf
cat > /home/mysql/conf/my.cnf << 'EOF'
[mysqld]
# Zeichensatz
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

# Verbindungen
max_connections=1000

# Authentifizierungs-Plugin (löst manche Client-Probleme)
default_authentication_plugin=mysql_native_password

[client]
default-character-set=utf8mb4
EOF

Beim Start die Config mit mounten:

docker run --name mysql-custom \
  -e MYSQL_ROOT_PASSWORD=rootpwd123 \
  -p 3306:3306 \
  -v /home/mysql/conf:/etc/mysql/conf.d \
  -v /home/mysql/data:/var/lib/mysql \
  -d mysql:8.0

Hier sind Config und Datenverzeichnis gleichzeitig gemountet.

Prüfen, ob die Einstellungen greifen:

docker exec -it mysql-custom mysql -uroot -prootpwd123 -e "SHOW VARIABLES LIKE 'character%';"

Steht character_set_server auf utf8mb4, ist die Config aktiv.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Externe Verbindungen ermöglichen

Container läuft, Daten persistent, Config gemountet – und Ihre lokale App verbindet sich trotzdem nicht:

ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost' (Connection refused)

oder

ERROR 1045 (28000): Access denied for user 'root'@'172.17.0.1'

Beide Fehler kenne ich. Die Ursache zu finden hat eine Weile gedauert.

Problem 1: Connection refused

Meist falsch gemappte Ports. Beim Start unbedingt -p 3306:3306 setzen, damit Port 3306 im Container auf dem Host erreichbar ist.

Ist 3306 auf dem Host schon belegt (z. B. lokale MySQL-Installation), einen anderen Host-Port wählen:

-p 3307:3306  # Host 3307, im Container weiterhin 3306

Auf Linux-Servern auch die Firewall prüfen:

# CentOS/RHEL
sudo firewall-cmd --zone=public --add-port=3306/tcp --permanent
sudo firewall-cmd --reload

# Ubuntu
sudo ufw allow 3306/tcp

Problem 2: Access denied

Das ist ein Berechtigungsthema. Der root-Benutzer darf standardmäßig nur von localhost verbinden, nicht von externen IPs.

Lösung: Host für root auf % setzen (Verbindung von jeder IP):

# In den Container
docker exec -it mysql-custom mysql -uroot -prootpwd123

# SQL ausführen
ALTER USER 'root'@'%' IDENTIFIED WITH mysql_native_password BY 'rootpwd123';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Zwei Hinweise:

1. mysql_native_password ist mit älteren MySQL-Clients oft kompatibler
2. In Produktion root niemals von überall zugänglich machen – dedizierte Benutzer mit IP-Einschränkung anlegen

Danach sollten externe Apps verbinden können.

Damit sind die Grundlagen für ein standalone Docker-MySQL abgedeckt.

Elegant verwalten mit Docker Compose

Warum Docker Compose sinnvoll ist

Für lokale Tests reichen die docker run-Befehle. Im Alltag stören aber oft:

1. Sehr lange Befehle, die man jedes Mal nachschlagen muss
2. Fehleranfällige Parameter, z. B. falscher Volume-Pfad
3. Unterschiedliche Startbefehle im Team, chaotische Konfiguration
4. Mehrere Container (MySQL + Redis + Nginx) einzeln starten ist mühsam

Hier hilft Docker Compose.

Kurz: Eine lange docker run-Zeile wandert in eine YAML-Datei. Start mit docker-compose up -d, Stopp mit docker-compose down, Versionierung in Git.

Neue Kolleginnen und Kollegen fragen „Wie starte ich MySQL?“ – Sie schicken docker-compose.yml, sie klonen und starten mit einem Befehl. Praktisch.

Docker Compose: MySQL standalone

Vollständige Konfiguration mit Erklärung:

version: '3.8'

services:
  mysql:
    image: mysql:8.0
    container_name: mysql-standalone
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpwd123
      MYSQL_DATABASE: myapp
      MYSQL_USER: appuser
      MYSQL_PASSWORD: apppwd123
    ports:
      - "3306:3306"
    volumes:
      - mysql-data:/var/lib/mysql
      - ./conf/my.cnf:/etc/mysql/conf.d/my.cnf
      - ./logs:/var/log/mysql
    networks:
      - mysql-network
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-prootpwd123"]
      interval: 10s
      timeout: 5s
      retries: 3

volumes:
  mysql-data:

networks:
  mysql-network:
    driver: bridge

Wichtige Punkte:

environment:

• MYSQL_ROOT_PASSWORD: Root-Passwort, Pflicht
• MYSQL_DATABASE: wird beim Start automatisch angelegt
• MYSQL_USER / MYSQL_PASSWORD: normaler Benutzer (sicherer als root)

volumes:

• mysql-data:/var/lib/mysql: Persistenz via Named Volume
• ./conf/my.cnf:/etc/mysql/conf.d/my.cnf: Config mit relativem Pfad
• ./logs:/var/log/mysql: Logs für Troubleshooting

restart: always: Neustart bei Absturz und nach Server-Reboot

healthcheck: regelmäßiger Ping; bei Ausfall Neustart

networks: eigenes Netz für Kommunikation mehrerer Container

Ablauf:

1. Verzeichnisstruktur:

mkdir -p mysql-docker/{conf,logs}
cd mysql-docker

2. conf/my.cnf:

[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
max_connections=1000
default_authentication_plugin=mysql_native_password

[client]
default-character-set=utf8mb4

3. docker-compose.yml (siehe oben)

4. Start:

docker-compose up -d

5. Status:

docker-compose ps

Beispielausgabe:

       Name                     Command                  State                 Ports
------------------------------------------------------------------------------------------------
mysql-standalone      docker-entrypoint.sh mysqld      Up (healthy)    0.0.0.0:3306->3306/tcp

(healthy) bedeutet: Healthcheck bestanden.

6. Logs:

docker-compose logs -f mysql

-f folgt den Logs wie tail -f. Startprobleme stehen meist in den Logs.

7. Stoppen und Container entfernen:

docker-compose down

Nur Container werden gelöscht, nicht das Volume – Daten bleiben. Alles inklusive Daten löschen:

docker-compose down -v  # Vorsicht – löscht alle Daten

Lokal entwickle ich fast nur noch mit Docker Compose: Config einmal schreiben, danach ein Befehl zum Starten und Stoppen.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Produktionsreife Master-Slave-Replikation

Kurz zur Master-Slave-Replikation

Warum Replikation?

Standalone-MySQL reicht für kleine Projekte. Mit wachsender Last wird es eng. Replikation löst vor allem:

1. Read/Write-Splitting: Master für Schreiben (INSERT, UPDATE, DELETE), Slaves für Lesen (SELECT). Die meisten Apps lesen mehr als sie schreiben – Last auf mehrere Slaves verteilen
2. Backup und Verfügbarkeit: Fällt der Master aus, liefern Slaves weiterhin Lesezugriff

Prinzip:

• Der Master schreibt Binlog mit allen Datenänderungen
• Der Slave verbindet sich, liest das Binlog
• Zwei Threads auf dem Slave: IO-Thread holt Binlog ins Relay Log, SQL-Thread führt die Statements aus
• So synchronisiert sich der Slave mit dem Master

Unter Docker im Kern:

1. Zwei Container mit unterschiedlicher server-id
2. Binlog auf dem Master
3. Slave verbindet sich und startet Replikation

Klingt aufwendig – mit Docker Compose ist es nach der Config vor allem Starten und Prüfen.

Master-Knoten konfigurieren

Der Master braucht: Binlog, server-id, Replikationsbenutzer.

1. conf/master.cnf:

[mysqld]
# Eindeutige Server-ID, Master und Slave dürfen nicht gleich sein
server-id=1

# Binäres Log aktivieren
log-bin=mysql-bin

# ROW-Format protokolliert Zeilenänderungen – sicherer
binlog-format=ROW

# Zeichensatz
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

# Optional: nur bestimmte DBs replizieren
# binlog-do-db=myapp

# Optional: DBs ausschließen
# binlog-ignore-db=mysql
# binlog-ignore-db=information_schema

2. docker-compose für den Master:

version: '3.8'

services:
  mysql-master:
    image: mysql:8.0
    container_name: mysql-master
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpwd123
      MYSQL_DATABASE: myapp
    ports:
      - "3306:3306"
    volumes:
      - master-data:/var/lib/mysql
      - ./conf/master.cnf:/etc/mysql/conf.d/master.cnf
      - ./logs/master:/var/log/mysql
    networks:
      - mysql-replication

volumes:
  master-data:

networks:
  mysql-replication:
    driver: bridge

3. Master starten:

docker-compose up -d mysql-master

4. Replikationsbenutzer anlegen:

docker exec -it mysql-master mysql -uroot -prootpwd123

SQL:

-- Replikationsbenutzer
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'replpwd123';

-- Replikationsrechte
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

FLUSH PRIVILEGES;

-- Master-Status – File und Position notieren
SHOW MASTER STATUS;

Beispielausgabe:

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 |      156 |              |                  |
+------------------+----------+--------------+------------------+

Wichtig: File und Position für die Slave-Konfiguration merken.

Slave-Knoten konfigurieren

Etwas einfacher als der Master.

1. conf/slave.cnf:

[mysqld]
# Eindeutige server-id, anders als Master
server-id=2

# Relay Log
relay-log=relay-bin

# Slave nur lesen (Schreibfehler vermeiden)
read-only=1

# Zeichensatz
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

2. docker-compose um Slave erweitern:

version: '3.8'

services:
  mysql-master:
    image: mysql:8.0
    container_name: mysql-master
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpwd123
      MYSQL_DATABASE: myapp
    ports:
      - "3306:3306"
    volumes:
      - master-data:/var/lib/mysql
      - ./conf/master.cnf:/etc/mysql/conf.d/master.cnf
      - ./logs/master:/var/log/mysql
    networks:
      - mysql-replication

  mysql-slave:
    image: mysql:8.0
    container_name: mysql-slave
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpwd123
    ports:
      - "3307:3306"  # Host-Port 3307 für Slave-Zugriff
    volumes:
      - slave-data:/var/lib/mysql
      - ./conf/slave.cnf:/etc/mysql/conf.d/slave.cnf
      - ./logs/slave:/var/log/mysql
    networks:
      - mysql-replication
    depends_on:
      - mysql-master

volumes:
  master-data:
  slave-data:

networks:
  mysql-replication:
    driver: bridge

3. Slave starten:

docker-compose up -d mysql-slave

4. Slave mit Master verbinden:

docker exec -it mysql-slave mysql -uroot -prootpwd123

SQL (File und Position durch Ihre Werte ersetzen):

-- Master-Verbindung
CHANGE MASTER TO
  MASTER_HOST='mysql-master',           -- Container-Name im Docker-Netzwerk
  MASTER_PORT=3306,
  MASTER_USER='repl',
  MASTER_PASSWORD='replpwd123',
  MASTER_LOG_FILE='mysql-bin.000003',   -- aus SHOW MASTER STATUS
  MASTER_LOG_POS=156;                   -- aus SHOW MASTER STATUS

START SLAVE;

SHOW SLAVE STATUS\G

Replikation verifizieren

Bei SHOW SLAVE STATUS\G diese Felder prüfen:

Slave_IO_Running: Yes       # IO-Thread – muss Yes sein
Slave_SQL_Running: Yes      # SQL-Thread – muss Yes sein
Seconds_Behind_Master: 0    # Verzögerung in Sekunden, 0 = synchron
Last_IO_Error:              # leer = OK
Last_SQL_Error:             # leer = OK

Sind Slave_IO_Running und Slave_SQL_Running beide Yes, läuft die Replikation.

Sync testen:

1. Daten auf dem Master:

docker exec -it mysql-master mysql -uroot -prootpwd123 -e "
USE myapp;
CREATE TABLE test_table (id INT PRIMARY KEY, name VARCHAR(50));
INSERT INTO test_table VALUES (1, 'test data');
"

2. Auf dem Slave abfragen:

docker exec -it mysql-slave mysql -uroot -prootpwd123 -e "
USE myapp;
SELECT * FROM test_table;
"

Erscheint der eingefügte Datensatz auf dem Slave, funktioniert die Synchronisation.

Typische Fehler bei der Replikation

Problem 1: Slave_IO_Running = No

Mögliche Ursachen:

• Netzwerk: gleiches Docker-Netz? docker exec -it mysql-slave ping mysql-master
• Repl-Benutzer: auf dem Master korrekt angelegt?
• Falsches Binlog-File oder Position: SHOW MASTER STATUS erneut ausführen

Problem 2: Slave_SQL_Running = No

Mögliche Ursachen:

• SQL-Fehler: Feld Last_SQL_Error lesen
• Inkonsistenz: hatte der Master schon Daten vor der Replikation, zuerst Dump auf Slave importieren

Problem 3: Seconds_Behind_Master bleibt hoch

Mögliche Ursachen:

• Slave zu schwach: CPU, RAM, Disk-I/O prüfen
• Hohe Schreiblast am Master: mehr Slaves
• Netzwerk: Latenz und Bandbreite prüfen

Slave zurücksetzen und neu konfigurieren:

-- auf dem Slave
STOP SLAVE;
RESET SLAVE;

-- CHANGE MASTER TO und START SLAVE erneut

Performance und Best Practices

Performance-Tipps für Docker MySQL

Viele fürchten Performance-Einbußen durch Docker. Früher war das spürbar; 2024 liegt der Overhead oft unter 5 %, bei I/O-lastigen Workloads kaum merkbar.

Trotzdem lohnt Feintuning:

1. Volume-Typ

• Named Volume: von Docker verwaltet, optimaler Treiber – Entwicklung
• Bind Mount: direktes Host-Verzeichnis – Produktion (Backup, Monitoring)

# Named Volume
volumes:
  - mysql-data:/var/lib/mysql

# Bind Mount
volumes:
  - /data/mysql:/var/lib/mysql

2. Netzwerkmodus

Bridge reicht meist. Für maximale Performance optional Host-Modus:

services:
  mysql:
    network_mode: "host"  # Host-Netzwerk, etwas schneller

Mit Host-Modus entfällt ports-Mapping; MySQL lauscht direkt auf Host-Port 3306.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

3. Ressourcenlimits

In Produktion Limits setzen, damit MySQL nicht den ganzen Server blockiert:

services:
  mysql:
    image: mysql:8.0
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 2G
        reservations:
          memory: 1G

Start mit docker-compose --compatibility up oder Docker Swarm.

4. Log-Rotation

Unbegrenzte Container-Logs füllen die Platte:

services:
  mysql:
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "3"

Checkliste für Produktion

Sicherheit:

1. Keine Standard- oder schwachen Passwörter

# ❌ so nicht
MYSQL_ROOT_PASSWORD: 123456

# ✅ starkes Passwort oder Docker Secrets
MYSQL_ROOT_PASSWORD: "Mx8#kL9$pQ2@vN4!"

2. Secrets für sensible Daten

services:
  mysql:
    image: mysql:8.0
    secrets:
      - mysql_root_password
    environment:
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root_password

secrets:
  mysql_root_password:
    file: ./secrets/mysql_root_password.txt

3. Netzwerk einschränken

networks:
  mysql-network:
    driver: bridge
    internal: true  # nur Container-zu-Container, kein externer Zugriff

Externer Zugriff über App-Proxy, nicht direkt auf MySQL.

Betrieb:

1. Regelmäßige Backups

#!/bin/bash
DATE=$(date +%Y%m%d_%H%M%S)
docker exec mysql-master mysqldump -uroot -prootpwd123 --all-databases > backup_$DATE.sql

# oder Datenverzeichnis archivieren
tar -czf mysql-data-backup_$DATE.tar.gz /data/mysql/

Täglich automatisieren, mindestens 7 Tage aufbewahren.

2. Healthcheck

healthcheck:
  test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-p$$MYSQL_ROOT_PASSWORD"]
  interval: 10s
  timeout: 5s
  retries: 3
  start_period: 30s

Mit Monitoring und Alerts kombinieren.

3. Logs separat mounten

volumes:
  - ./logs:/var/log/mysql

Hochverfügbarkeit:

1. Mindestens ein Master, ein Slave – besser ein Master, mehrere Slaves

Bei Read-heavy Workloads 3–5 Slaves für Lese-Last.

2. Load Balancing für Read/Write-Splitting

MySQL Router, ProxySQL oder auf App-Ebene:

• Schreiben → Master
• Lesen → Slaves (Load Balancing)

3. Failover regelmäßig testen

Nicht erst beim Ausfall merken, dass der Slave nicht hochfährt:

-- auf dem Slave
STOP SLAVE;
RESET SLAVE ALL;
SET GLOBAL read_only=0;  -- Slave zum Master machen

In Produktion MHA, Orchestrator o. Ä. für automatisches Failover.

Fazit

Kurz zusammengefasst:

Vom standalone Docker MySQL über Datenspeicherung, Config-Mounts und externe Verbindungen bis Docker Compose und produktionsreife Master-Slave-Replikation – dieser Leitfaden deckt die gängigen Deployment-Szenarien ab.

Die wichtigsten Punkte:

1. Datenspeicherung ist Pflicht – kein „nackter“ MySQL-Container mehr
2. Config-Mounts für Zeichensatz, Verbindungslimits usw.
3. Docker Compose für zentrale Config und Teamarbeit
4. Replikation ist machbar, wenn Config und Schritte stimmen
5. Sicherheit und Backups in Produktion nicht vernachlässigen

Alle Configs in diesem Artikel sind getestet und direkt nutzbar – Passwörter und Ports anpassen und starten.

Beim ersten Docker-MySQL-Deployment: mit Standalone und Persistenz beginnen, dann Replikation angehen. Schritt für Schritt.

Bei Problemen: Logs lesen – dort steht meist die Ursache. Wenn Sie nicht weiterkommen, gerne in den Kommentaren austauschen.

MySQL mit Docker ist deutlich unkomplizierter als klassisches Setup: einmal konfigurieren, überall lauffähig.