Lord Gurke
Nur echt mit 32 Zähnen
Hallo zusammen!
Gerade eben ist mir wieder mal bewusst geworden, warum ich eigentlich schon länger auf MySQL 5.1 updaten wollte - auch wenn das in den stabilen Repositories der meisten Distributionen noch nicht enthalten ist:
Das überholte Replikationssystem!
Bei MySQL < 5.1 gibt es nur die "Statement Based Replication", kurz SBR. Die funktioniert ja nach dem Prinzip, dass der Master-Server alle SQL-Anweisungen 1:1 in eine Datei schreibt und gleichzeitig an die angeschlossenen Slaves weiterreicht. Solange man nicht schusseligerweise auf dem Slave in den Tabellen rumhantiert, passiert da auch eigentlich nie was großartiges, wo man eingreifen müsste.
Jetzt hat die Sache einen Haken: Ich benutze ganz gerne die MySQL-Eigenen Funktionen zum Eintragen von Uhrzeiten oder UUIDs etc... - ich meine, dafür sind die ja da. Nehmen wir mal als Beispiel die Anweisung
Funktioniert prima - beim Insert wird NOW() ausgeführt und liefert den aktuellen Timestamp.
Aber was passiert, wenn die Verbindung zu einem Slave währenddessen unterbrochen war und die Replikation erst ein paar Minuten später wieder aufgenommen und nachgeführt werden kann?
Dann ist NOW() ja ein paar Minuten später und ich habe inkonsistente Datenbanken
Was mit der UUID()-Anweisung passiert, kann man sich wohl denken - im Hinblick auf die Tatsache, dass die UUID z.B. von Prozessor-Seriennummer und MAC-Adresse abhängt, kann sich jeder vorstellen, dass die UUID()-Anweisung auf jedem System grundsätzlich andere Werte liefert.
In MySQL 5.1 gibt es dafür die "Row Based Replication", RBR.
Was ist anders? Anstatt, die SQL-Anweisungen einfach 1:1 durchzureichen, werden die kritischen Anweisungen wie NOW(), UUID() und einige andere auf dem Master durch die entsprechenden Werte ersetzt und vollständiger Form an die Slaves übertragen.
Statt NOW() kommt dann am Slave bereits ein '2010-08-24 00:21:52' als normaler String an
Will heißen, egal wann diese Daten dort ankommen, bleiben die Datenbanken konsistent, da ja alles bereits vorgekaut wurde, und die Slaves nicht mehr selber eigene Werte für NOW() oder sonstwas einsetzen müssen.
Siehe in technisch korrekter Form hier:
http://dev.mysql.com/doc/refman/5.1/en/replication-sbr-rbr.html
Für mich ist das bereits ein Argument für ein Update - auch wenn ich normalerweise kein Freund von Software bin, die nicht aus dem Stable-Zweig des Repositories stammt.
Wollte das nur mal loswerden, damit andere nicht wie ich in die Falle tappen und sich wundern, warum die replizierten Datenbanken irgendwann Checksummentechnisch auseinanderdriften, obwohl keine Störungen gemeldet werden
Viele Grüße aus dem Tal
Max
Gerade eben ist mir wieder mal bewusst geworden, warum ich eigentlich schon länger auf MySQL 5.1 updaten wollte - auch wenn das in den stabilen Repositories der meisten Distributionen noch nicht enthalten ist:
Das überholte Replikationssystem!
Bei MySQL < 5.1 gibt es nur die "Statement Based Replication", kurz SBR. Die funktioniert ja nach dem Prinzip, dass der Master-Server alle SQL-Anweisungen 1:1 in eine Datei schreibt und gleichzeitig an die angeschlossenen Slaves weiterreicht. Solange man nicht schusseligerweise auf dem Slave in den Tabellen rumhantiert, passiert da auch eigentlich nie was großartiges, wo man eingreifen müsste.
Jetzt hat die Sache einen Haken: Ich benutze ganz gerne die MySQL-Eigenen Funktionen zum Eintragen von Uhrzeiten oder UUIDs etc... - ich meine, dafür sind die ja da. Nehmen wir mal als Beispiel die Anweisung
Code:
INSERT INTO `Tabelle` (`ID`, `CreateTimestamp`) VALUES (null, NOW() );Funktioniert prima - beim Insert wird NOW() ausgeführt und liefert den aktuellen Timestamp.
Aber was passiert, wenn die Verbindung zu einem Slave währenddessen unterbrochen war und die Replikation erst ein paar Minuten später wieder aufgenommen und nachgeführt werden kann?
Dann ist NOW() ja ein paar Minuten später und ich habe inkonsistente Datenbanken
Was mit der UUID()-Anweisung passiert, kann man sich wohl denken - im Hinblick auf die Tatsache, dass die UUID z.B. von Prozessor-Seriennummer und MAC-Adresse abhängt, kann sich jeder vorstellen, dass die UUID()-Anweisung auf jedem System grundsätzlich andere Werte liefert.
In MySQL 5.1 gibt es dafür die "Row Based Replication", RBR.
Was ist anders? Anstatt, die SQL-Anweisungen einfach 1:1 durchzureichen, werden die kritischen Anweisungen wie NOW(), UUID() und einige andere auf dem Master durch die entsprechenden Werte ersetzt und vollständiger Form an die Slaves übertragen.
Statt NOW() kommt dann am Slave bereits ein '2010-08-24 00:21:52' als normaler String an
Will heißen, egal wann diese Daten dort ankommen, bleiben die Datenbanken konsistent, da ja alles bereits vorgekaut wurde, und die Slaves nicht mehr selber eigene Werte für NOW() oder sonstwas einsetzen müssen.
Siehe in technisch korrekter Form hier:
http://dev.mysql.com/doc/refman/5.1/en/replication-sbr-rbr.html
Für mich ist das bereits ein Argument für ein Update - auch wenn ich normalerweise kein Freund von Software bin, die nicht aus dem Stable-Zweig des Repositories stammt.
Wollte das nur mal loswerden, damit andere nicht wie ich in die Falle tappen und sich wundern, warum die replizierten Datenbanken irgendwann Checksummentechnisch auseinanderdriften, obwohl keine Störungen gemeldet werden
Viele Grüße aus dem Tal
Max
