Juli 2010 Archive

Moinsen,

hier sind die Vortragsfolien des OpenVZ-Vortrags auf der OSDC 2010.


 
Dieser Blog beschreibt, wie das Ignorieren von Warnings und Verlassen auf Default(s|namen) die Replikation lahmlegte und warum trotzdem die Replikation nicht neu aufgebaut werden musste.
Und alles weil die Benamsung von den relay_log_files und dem dazugehörigen Index sich geändert hat.

Was war geschehen:
Nach dem Distupgrade eines Slaves von Etch auf Lenny (hier in einem Testsystem nachgestellt) wird unter anderem MySQL upgedated:

Preparing to replace mysql-server-5.0 5.0.32-7etch12 (using .../mysql-server-5.0_5.0.51a-24+lenny4_i386.deb) ...

Der darauffolgende Start des MySQLd füllte das Errorlog wie folgt:

100630  1:19:06 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use
+'--relay-log=mysqld-relay-bin' to avoid this problem.
100630  1:19:06 [ERROR] Failed to open the relay log './slave1-relay-bin.000002' (relay_log_pos 408)
100630  1:19:06 [ERROR] Could not find target log during relay log initialization
100630  1:19:06 [ERROR] Failed to initialize the master info structure
100630  1:19:06 [Note] mysqld: ready for connections.


Vorneweg gesagt: Hätte ich die Warnings beherzigt, wäre es nicht zu dem Problem gekommen.
Die Default-Benamsung der RelayLogs hat sich zwischen den Versionen geädert.
Hier die Relevanten Files:

1. Für Debian 4.0
relay-log.info
slave4-relay-bin.index
slave4-relay-bin.000002

2. Für Debian 5.0
relay-log.info
mysqld-relay-bin.index
mysqld-relay-bin.000003

Sprich in Etch (4.0) wurde noch der Hostname im Dateinamen der RelayLogs mit eingearbeitet. In Lenny (5.0) wird statt des hostname das formschöne mysqld verwendet.

Nach einem Update schaut MySQL nun im in der relay-log.info. Dieser Name hat sich nicht geändert, wird damit nicht neu erstellt und enthält noch die Dateien/Einträge, welche es auch schon vor dem Update hatte.
Damit es nicht falsch verstanden wird. Die Daten wollen wir auch behalten! Immerhin sind dies Daten, die der SQL-Thread der Replikation noch einspielen soll.

Schauen wir mal auf diesem Testsystem nach.

# cat relay-log.info
./slave4-relay-bin.000002
408
mysql-bin.000009
13977



Um ./slave4-relay-bin.000002 zu finden schaut MySQL nun im neu erstellten mysqld-relay-bin.index nach, welcher selbst nur Einträge ala mysqld-relay.bin.... hat, anstatt wie noch vor dem Upgrade in (dem alten) slave4-relay-bin.index.
Daher kommt es dann zu der Fehlermeldung.

100630  1:19:06 [ERROR] Failed to open the relay log './slave1-relay-bin.000002' (relay_log_pos 408)

Das heisst nicht, das die Datei nicht im Filesystem existiert. Es heisst schlicht, sie steht nicht in der (neuen) IndexDatei:)

Das beherzte Setzen von relay-log in der my.cnf hätte mich vor obigen Ärger bewahrt.

Aber anstatt die Replikation *neu* Aufzubauen, reicht es die neue Index-Datei (mysqld-relay-bin.index) um die Informationen zu den alten Dateien zu erweitern.
Dazu einfach den Inhalt der slave4-relay-bin.index an den Anfang der mysqld-relay-bin.index schreiben.
Dann kennt MySQL auch die alten RelayLogs.

Moral: Don't ignore the Warnings!
:)