MySQL-Replikation mit SSL auf CentOS 5.4 einrichten

Dieses Tutorial zeigt schrittweise, wie Sie MySQL-Replikation zwischen zwei CentOS 5.4-Servern so einrichten, dass die Verbindung zwischen Master und Slave per SSL verschlüsselt ist. Sie erhalten Konfigurationsbeispiele für Master und Slave, Zertifikatserstellung, typische Prüfungen und eine Checkliste zur Inbetriebnahme und Fehlerbehebung.

Worum es geht

MySQL-Replikation kopiert Änderungen von einer Master-Datenbank automatisch auf einen oder mehrere Slave-Server. SSL schützt die Replikationsverbindung vor Mitlesern und sichert Anmeldedaten während der Übertragung. Hinweis: Replikation ist kein Ersatz für Backups — gelöschte Daten werden ebenfalls repliziert.

Wichtige Begriffe in einer Zeile

• Master: Der primäre MySQL-Server, von dem Änderungen repliziert werden.
• Slave: Der sekundäre Server, der Änderungen vom Master empfängt.
• Binlog: Binärlog auf dem Master, das Änderungen protokolliert.
• SSL-CA / Zertifikate: Zertifikate zum Aufbau verschlüsselter Verbindungen.

Wichtig: CentOS 5.4 ist veraltet. Planen Sie nach Möglichkeit Migration auf eine aktuelle Distribution. Die hier beschriebenen Schritte sind technisch korrekt für MySQL 5.x und CentOS 5.4, aber Sicherheitsupdates fehlen möglicherweise.

Überblick und Voraussetzungen

Kurz: zwei Server, Master (server1.example.com, 192.168.0.100) und Slave (server2.example.com, 192.168.0.101), beide CentOS 5.4. Auf dem Master existiert bereits die Datenbank exampledb; auf dem Slave noch nicht. Sie benötigen Root-Zugriff auf beide Systeme.

Vor dem Start prüfen Sie:

• Root-Login auf beiden Systemen (SSH).
• Paketmanager (yum) funktioniert und MySQL-Pakete verfügbar sind.
• Port 3306 zwischen den Hosts erreichbar (Firewall/iptables, SELinux beachten).

1 Vorbemerkung

Dieses Dokument beschreibt eine typische, praxisnahe Replikationskonfiguration. Sie können die Befehle als root ausführen. Pfade und Dateinamen entsprechen dem Beispiel; passen Sie diese an Ihre Umgebung an.

Hinweis: Wenn Sie bereits Zertifikate aus einer PKI verwenden, können Sie diese statt der hier erzeugten self-signed CA verwenden.

2 MySQL 5 installieren und SSL-Unterstützung aktivieren

Installieren Sie MySQL auf beiden Servern, falls noch nicht geschehen:

server1/server2:

yum install mysql mysql-devel mysql-server

Erzeugen Sie Autostart-Links und starten Sie den MySQL-Dienst:

chkconfig --levels 235 mysqld on
/etc/init.d/mysqld start

Setzen Sie das root-Passwort lokal auf beiden Systemen (ersetzen Sie yourrootsqlpassword):

server1:

mysqladmin -u root password yourrootsqlpassword
mysqladmin -h server1.example.com -u root password yourrootsqlpassword

server2:

mysqladmin -u root password yourrootsqlpassword
mysqladmin -h server2.example.com -u root password yourrootsqlpassword

Prüfen Sie, ob MySQL SSL unterstützt. Melden Sie sich an:

server1/server2:

mysql -u root -p

Im MySQL-Shell:

show variables like '%ssl%';

Wenn die Ausgabe have_openssl und have_ssl als DISABLED zeigt, ist SSL zwar verfügbar, aber noch nicht aktiviert. Verlassen Sie die Shell:

quit;

Öffnen Sie /etc/my.cnf und fügen Sie im [mysqld]-Abschnitt die Zeile ssl hinzu (die folgenden Konfigurationsblöcke stammen aus dem Originalbeispiel):

| [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 ssl [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid |

Starten Sie MySQL neu:

/etc/init.d/mysqld restart

Prüfen Sie erneut im MySQL-Shell mit:

show variables like '%ssl%';

Die Ausgabe sollte jetzt have_openssl und have_ssl mit YES zeigen.

Wichtig: Wenn SSL nach dem Hinzufügen von ssl weiterhin DISABLED ist, prüfen Sie die MySQL-Version. Manche Distributor-Builds deaktivieren SSL oder erfordern OpenSSL-Pakete.

3 Master konfigurieren (server1)

1. Log-Verzeichnis für Binärlogs anlegen:

server1:

mkdir /var/log/mysql
chown mysql:mysql /var/log/mysql

2. Zertifikate erzeugen

Erstellen Sie ein Verzeichnis für die Zertifikate und wechseln Sie hinein:

mkdir -p /etc/mysql/newcerts && cd /etc/mysql/newcerts

CA-Zertifikat erzeugen:

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem

Server-Zertifikat erzeugen:

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem > server-req.pem
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem

Client-Zertifikat erzeugen (für den Slave-Client):

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem > client-req.pem
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem

Die erzeugten Dateien sollten nun im Verzeichnis sichtbar sein (Beispielausgabe):

[root@server1 newcerts]# ls -l
total 32
-rw-r--r-- 1 root root 1375 Feb  8 17:37 ca-cert.pem
-rw-r--r-- 1 root root 1679 Feb  8 17:37 ca-key.pem
-rw-r--r-- 1 root root 1119 Feb  8 17:37 client-cert.pem
-rw-r--r-- 1 root root 1675 Feb  8 17:37 client-key.pem
-rw-r--r-- 1 root root  968 Feb  8 17:37 client-req.pem
-rw-r--r-- 1 root root 1119 Feb  8 17:37 server-cert.pem
-rw-r--r-- 1 root root 1679 Feb  8 17:37 server-key.pem
-rw-r--r-- 1 root root  968 Feb  8 17:37 server-req.pem
[root@server1 newcerts]#

3. Zertifikate zum Slave kopieren

Erstellen Sie zuerst auf server2 das Verzeichnis:

server2:

mkdir -p /etc/mysql/newcerts

Auf server1 kopieren Sie die CA- und Client-Dateien zum Slave (Beispiel):

server1:

scp /etc/mysql/newcerts/ca-cert.pem [email protected]:/etc/mysql/newcerts
scp /etc/mysql/newcerts/client-cert.pem [email protected]:/etc/mysql/newcerts
scp /etc/mysql/newcerts/client-key.pem [email protected]:/etc/mysql/newcerts

4. Master-MySQL konfigurieren (SSL-Pfade, Binlog, server-id)

Bearbeiten Sie /etc/my.cnf und ergänzen Sie die SSL- und Binlog-Einträge im [mysqld]-Abschnitt:

| [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 ssl ssl-ca=/etc/mysql/newcerts/ca-cert.pem ssl-cert=/etc/mysql/newcerts/server-cert.pem ssl-key=/etc/mysql/newcerts/server-key.pem server-id = 1 log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M binlog_do_db = exampledb [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid |

Starten Sie MySQL neu:

/etc/init.d/mysqld restart

5. Replikationsbenutzer anlegen

Melden Sie sich an und legen Sie einen Benutzer mit Replikationsrechten an. REQUIRE SSL erzwingt verschlüsselte Verbindungen:

mysql -u root -p

Im MySQL-Shell:

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password' REQUIRE SSL;
FLUSH PRIVILEGES;
quit;

Hinweis: Wenn REQUIRE SSL weggelassen wird, sind auch unverschlüsselte Verbindungen möglich. Sie können bestehende Nutzer mit GRANT USAGE … REQUIRE SSL auf SSL verpflichten.

6. Aktuellen Master-Status, Sperre und Dump erstellen

Auf dem Master sperren wir die Datenbank vorübergehend, ermitteln die aktuelle Binlog-Position und erzeugen einen Dump:

mysql -u root -p

Im MySQL-Shell:

USE exampledb;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Notieren Sie die Ausgabe von SHOW MASTER STATUS: File (z. B. mysql-bin.000001) und Position. Halten Sie die Shell offen, solange die Tabellen gesperrt sind.

In einem zweiten Terminal erzeugen Sie das Dump-File und kopieren es zum Slave:

server1:

cd /tmp
mysqldump -u root -pyourrootsqlpassword --opt exampledb > snapshot.sql
scp snapshot.sql [email protected]:/tmp

Anschließend im ersten Terminal die Sperre aufheben und die Shell verlassen:

server1:

UNLOCK TABLES;
quit;

4 Slave konfigurieren (server2)

1. MySQL-SSL-Optionen und server-id setzen

Bearbeiten Sie /etc/my.cnf auf dem Slave und fügen Sie im [mysqld]-Abschnitt eine eindeutige server-id, Relay-Log sowie ggf. replicate-do-db hinzu. Zusätzlich geben Sie den Pfad zur CA an, damit der Slave den Master verifiziert:

Beispiel minimal:

[mysqld]
server-id               = 2
relay_log               = /var/log/mysql/mysql-relay-bin.log
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
replicate-do-db         = exampledb
ssl
ssl-ca=/etc/mysql/newcerts/ca-cert.pem
# Optional: wenn Sie client-cert/key einsetzen möchten
# ssl-cert=/etc/mysql/newcerts/client-cert.pem
# ssl-key=/etc/mysql/newcerts/client-key.pem

Hinweis: client-cert und client-key sind notwendig, wenn der Master eine Client-Zertifikats-Authentifizierung verlangt. Bei Verwendung von REQUIRE SSL für den Replikationsuser genügt oft das Vorhandensein der CA auf dem Slave.

Starten Sie MySQL auf dem Slave neu:

/etc/init.d/mysqld restart

2. Daten importieren

Auf dem Slave importieren Sie das zuvor kopierte snapshot.sql:

cd /tmp
mysql -u root -p exampledb < snapshot.sql

3. Replikation konfigurieren (CHANGE MASTER TO)

Auf dem Slave verbinden Sie sich mit MySQL und konfigurieren die Master-Verbindung. Ersetzen Sie MASTER_LOG_FILE und MASTER_LOG_POS durch die zuvor notierten Werte.

mysql -u root -p

Im MySQL-Shell:

CHANGE MASTER TO
  MASTER_HOST='server1.example.com',
  MASTER_USER='slave_user',
  MASTER_PASSWORD='slave_password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=3096416,
  MASTER_USE_SSL=1,
  MASTER_SSL_CA='/etc/mysql/newcerts/ca-cert.pem';

START SLAVE;

Prüfen Sie den Status:

SHOW SLAVE STATUS\G

Achten Sie auf:

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes
• Last_IO_Error: (leer)

Wenn beide Running-Felder Yes anzeigen, arbeitet die Replikation.

5 Typische Fehler und Lösungen

• SSL nicht aktiv (have_ssl DISABLED): MySQL wurde ohne SSL-Bibliothek kompiliert oder ssl in my.cnf fehlt. Prüfen Sie die MySQL-Build-Optionen und OpenSSL-Pakete.
• Verbindung verweigert (ER_ACCESS_DENIED_ERROR): Benutzername/Passwort oder Host-Beschränkung stimmen nicht. Prüfen Sie GRANT-Hostangabe (‘%’ erlaubt alle Hosts).
• Dateiberechtigungen auf Zertifikaten: Private Keys müssen restriktiv sein (chmod 600 client-key.pem; Besitzer mysql:mysql, wenn MySQL sie liest).
• Firewall: Port 3306 muss erreichbar sein.
• SELinux: Falls aktiv, sind ggf. kontextspezifische Regeln nötig (audit.log prüfen).
• Master-Position falsch: Nutzen Sie genau die Werte aus SHOW MASTER STATUS zum Zeitpunkt des Dumps.

Wertvolle Zusatzinformationen und Best Practices

Factbox — Kerndaten

• Empfohlene Mindest-MySQL-Version: 5.0+ (beachten Sie Sicherheitsupdates).
• Server-IDs müssen eindeutig sein (z. B. 1 für Master, 2 für Slave).
• Binärlogs sollten auf Master aktiviert sein (log_bin).
• SSL schützt Daten in Transit, löscht aber keine Backup-Anforderungen.

Mini-Methodik (schnelle Entscheidungsheuristik)

• Haben Sie kritische personenbezogene Daten? -> SSL aktivieren + Zugriff beschränken.
• Planen Sie Failover? -> Benutzen Sie mehrere Slaves und ein Orchestrierungstool.
• Sind Master und Slave in unterschiedlichen Rechenzentren? -> Redundanz + Monitoring + Verschlüsselung zwingend.

Alternative Ansätze

• VPN statt SSL: Tunnel (z. B. IPSec/OpenVPN) verschlüsselt Netzwerkverkehr gesamthaft. Vorteil: vereinfacht Zertifikatshandling; Nachteil: zusätzlicher Komplexitätslayer.
• Global Transaction Identifiers (GTID, neuere MySQL-Versionen): Erleichtern Failover und Konsistenzprüfungen. Nicht in alten 5.0-Setups verfügbar.

Security Hardening

• Schützen Sie private Keys (Berechtigungen 600, Besitzer root oder mysql je nach Lesebedarf).
• Verwenden Sie eine zentrale PKI oder Hardware-Sicherheitsmodule (HSM) für Produktionsumgebungen.
• Rotieren Sie Passwörter und Zertifikate periodisch.
• Limitieren Sie Replikationsuser über GRANT auf nötige Rechte.

Datenschutz / GDPR-Hinweis

Replizierte Daten können personenbezogene Informationen enthalten. Verschlüsselung während der Übertragung ist eine Mindestanforderung. Prüfen Sie außerdem Zugriffsprotokolle, Aufbewahrungsfristen und löschen Sie Daten konform zu Datenschutzrichtlinien.

Checklisten (Rollenbasiert)

Master-Administrator

• Binärlog aktiviert (log_bin)
• server-id eindeutig gesetzt
• SSL-Zertifikate vorhanden und Pfade in my.cnf eingetragen
• Replikationsuser mit minimalen Rechten angelegt
• Dump erstellt und Position dokumentiert

Slave-Administrator

• CA-Zertifikat auf Slave vorhanden
• server-id anders als Master
• relay_log konfiguriert
• snapshot importiert
• CHANGE MASTER TO mit korrekter Position ausgeführt
• START SLAVE und SHOW SLAVE STATUS geprüft

Rollback/Incident Runbook (Kurz)

• Bei inkonsistentem Slave: STOP SLAVE; SHOW SLAVE STATUS\G; prüfen Last_SQL_Error/Last_IO_Error; ggf. neu synchronisieren mit frischem Dump.
• Bei kompromittiertem Key: Sperren Sie Replikation (STOP SLAVE auf Slaves), ersetzen Sie Zertifikate, setzen Sie MASTER auf Slaves neu.

Testfälle / Akzeptanzkriterien

• Nach START SLAVE zeigen Slave_IO_Running und Slave_SQL_Running Yes.
• INSERT/UPDATE/DELETE auf Master erscheinen innerhalb erwarteter Zeit auf Slave.
• Verbindung zum Master zeigt in tcpdump/wireshark verschlüsselte SSL-Handshake-Pakete (kein Klartext-Passwort).

Mermaid-Entscheidungsbaum (vereinfachte Prüfung)

flowchart TD
  A[Replikation funktioniert nicht] --> B{Fehler bei SSL?}
  B -- Ja --> C[Prüfe have_ssl, Zertifikatspfad, Berechtigungen]
  B -- Nein --> D{Fehler bei Replikation?}
  D -- Ja --> E[Prüfe MASTER_LOG_FILE/POS, GRANT-Rechte, Firewall]
  D -- Nein --> F[Prüfe Systemressourcen und Logs]

Wichtige Hinweise

• Testen Sie Änderungen zuerst in einer isolierten Testumgebung.
• Automatisieren Sie Monitoring (z. B. mit Nagios, Prometheus) für Replikationslatenz und Status.
• Planen Sie Backups zusätzlich zur Replikation ein (physische Backups, Point-in-Time-Recovery).

Zusammenfassung

Dieses Tutorial beschreibt die Einrichtung einer MySQL-Replikation mit SSL zwischen einem Master und einem Slave auf CentOS 5.4. Sie haben gelernt, wie man MySQL installiert, SSL aktiviert, Zertifikate erzeugt und verteilt, den Master für Binärlogs konfiguriert, einen Replikationsnutzer anlegt und die Slave-Seite konfiguriert. Prüfen Sie nach dem Start die Slave-Statuswerte und beachten Sie die Sicherheits- und Compliance-Empfehlungen.

Wichtige nächste Schritte

• Überprüfen Sie regelmäßig Slave-Status und Logs.
• Automatisieren Sie Zertifikatsrotation und Monitoring.
• Planen Sie ein Upgrade auf eine unterstützte OS-/MySQL-Version, um Sicherheitslücken zu schließen.

Literaturhinweis

Die gezeigten Befehle und Konfigurationen basieren auf MySQL 5.x-Konventionen. Konsultieren Sie die offizielle MySQL-Dokumentation für Ihre exakte Version bei Fragen zu Syntaxvarianten.

Ende des Tutorials.