Anzeige:
Ergebnis 1 bis 10 von 10

Thema: MySQL DB spiegeln, abgleichen - interessant für jeden -- Post von Xeno

  1. #1
    Administrator
    Registriert seit
    13.04.1999
    Ort
    Reutlingen
    Beiträge
    535

    MySQL DB spiegeln, abgleichen - interessant für jeden -- Post von Xeno

    MySQL DB spiegeln, abgleichen - interessant für jeden

    Hi Leute,

    so hier mal ein kleiner Infoaustausch.

    Folgendes,
    - zwei Datenbanken, eine im Netz eine Local
    - auf beiden das gleiche
    - Auf beiden werden Änderungen vorgenohmen

    Und jetzt soll ein Abgleich zwischen denn beiden durchgeführt werden.

    Gleich vorweg. Die Datenbanken sind zu große bzw. ich will nicht MySQL Dumb hören.

    Meine Idee war es,
    jeden DS mit einem TimeStamp zuversehen und den Abgleich über diesen Schlüssel zu machen.
    Also alles was älter als die letzte Aktualisierung ist wird upgedatet außer in der anderen Tabelle existiert eine neuerer DS.

    Die Idee spart Zeit und ist eigentlich auch effektiv. Aber eben eine Spalte Mehr pro DS.

    Wer hat noch andere Vorschläge.
    Wäre doch gelacht wenn wir da nix ordentliches finden.

    MfG
    Xeno

  2. #2
    Registrierter Benutzer Avatar von elrond
    Registriert seit
    03.10.2001
    Ort
    potsdam
    Beiträge
    881
    timestamps für so etwas zu nutzen ist eine klase idee. allerdings sollten dann beide server auf den selben timed zugreifen...

    das problem bei solchen abgleichen ist natürlich immer, dass man das problem hat, die db nicht in einen inkonsistenten zustand kommen zu lassen. das kann man meiner meinung nach nur so lösen, dass die beiden db sich einigen müssen, wer für welche tabelle als 'master' zuständig ist. das beliebte beispiel ist, das in beiden datenbanken an den selben datensets gearbeitet wird.

    möglich wäre allerdings, das die db, die gerade einen ds geschrieben hat versucht master zu werden, und nach beendigung der aktion die masterrolle wieder aufgibt. ein abglich könnte dann so aussehen, dass die master-db den erzeugten datensatz an die in diesen augenblick slave-db sendet. die slave-db verarbeitet und gibt ein ok zurück. daraufhin gibt die master-db die masterrolle wieder auf.

    das problem dabei ist, dass die db sehr häufig zur klärung der master.frage in kontakt treten müssten. entweder wird dazu auf beiden db-servern ein server prozess nötig, der immer auf die master-anforderung der anderen db wartet, oder an zentraler stelle müsste in einem file oä. eine info dazu hinterlegt sein...


    ps: ich hab schon mal irgendwann eine anwending entwickelt, in der die daten dezentral gehalten und gepflegt wurden, früher noch in clipper, also ziemlich zu fuss. ich habe mich langsam wieder davon erholt

    also, viel arbeit....
    gruss el
    Geändert von elrond (16-04-2002 um 15:20 Uhr)
    "Um die Welt zu ruinieren, genügt es, wenn jeder seine Pflicht tut." (Winston Churchill)

  3. #3
    Registrierter Benutzer
    Registriert seit
    22.05.2001
    Ort
    Friedberg (Hessen)
    Beiträge
    15

    Exclamation

    Das ist ein interessanter Ansatz und wir sollten das weiterführen, weil ich denke das es vielen helfen könnte und ich mir darüber schon die ganze Zeit gedanken mache und auch bald beruflich eine Lösung dafür haben muss.

    Ich denke aber mal folgendes, wenn auf beiden Datenbanken gearbeitet wird, kann man da dann nicht von ausgehen das der DS mit dem neusten Timestamp der aktuelleste ist. Oder unterliege ich da einem Logischen fehler?

    MfG
    Xeno

  4. #4
    Registrierter Benutzer
    Registriert seit
    22.05.2001
    Ort
    Friedberg (Hessen)
    Beiträge
    15
    Ok Fehler habe ich.

    Wenn natürlich auf A Field 1 geändert wurde und danach auf B Field 2 wird der DS von B genohmen und die änderung von A ist futsch.
    Ok das ist ein problem.

    Wie wäre es mit einen Logfile im SQL-Format die alle änderungen mit protokoliert.

    dann würde da ja so aussehen.

    SQL für a:
    Update daten set field1 = x where id = 1;

    SQL für b:
    Update dateb set field2 = z where id = 1;

    Dann würde die SQL-Datei von A auf B ausgeführt werden und umgekehrt.
    Was wäre damit?

    MfG
    Xeno

  5. #5
    Registrierter Benutzer
    Registriert seit
    28.07.2001
    Ort
    Wien
    Beiträge
    90
    ein blick ins MySQL-Manual führt zu 4.10 Replication in MySQL - vielleicht hilft das ja weiter?
    Diese Message wurde erstellt mit freundlicher Unterstützung eines frei-
    laufenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert
    frei von Micro$oft'schen Viren.

  6. #6
    Registrierter Benutzer Avatar von elrond
    Registriert seit
    03.10.2001
    Ort
    potsdam
    Beiträge
    881
    mysqlreplikation klingt gut, sieht auf den ersten blick aber so aus, als würde es nur in eine richtung funktionieren. ich werd's mal eingehender lesen...

    @xeno
    genau das ist das Problem: theoretisch muss ein update aus zwei teilen bestehen.
    1. update auf dem eigenen system,
    2. update auf dem remote-system

    die slave-db müsste solange kein update zulassen, bist das master-db beide sritte vollzogen hat. Daraus ergeben sich im erntfall fiese db-locks...

    wie gesagt, falls der mysql-demon das nicht selbst leisten kann brauchen wir auf beiden seiten einen demon, der die master-anforderung handelt und das locking der daten verwaltet.

    gruss el
    "Um die Welt zu ruinieren, genügt es, wenn jeder seine Pflicht tut." (Winston Churchill)

  7. #7
    Registrierter Benutzer
    Registriert seit
    22.05.2001
    Ort
    Friedberg (Hessen)
    Beiträge
    15
    Das ist ja alles schön und gut.

    Ich suche aber eine Lösung bei der A im Netz liegt und B local. Wobei B nicht immer aus dem Netz zu erreichen ist.
    Das heißt das B sich z.B. einmal pro Tag einwählt und einen abgleich macht. Und dann sollte auf beiden gearbeitet werden können.

    Genial wäre ein Timestamp für jedes Field, aber damit würde die Datenbank einfach zu groß werden. Aber das wäre etwas welches das Problem lösen würde.
    Mit der Vorraussetzung natürlich das der aktuellste Timestamp auch immer das aktuelleste Field dastellt.

    Das mit dem SQL-Daemon ist ja schon und gut, aber eben wohl nur in eine Richtung. Habe es vorhin mal etwas überflogen.

    Ich finden die Idee mit der Logfile ganz gut, bloß mir ist ein kleines problem aufgefallen, aber vielleicht fällt dir ja eine lösung dazu ein.

    Ich kann ja die ganzen SQL-Strings speichern, aber die meisten Updatebefehle umfassen ja immer die ganzen Fields und nicht nur das Field welches geändert wird.
    So hätten wir das gleich problem wie bei den Timestamps pro DS.

    MfG
    Xeno

    PS. Da für muss es doch eine Lösung geben. Wenn net und wir finden trotzdem eine sollten wir uns die Schützen lassen oder ihr unseren Namen geben.

  8. #8
    Registrierter Benutzer Avatar von elrond
    Registriert seit
    03.10.2001
    Ort
    potsdam
    Beiträge
    881
    um rauszukriegen welches feld sich geändert hat könnte man einen relativ einfachen mechanismus verwenden:

    pro datensatz ein weiteres feld, in den in einem Bitmuster gespeichert wird, welche felder sich geändert haben.z.B. 010000 -> Änderung am Feld 2. dezimal umgerechnet passt das gut in in integer-feld, auch bei längeren datensätzen. das problem ist nur, wer pflegt das ?
    müsste eigentlich des sql-demon direkt beim update machen... vielleicht gibt es ja sowas ?
    "Um die Welt zu ruinieren, genügt es, wenn jeder seine Pflicht tut." (Winston Churchill)

  9. #9
    Registrierter Benutzer Avatar von TheDodger
    Registriert seit
    17.05.2001
    Ort
    Hamburg
    Beiträge
    615
    Irgendwie errnnert mich das massiv an Lotus Domino/Notes

    Allerdings ist die Frage (und die Lösungsansätze hier) sehr interessant!
    Ich habe nur bedenken, das mySQL (wegen fehlender Transaktionen) dafür wirklich geeignet ist.

    Hmm, was mir gearade einfällt ... wenn man schon so einen Deamon einsetzt, muß man ihm die Möglcihkeit geben, die Master/Slave Frage zu regeln ... eben wie es bei Lotus geregelt wird.
    So könnte man eben nuere Daten von DB-B in die DB-A übernehmen, obwohl DB-A der Master ist ...
    Bodo
    Systemadmistration UNIX

  10. #10
    Registrierter Benutzer
    Registriert seit
    15.05.2002
    Ort
    Bochum
    Beiträge
    18
    Die Frage die ich dazu hätte ist (wenn ich das überhaupt richtig verstehe):

    Was macht man wenn die änderung auf der local-DB noch andere folgen mit sich bringt beispielsweise das änder bestimmter Daten in anderen Teilen oder Tabellen bevor der abgleich geschieht.
    Dann müssten diese änderungen nach dem Abgleich doch wieder rückgänig gemacht werden können (müssen).

    Und die andere Sache ist die:
    Angenommen auf der local-DB wird ein Wert so gesetzt das er eine Datensatz sperrt oder löscht.
    Zeitlich danach wird auf der Server-DB derselbe DS bearbeitet, so das er nicht sperrt oder löscht.
    Danach der Abgleich.
    Selbst wenn man einen Timestamp für jedes Field einsetzt, was wie Xeno schon gesagt hat einen gigantischen Platzaufwand ist, kann man dieses Problem einfach nicht lösen.

    Die überlegung finde ich aber sehr interessant, und koregiert mich bitte wenn ich falsch liege denn ich bin auf dem Gebiet noch ein ziemlicher Anfänger

    Gruß andreas

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •