PythonQ 240-8XX Instrukcja Użytkownika Pobierz pdf (Strona 327)

100

101

306 MySQL - Technische Referenz f¨ur Version 5.0.1-alpha

5.10 Replikation bei MySQL

Dieses Kapitel beschreibt die verschiedenen Replikationsfeatures in MySQL. Es dient als

Referenz f¨ur die Optionen, die bei Replikation verf¨ugbar sind. Sie erhalten eine Einf¨uhrung

in die Replikation und lernen, wie Sie sie implementieren. Am Ende des Kapitels werden

einige h¨auﬁge gestellte Fragen und die dazugeh¨origen Antworten aufgelistet sowie Beschrei-

bungen der Probleme und wie man sie l¨ost.

5.10.1 Einf¨uhrung in die Replikation

Einweg-Replikation wird benutzt, um sowohl Stabilit¨at als auch Geschwindigkeit zu

steigern. Was Stabilit¨at betriﬀt, haben Sie zwei M¨oglichkeiten und k¨onnen zur M¨oglichkeit

der Datensicherung zur¨uckkehren, wenn Sie Probleme mit dem Master haben. Die

Geschwindigkeitssteigerung wird dadurch erreicht, dass ein Teil der Anfragen, die nichts

aktualisieren, an den Replikationsserver geschickt werden. Das funktioniert naturgem¨aß

nur dann, wenn Anfragen, die nichts aktualisieren, ¨uberwiegen, aber das ist der Normalfall.

Ab Version 3.23.15 unterst¨utzt MySQL intern Einweg-Replikation. Ein Server agiert als

Master, der andere als Slave. Beachten Sie, dass ein Server beide Rolle - als Master und

als Slave - in einem Paar spielen kann. Der Master h¨alt eine Bin¨ar-Log-Datei der Aktu-

alisierungen vor (siehe Abschnitt 5.9.4 [Binary log], Seite 303) sowie eine Index-Datei f¨ur

Bin¨ar-Log-Dateien, um hinsichtlich der Log-Rotation auf dem Laufenden zu bleiben. Der

Slave informiert den Master beim Verbinden dar¨uber, wo er seit der letzten erfolgreich

durchgef¨uhrten Aktualisierung aufgeh¨ort hat, schließt zu den Aktualisierungen auf, block-

iert danach und wartet darauf, dass ihn der Master ¨uber neue Aktualisierungen informiert.

Beachten Sie, dass alle Aktualisierungen auf eine Datenbank, die repliziert wird, durch den

Master durchgef¨uhrt werden sollten!

Ein weiterer Vorteil von Replikation ist, dass man permanente (live) Datensicherungen

vom System erh¨alt, wenn man die Datensicherung auf dem Slave durchf¨uhrt statt auf dem

Master. Siehe Abschnitt 5.4.1 [Backup], Seite 217.

5.10.2 Replikationsimplementation

MySQL-Replikation basiert darauf, dass der Server alle

Anderungen Ihrer Datenbank im

Bin¨ar-Log verfolgt (Updates, Deletes usw.) (siehe Abschnitt 5.9.4 [Binary log], Seite 303)

und der oder die Slave-Server die gespeicherten Anfragen aus der Bin¨ar-Log-Datei des Mas-

ters lesen, so dass der Slave dieselben Anfragen auf seine Kopie der Daten ausf¨uhren kann.

Es ist sehr wichtig sich klarzumachen, dass die Bin¨ar-Log-Datei schlicht eine Aufzeichnung

ist, die ab einem festen Zeitpunkt an startet (ab dem Moment, wo Sie Bin¨ar-Loggen starten).

Alle Slaves, die Sie aufsetzen, ben¨otigen Kopien aller Daten vom Master, wie Sie zu dem

Zeitpunkt existierten, als Bin¨ar-Loggen auf dem Master aktiviert wurde. Wenn Sie Ihre

Slaves mit Daten starten, die nicht mit dem ¨ubereinstimmen, was auf dem Master war, als

die Bin¨ar-Log-Datei gestartet wurde, funktionieren Ihre Slaves wom¨oglich nicht richtig.

Eine zuk¨unftige Version (4.0) von MySQL wird die Notwendigkeit beseitigen, (eventuell

große) Schnappsch¨usse von Daten f¨ur neue Slaves vorzuhalten, die Sie ¨uber die Live-

Datensicherungs-Funktionalit¨at aufsetzen wollen, wobei kein Sperren (Locking) erforderlich

1 2 ... 322 323 324 325 326 327 328 329 330 331 332 ... 767 768

Komentarze do niniejszej Instrukcji

Brak uwag

PythonQ 240-8XX Instrukcja Użytkownika Strona 327

Komentarze do niniejszej Instrukcji

Powiązane produkty i podręczniki dla System spawalniczy PythonQ 240-8XX