Seite wählen

MySQL Replikation per verschlüsselte Verbindung und caching _sha

von | Mrz 4, 2023 | Datenbanken, MySQL, Simples und Hilfreiches | 0 Kommentare

MySQL 8  

Aufbau Replikation mit SSL Verschlüsselung und neuem Passwortverfahren caching_sha2_password.

Mit MySQL 8 haben sich unterschiedliche Dinge geändert. Eine Änderung ist die sicherere caching_sha2_password Methode. Diese bringt auch zusätzliche Anforderungen mit sich. 

caching_sha2_password

Passworte für die Benutzeranmeldung an der Datenbank, werden verschlüsselt abgelegt:  Das ist nicht neu. MySQL hat jedoch mit der Version 8 ein neues Verschlüsselingsverfahren als default gesetzt. Hiermiet gehen weitere Anroferungen an Sicherheit einher.

Die caching_sha2_password Methode bietet im Vergleich zur native_password Methode ein höheres Sicherheitsniveau, indem sie ein stärkeres Hashing-Verfahren verwendet. Bei dieser Methode wird das Passwort des Benutzers mit einer Kombination aus SHA-256 und einer zufälligen Salzsequenz gehasht. Das Ergebnis wird in der Datenbank gespeichert. Wenn der Benutzer sich anmeldet, wird sein Passwort erneut gehasht und mit dem in der Datenbank gespeicherten Hash verglichen. Wenn die beiden Hashes übereinstimmen, wird der Benutzer authentifiziert. Der Unterschied zwischen den beiden Methoden besteht also darin, wie das Passwort des Benutzers gespeichert wird und welches Hashing-Verfahren verwendet wird. Die caching_sha2_password Methode bietet eine höhere Sicherheit, aber sie erfordert auch mehr Ressourcen, da die Berechnung des Hashes mehr Zeit und CPU-Leistung erfordert als bei der native_password Methode. In der Regel wird empfohlen, die caching_sha2_password Methode zu verwenden, wenn die Sicherheit eine hohe Priorität hat, z.B. bei der Speicherung sensibler Daten. Mit MySQL8 wurde caching_sha2_password eingeführt unterstützt aber auch noch das alte Verfahren. Primär um eine Datenbankmigration von MySQL5.7 auf 8 zu vereinfachen, bei existierenden Benutzerkonten.

Ein „Update“ des verschlüsselten Passworts auf das aktuelle Verfahren ist nicht möglich. Es muss neu erstellt werden. 
MariaDB Server und frühere MySQL Version z.B. 5.7 unterstützen dieses Verfahren, caching_sha2_password, nicht. Allgemein hat sich mit dieser Änderung auch folgende Sicherheits- Anforderung ergeben. MySQL erwartet bei der Verwendung mit caching_sha2_password grundsätzlich eine verschlüsselte Verbindung.  Somit sind wir beim Thema: 

Aufbau Replikation

Der Ablauf beim Aufbau der Replikation hat sich nicht geändert. Der Vollständigkeit wegen wird es dennoch festgehalten und hier die wichtigsten Schritte aufgeführt:

*Aus Gründen der Diskriminierung wurde begonnen Master und Slave als Bezeichnungen durch Source und Replikat zu ersetzen. Allerdings ist dieser Prozess noch nicht vollständig und durchgängig abgeschlossen. Daher fassen wir die ehemaligen Bezeichnungen in (). Stolpern aber ab und an über die alte Namensgebung.
MySQL- Replikation ist eine Methode, um Daten von einer MySQL-Datenbank auf eine andere zu replizieren, um Hochverfügbarkeit, Skalierbarkeit und Datensicherheit zu verbessern. Eine Replikation kann aufgebaut werden, indem man die folgenden Schritte ausführt:
  • Vorbereitung der Datenbanken: Zunächst muss sicherstellt werden, dass die MySQL-Datenbanken korrekt konfiguriert sind und über ausreichend Ressourcen verfügen. Die Replikation funktioniert nur, wenn beide Datenbanken denselben MySQL-Server und dieselbe Version nutzen. 
  • Konfiguration der Source-Datenbank: Die Source(Master)-Datenbank ist die Quelle der Daten, welche auf die Replikat (Slave) Datenbank repliziert werden. Um die Replikation zu aktivieren, müss die my.cnf-Konfigurationsdatei der Master-Datenbank ergänzt werden. Das server-id-Attribut muss eine eindeutige Nummer (ID) erhalten, um die Datenbanken (Instanzen)  zu identifizieren. Erstellen Sie einen neuen Benutzer, welcher die Replikation durchführen soll, und geben Sie diesem Benutzer die erforderlichen Replikationsrechte.
  • Erstellung von Backup: Bevor die Replikation gestartet wird, muss ein Backup der Source-Datenbank erstellt werden, um damit das Replikat zu befüllen.
  • Konfiguration der Replikat-Datenbank (Slave): Die Replikat-Datenbank ist die Ziel-Datenbank, auf die die Daten repliziert werden sollen. Bearbeiten Sie die my.cnf-Konfigurationsdatei der Replikat-Datenbank und konfigurieren Sie das server-id-Attribut auf eine eindeutige Nummer. Konfigurieren Sie die master-host, master-user, master-password, und master-port-Parameter in der my.cnf-Datei mit den Werten, die der Source-Datenbank entsprechen.
  • Starten der Replikation: Starten Sie den MySQL-Server auf der Master-Datenbank und stellen Sie sicher, dass die Replikation funktioniert. Starten Sie anschließend den MySQL-Server auf der Slave-Datenbank. Verbinden Sie sich mit der MySQL-Shell und geben Sie den Befehl START SLAVE; ein, um die Replikation zu starten.
  • Überprüfung der Replikation: Überprüfen Sie die Replikation, indem Sie auf der Slave-Datenbank eine neue Datenbank erstellen oder Daten in eine vorhandene Datenbank einfügen. Überprüfen Sie dann, ob die Änderungen auf der Master-Datenbank repliziert wurden. Verwenden Sie den Befehl SHOW SLAVE STATUS\\G auf der Slave-Datenbank, um den Status der Replikation zu überprüfen.
Anmerkung: Es ist möglich, nur einzelne Datenbanken innerhalb einer Instanz zu replizieren. Somit könnten auf einer Replikat-Instanz mehrere Datenbanken repliziert werden, welche auf unterschiedlichen Source Instanzen liegen.  Im nachfolgenden Besipiel replizieren wir eine, aber vollständig, MySQL Datenbank Instanz. 

Aufbau Replikation

Anlage der Benutzer

Ich persönlich beginne eine Replikation immer ganz von Anfang an. Sprich, ich führe die ersten Schritte wie Absicherung, Benutzeranlage etc. auf dem Master aus und hole diese Änderungen über die Replikation, nach.  Aus meiner persönliche Sicht, die konsequenteste Art die Daten und Benutzer konsistent zu halten.

Neben folgenden Paramter in der MySQL Server Konfiguration der Source (Master), vorab, muss noch der Replikations Benutzer angelegt werden:

server-id = 1
log_bin = /var/lib/mysql/mysql-bin.log
expire_logs_days = 7
max_binlog_size = 100M
Ich setze das Wissen um diese Paramter vorraus. Der Source Server hält die server-id=1 und das Replikat die server-id=2
Nur auf dem Source Server muss log_bin, definiert sein. Jede Instanz, sofern es mehrere Replikas oder Master Instanzen gibt, benötigt eine eindeutige ID. Auch die Replikas, hierüber wird über die Source und später die Änderungen welche per relay_log übermittelt werden, gesteuert.  Folgende Parameter wiederum sollten an die jeweilige Situation anpasst werden. expire_logs_days = 7
max_bin_log_size = 100M Vermutlich passt es ganz gut, bei einer hohen schreibenden Transaktionsdichte kann aber auch ein Filesystem schnell voll laufen. Fällt eine Replikation länger als 7 Tage aus, muss diese neue aufgesetzt werden. Also Backup auf der Source erstellen und auf dem Replikat einspielen.

Auf der Source legen wird der Replikationsbenutzer angelegt: Sofern gewünscht ist, dass für jede Richtung der Replikation ein Benutzer existieren soll, dann bitte eigenständig ergänzen. Das wäre jedenfalls konsequent sicherer.

Ich mache es mir einfach und lege innerhalb eines geschützten Netzwerkes einen Benutzer hierfür an. Bitte bedenkt diesen Aspekt der Sicherheit! Somit erlaube ich den Zugriff innerhalb eines privaten Netzwerkes: 192.168.0.%. 
CREATE USER 'repl'@'192.168.0.%' IDENTIFIED BY '<password>'; 
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.0.%';

Aufbau Replikation

Erstellung der Sicherung

Die Grundlage einer funktionierenden Replikation ist ein gemeinsamer Datenstamm. Diesen stellen wir hier auf dem Replikat aus der Sicherung der Source her. Mit der Information zu Binlog Position und Bin_log_file wiederum wird ein gemeinsamer Stand des Datenstammes definiert, ab welchem die Änderungen mit Laufender Replikation von der Source-Instanz zum Replikat übertragen werden. 

Bei der Sicherung über mysqldump gibt es folgende Optionen:

  • –source-data Damit wird im Dump ein „CHANGE MASTER“ Statement eingefügt.
  • –all-databases Hierbei werden alle Datenbanken gesichert.
  • –apply-replica-statements Darauf versichten wir, das macht Sinn, wenn bereits eine Replikation besteht. Z.B. wenn man später erneut eine Replication nach Abbruch aufbauen möchte. Hier wird am Ende des Dumps ein start replica; eingefügt.
Auf der Source Instanz wird über folgenden Befehl ein SQL Dump erstellt.
mysqldump --all-databases --source-data  >/mysql_all_db.sql
Aus dieser Datei entnehmen wir die Zeile mit der „CHANGE SOURCE TO“ Anweisung. Diese sieht wie folgt aus, jedoch sicherlich mit anderen Values: *Achtung, wie oben bereits angesprochen, MASTER/ SLAVE sind die alten, aber noch funktionierenden Bezeichnungen. Neu wäre SOURCE und REPLICA.
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000144', MASTER_LOG_POS=39204617
Hier fehlen noch die Informationen zur Source, Host, Replikationsbenutzer, Passwort.
Diese Zeile muss also um folgende Parameter ergänzt werden:
CHANGE MASTER TO MASTER_HOST="<YOur HOST IP", MASTER_PORT="3306", MASTER_USER="repl", MASTER_PASSWORD="<password>",MASTER_LOG_FILE='mysql-bin.000144', MASTER_LOG_POS=39204617;
Führen wir diesen Befehl aus, wird die Replikation auf dem Replikat (Slave) eingestellt. Mit start slave; wird die Repliation Schlussendlich gestartet: Geprüft werden kann es mit em Befehl: show slave status \G; \G erzeugt eine Ausgabe im Key Value Format, was deutlich leichte zu lesen ist.

Das sieht erstmal gut aus: Hier sind 3 Werte relevant:              Slave_IO_Running: Yes             Slave_SQL_Running: Yes         Seconds_Behind_Master: 0 Die 1. beiden sagen aus, dass die Replikation gestartet ist und auch das Recovery auf dem Slave läuft. Der 2. Wert sagt aus, dass der Datenstamm auf dem Replikat aktuell ist. Eine höhere Zahl ist lediglich eine Schätzung, welcher zeitlich Verzug besteht. So sieht es aus, wenn ales ok läuft: Wir haben aber u.U. einen Fehler erhalten in:                 Last_IO_Errno: 0                 Last_IO_Error:  Sinngemäss sagt die Meldung aus, das eine Anmeldung nicht erlaubt wurde. In einem Nebensatz wird noch von Zertifikat gesprochen. Ich gebe es zu, ich war zu faul mir schnell eine Spielwiese aufzubauen um den Fehler zu reproduzieren.  -> Dennoch bei der Fehlersuche stolperte ich zig Beiträge und Artikel, welche die Lösung darin sahen, den Benutzer mit der Verschlüsselungsmethode native_passwort anzulegen. Mir fällt dazu nur noch RTFM ein. https://dev.mysql.com/doc/refman/8.0/en/replication-encrypted-connections.html Wer sich die Mühe sparen will den notwendigen Public Key zu kopieren: Einfach den Change Master TO Befehle ergänzen um: GET_MASTER_PUBLIC_KEY=1

 

CHANGE MASTER TO MASTER_HOST=“<YOur HOST IP“, MASTER_PORT=“3306″, MASTER_USER=“repl“, MASTER_PASSWORD=“<password>“,MASTER_LOG_FILE=’mysql-bin.000144′, MASTER_LOG_POS=39204617, GET_MASTER_PUBLIC_KEY=1;

Feinheit zum Abschluss, Statt „MASTER_ kann auch gleich SOURCE_ verwendet werden. Lediglich beim Dump hatte ich noch die alten „Bezeichnungen“ im Dump erhalten. Beim dump hätte ich ebenfalls –source-data statt –master-data verwenden sollen. In diesem Sinne, eine sichere Verbindung und stabile Replikation.