der hat irgendwie gesagt gehabt, dass Intelligenz so zwischen 50 und 80 Prozent in den Genen ist! .... Was eine Verschwendung! Im Kopf sind die besser aufgehoben! Jawohl aber auch!
Ich musste wahrlich schmunzeln, denn dieser Blog ist so lesbar, dass bei einer aktiven Replikation kein SELECT UUID() möglich ist. Ohne jetzt auf aktive und passive Replikation eingehen zu wollen - vor allem weil ich von der Begrifflichkeit überfordert bin - können via/mit UUID() veränderte Daten - Hierfür ist SELECT nicht der erste Kandidat - repliziert werden.
Merke: MySQL kann mehr als SBR.
RTFM :)
Merke: MySQL kann mehr als SBR.
RTFM :)
Dieser Blog beschreibt, wie das Ignorieren von Warnings und Verlassen auf Default(s|namen) die Replikation lahmlegte und warum man 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!
:)
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!
:)
Da habe ich doch vergessen für einen eigenen Vortrag auf der OSDC Werbung zu machen.
Naja war ein Vortrag zu OpenVZ. Die Konferenz selbst war sehr lustig. Viele nette Leute und sehr entspannt :)
Folien kommen auch bald ... versprochen :o)
Naja war ein Vortrag zu OpenVZ. Die Konferenz selbst war sehr lustig. Viele nette Leute und sehr entspannt :)
Folien kommen auch bald ... versprochen :o)
MovableType bietet über die atom.xml ein globales Feed für alle Blogeinträge. Will man nun für jede Kategorie ein eigenes/weiteres Feed so
Wer will kann auch noch den Tag
<mt:Entries lastn="15"> in
<mt:Entries>
ändern.
Danke an Robert Kenny, welcher mir in #movabletype die Hand hielt.
- Öffnet man aus den Index-Vorlagen die atom.xml
- Kopiert den Inhalt
- Erstellt eine neue Archiv-Vorlage
- Pastet hier den Inhalt aus der atom.xml rein
- Setzt den Typ Kategoriearchive
- Setzt als Pfad %-c/atom.xml
- fertig:)
Wer will kann auch noch den Tag
<mt:Entries lastn="15"> in
<mt:Entries>
ändern.
Danke an Robert Kenny, welcher mir in #movabletype die Hand hielt.
Diese Weisheit scheint den "Killerspielen" entnommen und so manch ein Pädagoge mag seine Warnung bestätigt finden, dass dem Spielen analoge Verhaltensmuster in anderen Kommunikationsfeldern wirkkräfig werden.
Nun denn:
In letzter Zeit habe ich mich mit init-Skripten beschäftigt und bin über die Konstruktion gestolpert, dass MySQL via mysqladmin shutdown herunter gefahren werden soll.
So portabel diese Konstruktion auch ist, es passiert nichts anderes als bei einem (weniger portablem) kill -TERM (Doku).
IMHO *das* Argument gegen mysqladmin shutdown ist:
ERROR 1040 (HY000): Too many connection
Sprich: mysqladmin kann sich nicht mal mit dem mysqld verbinden um diesen herunter zu fahren.
Beim nächsten mysql-blog wird dann gezeigt, wann obige Pädagogen Recht bekommen und KILL eben doch keine Lösung ist ;-)
Nun denn:
In letzter Zeit habe ich mich mit init-Skripten beschäftigt und bin über die Konstruktion gestolpert, dass MySQL via mysqladmin shutdown herunter gefahren werden soll.
So portabel diese Konstruktion auch ist, es passiert nichts anderes als bei einem (weniger portablem) kill -TERM (Doku).
IMHO *das* Argument gegen mysqladmin shutdown ist:
ERROR 1040 (HY000): Too many connection
Sprich: mysqladmin kann sich nicht mal mit dem mysqld verbinden um diesen herunter zu fahren.
Beim nächsten mysql-blog wird dann gezeigt, wann obige Pädagogen Recht bekommen und KILL eben doch keine Lösung ist ;-)
Nun wo ich am Flughafen auf den Flug in die Heimat warte schreibe ich schnell was zu den CLT 2010. Die CLT sind mir ja ans Herz gewachsen. Nicht nur weil ich hier regelmäßig Vorträge halten darf, sonder auch weil ich hier regelmäßig Vorträge halten darf. \o/
Dabei will ich auch nicht nachtragend sein, dass anstatt einen MySQL-Vortrag von mir zu nehmen irgendwelche Fuzzies von Percona genommen wurden.
Percona?! grmml :)
Als Schludri habe ich leider die beiden Workshops
PostgreSQL optimieren vom ads
und ORTS verpasst ARGH!
Mein eigener Vortrag zur GPLv3 (Slides) - welchen ich für misslungen hielt - wurde zu meiner Überraschung doch gut bewertet. Danke für die Nachsicht :)
Dabei will ich auch nicht nachtragend sein, dass anstatt einen MySQL-Vortrag von mir zu nehmen irgendwelche Fuzzies von Percona genommen wurden.
Percona?! grmml :)
Als Schludri habe ich leider die beiden Workshops
PostgreSQL optimieren vom ads
und ORTS verpasst ARGH!
Mein eigener Vortrag zur GPLv3 (Slides) - welchen ich für misslungen hielt - wurde zu meiner Überraschung doch gut bewertet. Danke für die Nachsicht :)
Die Kausalität ist nicht einsichtig?
Sie ist genauso einsichtig wie: Kinder mit einem Fernseher im Kinderzimmer sind bildungsfern!
Sie ist genauso einsichtig wie: Kinder mit einem Fernseher im Kinderzimmer sind bildungsfern!
Gegeben folgende Seiten:
http://web.archive.org/web/20080502185553/http://www.mysql.com/why-mysql/migration/
und
http://www.mysql.com/why-mysql/migration/
Auf beiden Seiten wird Oracle gefunden.
Tipp: Die Differenz, die Differenz! :-D
http://web.archive.org/web/20080502185553/http://www.mysql.com/why-mysql/migration/
und
http://www.mysql.com/why-mysql/migration/
Auf beiden Seiten wird Oracle gefunden.
Tipp: Die Differenz, die Differenz! :-D
Aktuelle Kommentare