MySQL Syncronisierung mit 2 Servern..

society

society

Registered User
Hallo Leute,

stehe im Moment auf dem Schlauch wer kann mir sagen
wie ich es schaffe das 2 MySQL Datenbanken Identisch sind und in beide Richtungen Synronisieren..
Sprich Server A wird was geändert Server B übernimmt es
Wird auf Server B etwas geändert so übernimmt Server A es genauso...

Master/Slave geht nur in eine Richtung...
Cluster?? mit Boardmitteln?

Hoffe jemand kann mir dabei auf die Sprünge helfen
 
Weiss nicht ob das geht?
Dachte immer bei einem MySQL-Cluster gibt es nur einen MASTER (auf dem die Änderungen gemacht werden) und mehrere SLAVEs (welche die Änderungen übernehmen).

Obs möglich ist alle gegeneinander abzugleichen bezweifle ich?

Hab aba folgenden Link gefunden:
http://www.tecchannel.de/news/themen/server/430099/index.html
vielleicht hilft dir der weiter

lg aus linz
franzi

================
stumpner.MCS
Webhostung, CMS und
Bilddatenbanksysteme
http://www.stumpner.net
 
Hi,
nicht ganz, sagte ja die Master/Slave Geschichte geht nur in eine Richtung.
Es muss ein Weg geben es in beide Richtungen Syncronisieren zu lassen.
 
society said:
Es muss ein Weg geben es in beide Richtungen Syncronisieren zu lassen.
Click to expand...
Keinen Automatischen/vorgefertigten.
Ich habe dazu mal ein spezielles Programm geschrieben, welches aber nicht so leicht angepasst werden kann. Besonderes Problem sind immer die Löschvorgänge. Diese müssen von der Software in einer extra Tabelle protokolliert werden, damit sie bei der nächsten Replikation übertragen werden.

Falls Du genauere Infos zum Selberschreiben brauchst, frag noch mal.

huschi.
 
society said:
Wie wäre es mit nem Quellcode oder Programm? ;) ( per PN? )
Click to expand...
Geht nicht, da es eine 'Exclusiv-Entwicklung' war. Ich kann Dir leider nur die Idee vermitteln.

huschi.
 
Hmmmm für was brauchst Du denn die Replikation in 2 Richtungen?
Du weisst ja sicherlich, dass der Slaveserver zum Master werden kann, wenn der ursprüngliche Master ausfällt. Nur solltest Du aufpassen, dass es nicht 2 Master gibt, denn sonst, wären die Datenbanken nicht mehr konsistent.

Es ist geplant eine 2 Wege-Replikation zu implimentieren - wie weit die Jungs allerdings damit sind weiss ich nicht. Spiele selbst nur mit 4.1xxx Servern rum *g*
 
Das Problem ist das dies vorkommen kann sobalt ein Server ausfällt. Nachdem es aber Kritische Seiten sind (Arbeite doch der Zeit bei der Schweizer behörde) sollte dieses in beide Richtungen sein.
 
Versteh ich trotzdem noch nicht ganz.
Du hast einen Masterserver A und einen Slaveserver B.
A ist der Server auf den du ausschliesslich in die DB schreibst.

Nehmen wir mal an A würde ausfallen. Server B würde zum Master werden und wäre nun sofort verfügbar. In der Zwischenzeit kann Server A ausgetauscht oder repariert werden. Danach machst Du Server A dann zum Slave oder spielst die bin-logs wieder auf A um die Ursprüngliche Replikationsreihenfolge wiederherzustellen.
Die Replikation in beide Richtungen ist nur dann von Bedeutung, wenn Du in die DB von beiden Servern schreiben möchtest.

So hab ich die Thematik jedenfalls verstanden - sind hier allerdings auch erst seit kurzer Zeit am testen *g*
 
Also wenn Eure Anwendung tatsächlich in beide Server schreibt, dann werden die Datenbanken nie konsitent sein können bei einer one-way-replication.

Man macht es i.d.R. eher so, dass man die Lese-Schreibzugriffe entsprechend aufteilt.
z.B. 40% Schreiben : 60% Lesen
Hier würde man in den Master Server Schreiben lassen und nur die Abfragen dem Slave überlassen :)
 
Du Verstehst es nicht so wie ich es meine die Server sollen 100% Identisch sein nix mit der eine Master der andere Slave....
Sogar das muss 100% gleich sein. Es geht darum das im Falle das ein Server ausfällt er die Daten vom anderen übernimmt... dies aber Automatisch
 
Du Verstehst es nicht so wie ich es meine die Server sollen 100% Identisch sein nix mit der eine Master der andere Slave....
Click to expand...

Genau das ist der Sinn der oben beschrieben Replikation. Wobei Du natürlich eine ganz geringe Zeitdiferenz hast, mit der die Daten dann beim Slave angekommen sind - dieser bewegt sich allerdings im Millisekundenbereich.


Sogar das muss 100% gleich sein. Es geht darum das im Falle das ein Server ausfällt er die Daten vom anderen übernimmt... dies aber Automatisch
Click to expand...
Wenn Du o.g. Replikation benutzt sind die Daten immer zu 99,9% gleich. 100% kannst Du aber auch erreichen, wenn der Master nicht grad in dem Moment abschmiert, wo er grad repliziert.

Ich verstehe also immer noch nicht so ganz, wo das Problem liegt?!?
 
society said:
Du Verstehst es nicht so wie ich es meine die Server sollen 100% Identisch sein nix mit der eine Master der andere Slave....
Sogar das muss 100% gleich sein. Es geht darum das im Falle das ein Server ausfällt er die Daten vom anderen übernimmt... dies aber Automatisch
Click to expand...

Sag am besten mal, ws du genau machen willst und wieso man dafür 2 Mysql Server braucht?
 
Sorry, mehr darf ich mich nicht dazu äussern... aber inzwischen haben wir nen anderen Weg gefunden.
 
monotek said:
Sag am besten mal, ws du genau machen willst und wieso man dafür 2 Mysql Server braucht?
Click to expand...
Bei mir war es folgendes:
Eine Firma mit 10 Niederlassungen:
Davon arbeiten 8 auf dem 'externen' Server.
2 große Niederlassungen arbeiten jeweils auf ihrem 'internen' Servern.
Da aber die NL 1 auch mal Daten von NL 2 bearbeitet, muß die Datenbank fast Augenblicklich auch auf den anderen Servern zur verfügung stehen.

Das konnte man lediglich durch eigene Software lösen.
Dabei wird als Hauptreplikation der externe Server genutzt, mit dem sich die internen Server jeweils abgleichen.
Jeder Server hat einen eigenen ID-Bereich für die Primaries, so daß es hier schon mal keine Duplikate gibt. Alle Datensätze haben einen aktuellen Zeitstempel, so daß die Software Änderungen sofort erkennt. Schwer war lediglich das Löschen von Datensätzen.
Eine Lösung wäre gewesen, pro Datensatz ein 'gelöscht'-Flag zu setzten. Hätte aber ziemlich schnell zu Performance-Einbusen geführt. Daher wird eine eigene Tabelle für gelöschte Datensätze geführt, die vor der Replikation ausgetauscht wird.

Das ganze muß natürlich entsprechend abgesichert sein:
SSL-Tunnel, Schutz vor Abbruch des Datastream, etc.

Nachteil dieser Lösung:
Die gesammte Software muß darauf ausgelegt sein: eigenen ID-Kreis beachten, beim Update den Zeitstempel setzten und gelöschte Datensäzte in der entsprechende Tabelle notieren.
Dies wurde aber durch einen eigene DB-Wrapper-Library gelöst.

Soviel zur Theorie, die ich in eine Closed-Source Server-Client-Lösung umgesetzt habe.

huschi.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top