RootForum Community

Hallo,

ich bin gerade dabei, eine LAMP-Applikation auf mehrere Server zu verteilen. Jeder Server hat einen Apache + MySQL und soll die Datenbank-Änderungen der jeweils anderen Systeme übernehmen.

Ich würde das gerne über eine Master-Master Replikation lösen, finde dazu aber wenig sinnvolles im Netz. Hat dazu mal jemand lesenswerte Infos gefunden?

Hi, ja ich habe da mal was gefunden.
Sei aber gewarnt, wenn du das machst, musst du mit den auto increment wertern in deiner Datenbank sehr vorsichtig sein. Wenn die eine DB einen Wert hoch zählt, bekommt die andere das unter Umständen nicht sofort mit und vergibt den Wert evtl selber nochmal. Das kann zu datenchaos führen.

HTH
Cheers,
Jochen

http://www.google.de/search?hl=de&q=mys ... uche&meta=
http://jayant7k.blogspot.com/2006/06/mu ... mysql.html

Ok, danke. Und vor allem, danke für den Tipp - gibt´s dafür denn eine Lösung? Dazu fällt mir spontan gar nichts ein... und da beide Server Daten in die Datenbank loggen, wird gerade das extrem kritisch.

Tja, sicher bin ich mir nicht, aber soweit ich weiß, kann man das nur umgehen, indem man keine autoincrement Werte nutzt.

Ok, ich habe immer nach Master-Master gesucht und nicht nach Multi-Master. ;-)

Falls es noch jemanden interessiert:
http://dev.mysql.com/doc/refman/5.1/de/ ... ement.html

peterpan wrote:Ok, ich habe immer nach Master-Master gesucht und nicht nach Multi-Master. ;-)

Falls es noch jemanden interessiert:
http://dev.mysql.com/doc/refman/5.1/de/ ... ement.html

Seltsamerweise wird das, was da gemacht wird, von vielen Leuten als Multi-Master oder Master-Master-Replikation bezeichnet. Es ist weder das eine noch das andere, es ist eine kreuzweise normale Replikation. Insbesondere gibt es außer dem aii (auto_increment_increment) und aio (auto_increment_offset) keine weiteren Mechanismen, mit denen man in irgendeiner Weise Kollisionen verhindern kann. Aber ein gleichzeitiger Insert auf zwei Maschinen ist ja nur ein Kollisionsszenario zwischen zwei Servern, weitere sind jederzeit denkbar.

Richtiges Multimaster mit Conflict Resolution und weiteren Effekten war für 5.1 geplant, hat es aber nicht in die Beta geschafft. Daher werden wir bis 5.2 auf MM waren müssen.

Mmhhh... bin ich der Einzige, der sowas braucht ;-) oder denke ich da "einfach zu einfach"?

Im Prinzip habe ich bei dieser Applikation gar nicht viel, was sich so richtig in die Quere kommen könnte - eben außer den IDs.

@isotopp
Hast Du eine andere/einfachere Idee, sowas umzusetzen?

Du könntest auch zwei Master<->Slave aufsetzen und umgehst dadurch die Limitierungen, sofern beide Server die zusätzliche Last vertragen.

peterpan wrote:Im Prinzip habe ich bei dieser Applikation gar nicht viel, was sich so richtig in die Quere kommen könnte - eben außer den IDs.

Was genau willst Du denn aufsetzen, und warum?

Die Applikation enthält u.a. einen Adserver für Keyword-Advertising. Der Datenbestand ansich ist dabei relativ unkritisch, da er sich nicht ständig ändert. Aber das Tracking wird live ausgewertet und muß daher in beiden Systemen identisch sein.

Das läuft aktuell auf einer einzelnen Maschine. Die neue Lösung sollte auch als Failover laufen. Wenn also einer der Server ausfällt, darf die Anwendung langsamer sein - aber nicht offline.

peterpan wrote:Die Applikation enthält u.a. einen Adserver für Keyword-Advertising. Der Datenbestand ansich ist dabei relativ unkritisch, da er sich nicht ständig ändert. Aber das Tracking wird live ausgewertet und muß daher in beiden Systemen identisch sein.

Das läuft aktuell auf einer einzelnen Maschine. Die neue Lösung sollte auch als Failover laufen. Wenn also einer der Server ausfällt, darf die Anwendung langsamer sein - aber nicht offline.

Und warum reicht Dir da nicht eine einfache Master-Slave Replikation?

Sorry, ich stehe auf dem Schlauch:

Was macht denn mein Slave mit den Tracking-Daten, wenn sein Master offline ist?

peterpan wrote:Sorry, ich stehe auf dem Schlauch:

Was macht denn mein Slave mit den Tracking-Daten, wenn sein Master offline ist?

Nix. Er ist ja ein Slave, und deswegen read-only.

Aber wieso bekommt er überhaupt writes?

Warten bis der Master wieder online ist, oder er übernimmt nach kurzer Rekonfiguration den Job des Master.

peterpan wrote:Die neue Lösung sollte auch als Failover laufen. Wenn also einer der Server ausfällt, darf die Anwendung langsamer sein - aber nicht offline.

Ich habe zwei identische Systeme und einen RR-DNS mit zwei A-Records.

Joe User wrote:Warten bis der Master wieder online ist, oder er übernimmt nach kurzer Rekonfiguration den Job des Master.

Das wäre kein Failover.

peterpan wrote:

peterpan wrote:Die neue Lösung sollte auch als Failover laufen. Wenn also einer der Server ausfällt, darf die Anwendung langsamer sein - aber nicht offline.

Ich habe zwei identische Systeme und einen RR-DNS mit zwei A-Records.

Die sind sticky für was immer Dein nscd für einen Timeout hat (5 Min typisch). Das bedeutet, auch bei Master-Master klemmt sich der Writer fest und nach 5 Minuten bekommt er zufällig einen funktionierenden Server oder den toten.

Das funktioniert so einfach nicht.

Wenn Du die beiden MySQL-Server mit heartbeat verdrahtest, kann es besser funktionieren, aber dann reicht Master-Slave. Das Failback ist sowieso kompliziert, und das Failover kann den Slave dann zum Master oder Standalone befördern.

peterpan wrote:

Joe User wrote:Warten bis der Master wieder online ist, oder er übernimmt nach kurzer Rekonfiguration den Job des Master.

Das wäre kein Failover.

Dafür per Cron in <2Minuten realisierbar...

isotopp wrote:Die sind sticky für was immer Dein nscd für einen Timeout hat (5 Min typisch). Das bedeutet, auch bei Master-Master klemmt sich der Writer fest und nach 5 Minuten bekommt er zufällig einen funktionierenden Server oder den toten.

Timeout ist eine Minute.

isotopp wrote:Das funktioniert so einfach nicht.

Ich hätte gedacht, der ausgefallene Server repliziert nach seiner Auferstehung und alles ist wieder gut.

isotopp wrote: Wenn Du die beiden MySQL-Server mit heartbeat verdrahtest, kann es besser funktionieren, aber dann reicht Master-Slave. Das Failback ist sowieso kompliziert, und das Failover kann den Slave dann zum Master oder Standalone befördern.

Ok, dann muß ich mir da selbst was basteln... :-(

Danke Euch auf jeden Fall vielmals.

Joe User wrote:Dafür per Cron in <2Minuten realisierbar...

Ja, stimmt.

isotopp wrote:Das funktioniert so einfach nicht.

Ich hätte gedacht, der ausgefallene Server repliziert nach seiner Auferstehung und alles ist wieder gut.

Du hast mehr als dieses Problem.

Du hast zwei Server links und rechts. Unter dem Namen mysql.deinedomain.de lieferst Du beide IPs in zufälliger Reihenfolge aus, wenn nach mysql.deinedomain.de gefragt wird.

Deine Anwendung hat bisher auf links geschrieben, aber links geht runter. Deine Anwendung hängt einen Timeout lang, und fragt dann neu nach den IPs. Dein DNS liefert immer noch beide Namen, und Deine Anwendung (wie auch jeder andere) hat eine 50% Chance, eine Inaktive IP bei der großen IP-Lotterie zu gewinnen.

Dann ist die Frage, warum links runtergekommen ist.

Wenn links runtergefahren wurde, dann ist nach einem Restart links korrekt initialisiert und liest das Binlog von rechts weiter da wo er aufgehört hat. Außerdem ist rechts dann in der Lage, mit der alten auf rechts gespeicherten Binlog-Position von links weiter zu machen, denn die hat sich ja nicht geändert.

Wenn links aber platt war und von einem Backup oder rechts neu aufgesetzt wurde (etwa weil neue Platten drin sind), dann hat links kein Binlog mehr. Der Slave auf rechts muß also neu aufsetzen, und die Inhalte von rechts und links müssen zueinander passen.

Es ist also nicht damit getan, links einfach wieder in Betrieb zu nehmen, sondern man muß aufpassen, daß die beiden auf demselben Stand sind, und daß die Binlog-Positionen zu dem jeweiligen Stand passen.

isotopp wrote: Wenn Du die beiden MySQL-Server mit heartbeat verdrahtest, kann es besser funktionieren, aber dann reicht Master-Slave. Das Failback ist sowieso kompliziert, und das Failover kann den Slave dann zum Master oder Standalone befördern.

Ok, dann muß ich mir da selbst was basteln... :-(

Normal würde man halt links und rechts als jeweils eine physikalische IP (etwa .2 und .3) aufsetzen. mysql würde man zu einer virtuellen IP .4 auflösen. Die .4 würde man dann einem Server (etwa links) als Sekundäre IP auf dem Interface zuordnen (also auf eth0:1 würde man .4 laufen lassen), verwaltet von heartbeat.

Wenn links runter geht, bemerkt das heartbeat auf rechts, und fährt links runter, greift sich die IP und fährt die auf eth0:1 auf rechts hoch. Außerdem fährt es ein weiteres Script, damit ein mysqld auf rechts auf .4 hochkommt. Dieses Script kann dann auch aus dem bisherigen Slave auf rechts einen Standalone machen.

Für die Anwendung ändert sich nix - die schreibt immer auf .4 (mysql).

Danke für die ausführlich Antwort. Dennoch haben wir immer noch ein Verständnisproblem weil ich mich unklar ausgedrückt habe.

isotopp wrote:Du hast mehr als dieses Problem.

Du hast zwei Server links und rechts. Unter dem Namen mysql.deinedomain.de lieferst Du beide IPs in zufälliger Reihenfolge aus, wenn nach mysql.deinedomain.de gefragt wird.

Ich habe einen Server links (www1.domain.de) und einen Server rechts (www2.domain.de). Auf beiden läuft ein Apache und die gleiche Anwendung, die jeweils in die lokale (!) DB des jeweiligen Servers schreibt.

Ich habe weiterhin zwei A-Records für zwei unterschiedliche IPs für http://www.domain.de, die im RR-Verfahren auf www1 oder www2 verteilt werden. Bei einem Ausfall von www1 wird dessen IP nicht mehr ausgeliefert und andersrum genauso bei www2 (Ok, in der Praxis gibt´s Probleme mit DNS-Caching, in 90% der Fälle geift aber meine TTL [= 1M]).

isotopp wrote:Deine Anwendung hängt einen Timeout lang, und fragt dann neu nach den IPs.

Hängt sie wirklich bei zwei Mastern? Normalerweise sollte dann doch nur die Replikation hängen. Sehe ich das falsch?

isotopp wrote:Dein DNS liefert immer noch beide Namen

Nein, macht er nicht. ;-)

isotopp wrote:Wenn links runtergefahren wurde, dann ist nach einem Restart links korrekt initialisiert und liest das Binlog von rechts weiter da wo er aufgehört hat. Außerdem ist rechts dann in der Lage, mit der alten auf rechts gespeicherten Binlog-Position von links weiter zu machen, denn die hat sich ja nicht geändert.

Genau - und mehr wollte ich eigentlich gar nicht haben.

isotopp wrote:Wenn links aber platt war und von einem Backup oder rechts neu aufgesetzt wurde (etwa weil neue Platten drin sind), dann hat links kein Binlog mehr. Der Slave auf rechts muß also neu aufsetzen, und die Inhalte von rechts und links müssen zueinander passen.

Das stimmt. Aber ich habe in meinem Szenario Zeit, das zu prüfen.

isotopp wrote:Wenn links runter geht, bemerkt das heartbeat auf rechts, und fährt links runter, greift sich die IP und fährt die auf eth0:1 auf rechts hoch. Außerdem fährt es ein weiteres Script, damit ein mysqld auf rechts auf .4 hochkommt. Dieses Script kann dann auch aus dem bisherigen Slave auf rechts einen Standalone machen.

Ok, das wäre eine saubere Lösung, ist mir aber etwas zu kompliziert. Ideal wäre, wenn beide MySQL-Server von einander abschreiben, daher war mein Gedanke die Multi-Master-Lösung.

Ich werde das mal ausprobieren und berichten. :-)

Hier ein sehr interessanter Artikel zum Thema:
http://www.onlamp.com/pub/a/onlamp/2006 ... tml?page=1

Ich habe es nur kurz überflogen, aber Seiten 1 bis 3 hat isotopp ja bereits erläutert und die Seiten 4 bis 6 sind nur einer von mehreren eher experimentellen Workarounds und ist (wenn ich es nicht zu schnell überflogen habe) für ein Setup mit nur zwei Servern overkill.

Mal sehen was isotopp davon hält...

Ich dachte mir, ich poste es trotzdem mal. Für meine Config werde ich es so mal testen - ich habe mittelfristig auch mit 4-n Servern zu tun, daher trifft sich das ganz gut.