Kapitel 5: MySQL-Datenbankadministration 321
Antwort: Mit den momentan verf¨ugbaren Features w¨urden Sie einen Master und einen Slave
(nicht mehrere Slaves) aufsetzen und ein Skript schreiben, das den Master beobachtet, um
zu sehen, ob er hochgefahren ist, und Ihre Applikationen und die Slaves anweisen, den
Master im Falle von Fehlschl¨agen zu ¨andern. Einige Vorschl¨age: set up a master und a
slave (or several slaves) und write a Skript
• Um einem Slave mitzuteilen, den Master zu ¨andern, benutzen Sie den CHANGE MASTER
TO-Befehl.
• Eine gute M¨oglichkeit, Ihre Applikationen dar¨uber informiert zu halten, wo der Master
ist, ist ein dynamischer DNS-Eintrag f¨ur den Master. Bei bind k¨onnen Sie nsupdate
benutzen, um Ihr DNS dynamisch zu aktualisieren.
• Sie sollten Ihre Slaves mit der log-bin-Option und ohne log-slave-updates laufen
lassen. Auf diese Art wird der Slave bereit sein, ein Master zu werden, sobald Sie STOP
SLAVE eingeben, RESET MASTER und CHANGE MASTER TO auf den anderen Slaves. Das
wird auch dab ei helfen, fehlgelaufene Aktualisierungen zu entdecken, die auf Grund
von Fehlkonfiguration des Slaves passieren (im Idealfall sollten Sie die Zugriffsrechte so
konfigurieren, dass kein Client einen Slave aktualisieren kann, ausser der Slave-Thread),
in Kombination mit den Bugs in Ihren Client-Programmen (die den Slave nie direkt
aktualisieren sollten).
Momentan arbeiten wir an der Integration eines Systems in MySQL, das automatisch den
Master ausw¨ahlt, aber bis es fertig ist, m¨ussen Sie Ihre eigenen Beobachtungswerkzeuge
schaffen.
5.10.8 Probleml¨osung bei Replikation
Wenn Sie den Anweisungen gefolgt sind und Ihre Replikationseinrichtung nicht funktioniert,
beseitigen Sie zun¨achst die M¨oglichkeit von Benutzerfehlern, indem Sie folgendes pr¨ufen:
• Loggt der Master in die Bin¨ar-Log-Datei? Pr¨ufen Sie das mit SHOW MASTER STATUS.
Wenn das der Fall ist, ist die Position nicht 0. Wenn nicht, ¨uberpr¨ufen Sie, ob Sie
dem Master die log-bin-Option angegeben und die server-id gesetzt haben.
• L¨auft der Slave?
¨
Uberpr¨ufen Sie das mit SHOW SLAVE STATUS. Die Antwort steht in der
Slave_running-Spalte. Wenn nicht, ¨uberpr¨ufen Sie die Slave-Optionen und ¨uberpr¨ufen
Sie die Fehler-Log-Datei auf Meldungen.
• Wenn der Slave l¨auft, hat er eine Verbindung mit dem Master hergestellt? F¨uhren Sie
SHOW PROCESSLIST aus, finden Sie den Thread mit dem System user-Wert in der User-
Spalte und none in der Host-Spalte und ¨uberpr¨ufen Sie die State-Spalte. Wenn dort
steht connecting to master, ¨uberpr¨ufen Sie die Berechtigungen f¨ur den Replikations-
Benutzer auf dem Master, den Master-Hostnamen, Ihre DNS-Einrichtung, ob der Mas-
ter tats¨achlich l¨auft, ob er durch den Slave erreichbar ist, und wenn all das in Ordnung
zu sein scheint, lesen Sie die Fehler-Log-Dateien.
• Wenn der Slave lief, aber dann anhielt, schauen Sie in die Ausgabe von SHOW SLAVE
STATUS und ¨uberpr¨ufen Sie die Fehler-Log-Dateien. Das passiert ¨ublicherweise, wenn
eine Anfrage, die auf dem Master funktionierte, auf dem Slave fehlschl¨agt. Das sollte nie
vorkommen, wenn Sie einen korrekten Schnappschuss des Masters aufgenommen haben
und die Daten nie auf dem Slave ausserhalb des Slave-Threads ver¨andern. Wenn das
doch auftritt, ist es ein Bug und sollte berichtet werden.
Comentarios a estos manuales