1
MySQL Datenbankreplikation
Datenbanken im Netzwerk replizieren, als stets aktuelle Sicherungskopie oder zum Lastenausgleich
Wer eine MySQL Datenbank von einem Master auf Summe X Slave replizieren will hat es mit dem boardeigenen Mitteln der MySQL recht einfach. Trotz der Einfachheit sind einige Dinge zu beachten:
1. Alle Rechner im logischen Netzwerk
2. Gleiche MySQL Version auf allen Rechnern - ab MySQL 4 auch für MyIsam Tabellen möglich
3. Gleicher Datenbankstand auf allen Rechnern beim Start der Replikation
4. Wie immer, die nötigen Rechte
5. Original my.ini sichern
Vorbereitungen Master:
1. DB_User anlegen, lediglich Leserechte reichen aus, Schreibrechte sind nicht zu empfehlen
2. In der my.ini folgende Werte angeben:
server-id = 1
log-bin
3. Bearbeitete my.ini speichern
Was macht das denn?
Durch die Server ID wird jede Datenbank im Netzwerk eindeutig identifiziert. 1 ist immer der Master, weitere ID´s sind immer Slave und dürfen niemals doppelt vergeben werden, dazu aber später noch mehr. Durch die Aktivierung des log-bin wird dem Master klar gemacht das er wesentliche Daten in einem bestimmten Format (Binär) in eine Datei schreibt.
Was schreibt der Master denn in die Datei?
Alle datenbankverändernden Querys werden gespeichert, in der Datei ist ebenfalls ein fortlaufender Positionsschlüssel für die Slaves vorhanden.
So, wenn diese Dinge soweit eingerichtet sind, dann kann die Datenbank gestoppt werden, die Datenbank als Anfangsstand gesichert und die Datenbank wieder gestartet werden. Dazu hilft vllt. eine kleine Batchdatei:
Nach Ablauf dieses Scriptes sollte der MySQL Dienst gestartet sein und es sollten im Ordner DATA vier Dateien erstellt worden sein. Startet man nun die Anwendung die auf die Datenbank zugreift wird man sehen dass eine der Dateien, die "(Rechnername)bin.001" stetig wächst. In dieser Datei sind die Logdateien enthalten die für die Slaves die MySQL Querys enthalten.
Nun bereiten wir unseren Slave vor, dazu öffnen wir auch hier die my.ini und stellen folgende Parameter ein:
server-id = 2
master-host = "Ip-Adresse oder Hostname des Master"
master-user = "Replikationsuser"
master-password = "Password des Replikationsusers"
master-port = 3306 - wenn die MySQL auf dem Standard-Port läuft
replicate-do-db = "Datenbank"
read-only - Es wird nur lesend auf die Repliaktions-DB zugegriffen
Nach dem speichern der my.ini stoppen wir die Datenbank und kopieren uns den zuvor erstellten Datenbankstand Beginn herüber. Nachdem die Datenbank wieder gestartet wird erstellt die Replikations-DB ebenfalls einige Dateien im Ordner DATA.
Was passiert nun?
Die Replikationsdatenbank vollzieht alle Querys aus dem Master Log in der eigenen Datenbank nach. Wird die Replikationsdatenbank nun gestoppt schreibt der Repl-Slave einen Einsprungpunkt in seine eigene Log-Datei. Startet man die Datenbank wieder fängt der Slave am zuvor geschriebenen Punkt wieder an die Querys nachzuarbeiten. So bleibt die Datenbank immer auf dem aktuellen Stand.
Steigt der Rechner nun über einen netten Blue-Screen aus so ist natürlich kein Einsprungpunkt gespeichert. Also muss ich die Logdateien auf dem Slave löschen, den Datenbankstand db_beginn rüber kopieren und die Replikations-Datenbank wieder starten. Natürlich werden nun alle Querys von Beginn an nachvollzogen was auch mal etwas länger dauern kann.
Eigentlich ist die Einrichtung einer Datenbankreplikation unter MySQL eine leichte Übung für jeden Administrator. Daher ist es unverständlich warum es so wenige umsetzen.
Die Replikation einer Datenbank kann unter Umständen ein komplette Cluster-Lösung ersetzen. Speichert man die originale my.ini auf dem Slave als my.org ab und die my.ini für die Replikation als my.rep so kann mittels einem kleinen Script:
die Replikation sofort stoppen und die replizierte Datenbank als scharfe Datenbank starten. Nun braucht man nur in der Anwendung den Weg zur Datenbank neu definieren, was auch nicht das größte Problem sein sollte.
Im Rahmen des Lastenausgleiches kann man sogar reine SELECT Anweisungen auf der replizierten Datenbank ablaufen lassen und diese müssige Arbeit dem Master ersparen.
Wer eine Datenbankreplikation realisieren möchte, sich aber nicht so recht traut, dem kann ich Hilfe über TeamViewer 3.0 anbieten, dazu muss aber sicher gestellt sein, das eine Verbindung auf den oder die Rechner möglich ist.
Wer eine MySQL Datenbank von einem Master auf Summe X Slave replizieren will hat es mit dem boardeigenen Mitteln der MySQL recht einfach. Trotz der Einfachheit sind einige Dinge zu beachten:
1. Alle Rechner im logischen Netzwerk
2. Gleiche MySQL Version auf allen Rechnern - ab MySQL 4 auch für MyIsam Tabellen möglich
3. Gleicher Datenbankstand auf allen Rechnern beim Start der Replikation
4. Wie immer, die nötigen Rechte
5. Original my.ini sichern
Vorbereitungen Master:
1. DB_User anlegen, lediglich Leserechte reichen aus, Schreibrechte sind nicht zu empfehlen
2. In der my.ini folgende Werte angeben:
server-id = 1
log-bin
3. Bearbeitete my.ini speichern
Was macht das denn?
Durch die Server ID wird jede Datenbank im Netzwerk eindeutig identifiziert. 1 ist immer der Master, weitere ID´s sind immer Slave und dürfen niemals doppelt vergeben werden, dazu aber später noch mehr. Durch die Aktivierung des log-bin wird dem Master klar gemacht das er wesentliche Daten in einem bestimmten Format (Binär) in eine Datei schreibt.
Was schreibt der Master denn in die Datei?
Alle datenbankverändernden Querys werden gespeichert, in der Datei ist ebenfalls ein fortlaufender Positionsschlüssel für die Slaves vorhanden.
So, wenn diese Dinge soweit eingerichtet sind, dann kann die Datenbank gestoppt werden, die Datenbank als Anfangsstand gesichert und die Datenbank wieder gestartet werden. Dazu hilft vllt. eine kleine Batchdatei:
TITLE Anfangszustand der Datenbank wird erstellt
cls
net stop mysql
xcopy c:\mysql\data\datenbank\ c:\mysql\data\db_beginn\
if exist c:\mysql\data\db_beginn goto dbstart
if not exist c:\mysql\data\db_beginn goto error
:error
cls
ECHO Es ist ein Fehler aufgetreten...
ECHO Wenden Sie sich an den Admin
goto ende
:dbstart
cls
net start mysql
goto ende
:ende
PAUSENun bereiten wir unseren Slave vor, dazu öffnen wir auch hier die my.ini und stellen folgende Parameter ein:
server-id = 2
master-host = "Ip-Adresse oder Hostname des Master"
master-user = "Replikationsuser"
master-password = "Password des Replikationsusers"
master-port = 3306 - wenn die MySQL auf dem Standard-Port läuft
replicate-do-db = "Datenbank"
read-only - Es wird nur lesend auf die Repliaktions-DB zugegriffen
Nach dem speichern der my.ini stoppen wir die Datenbank und kopieren uns den zuvor erstellten Datenbankstand Beginn herüber. Nachdem die Datenbank wieder gestartet wird erstellt die Replikations-DB ebenfalls einige Dateien im Ordner DATA.
Was passiert nun?
Die Replikationsdatenbank vollzieht alle Querys aus dem Master Log in der eigenen Datenbank nach. Wird die Replikationsdatenbank nun gestoppt schreibt der Repl-Slave einen Einsprungpunkt in seine eigene Log-Datei. Startet man die Datenbank wieder fängt der Slave am zuvor geschriebenen Punkt wieder an die Querys nachzuarbeiten. So bleibt die Datenbank immer auf dem aktuellen Stand.
Steigt der Rechner nun über einen netten Blue-Screen aus so ist natürlich kein Einsprungpunkt gespeichert. Also muss ich die Logdateien auf dem Slave löschen, den Datenbankstand db_beginn rüber kopieren und die Replikations-Datenbank wieder starten. Natürlich werden nun alle Querys von Beginn an nachvollzogen was auch mal etwas länger dauern kann.
Eigentlich ist die Einrichtung einer Datenbankreplikation unter MySQL eine leichte Übung für jeden Administrator. Daher ist es unverständlich warum es so wenige umsetzen.
Die Replikation einer Datenbank kann unter Umständen ein komplette Cluster-Lösung ersetzen. Speichert man die originale my.ini auf dem Slave als my.org ab und die my.ini für die Replikation als my.rep so kann mittels einem kleinen Script:
net stop mysql
xcopy c:\windows\my.org c:\windows\my.ini
net start mysqlIm Rahmen des Lastenausgleiches kann man sogar reine SELECT Anweisungen auf der replizierten Datenbank ablaufen lassen und diese müssige Arbeit dem Master ersparen.
Wer eine Datenbankreplikation realisieren möchte, sich aber nicht so recht traut, dem kann ich Hilfe über TeamViewer 3.0 anbieten, dazu muss aber sicher gestellt sein, das eine Verbindung auf den oder die Rechner möglich ist.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 76444
Url: https://administrator.de/contentid/76444
Ausgedruckt am: 21.11.2024 um 20:11 Uhr
1 Kommentar
Wunderbar. Dann werd ich mich gleich morgen mal reinarbeiten. Gerade mit virtuellen Maschinen ist dieser Replikationsverbund ja schnell gebaut, über VPN verbunden.
