Abfrage mehrere Datenbankserver

[Technik via echtwahr.com]

Hallo Michael,

> Der Master hält für jede DB zwei Versionen, einmal seine normale
Arbeits-DB
> (z.B. "master_db") und eine zweite die der Slave-DB (z.b. "master_db_old")
> entspricht, also der DB vor dem Abgleich. Letztere nenn ich immer
> "Schatten-DB".
>
> Auf dem Slave steht natürlich auch eine DB (z.B. "slave_db").
>
> Zum Replikationszeitpunkt läuft dann ein (hier perl) script, daß die
> Datenbanken master_db und master_db_old vergleicht und aus der Differenz
> sql-script(s) mit haufenweise update,insert und delete-statements (jeweils
> auf einen record bezogen) erstellt.
>
> Nach Abschluß der Differenzbildung werden die Scripts in die master_db_old
> eingespielt, somit sind danach master_db und master_db_old identisch
(sofern
> nicht zwischenzeitlich Änderungen in master_db liefen).
>
> Dann bzw parallel werden die gleichen Scripts an den slave übermittelt und
> in slave_db eingespielt, welcher dann auch abgeglichen ist.
>
>
> Sollten mal fehlerhafte SQL-Statements im Differenz-Script enthalten sein
> ist das kein (großes) Problem, da die Fehler sowohl beim Einspielen in
> master_db_old als auch in slave_db auftreten (sollten) und somit die nicht
> beseitigte Differenz solange erhalten bleibt, bis das Problem behoben ist.
>
>
> Nachteile:
> - Programme müssen selbst erstellt bzw. zugekauft werden.
> - Master wird stark belastet
> - DB auf Master ist redundant (Platzbedarf).
> - Sollten (echte) Foreign Keys definiert sein wird es knifflig, dann muß
> (mindestens) eine spezielle Reihenfolge bei Replikation der Tabellen
> beachtet werden
>
> Vorteile:
> - Transfervolumen gering (vor allem wenn scripts gepackt werden).
> - Slave-Belastung leidlich gering, und keine "ungeplanten" Belastungen
durch
> "fiese" replizierte SQL-Statements.
>
> alle Klarheiten beseitigt?
>
> Zur Performance:
> Zur Replikation einer 3,5GB DB braucht der Master immerhin so ca. 1h bis
> maximal ca. 3h (nach Blick auf die cpu-last statistik :), je nachdem
> wieviele Tabellen geändert wurden).

jau, das ar sehr aufschlußreich!

Danke!
Leider kann ich diese form nicht verwenden,
da ich Live-Zugriffe habe, also alles im Web steht!

Aber trotzdem danke für die guten Tipps!

Gruß Thomas

p.s.  ich suchen eine Fehler Nr und kann die im Handbuh niht finden:
error=13


----- Original Message ----- 
From: "Michael Donning" <donning at informenta.de>
To: <mysql-de at lists.4t2.com>
Sent: Wednesday, May 07, 2003 7:57 PM
Subject: RE: Abfrage mehrere Datenbankserver


> Hallo Thomas,
>
> > -----Original Message-----
> > From: Technik via echtwahr.com (NT7) [mailto:technik at echtwahr.com]
> > wenn ich da mal ein paar fragen zu deinen "Schatten-DB"  haben,
> > weil ich verstehe das noch nicht so 100%, kannst du mir dann ein paar
> > konkretere Infos geben?!
> >
>
> Der Master hält für jede DB zwei Versionen, einmal seine normale
Arbeits-DB
> (z.B. "master_db") und eine zweite die der Slave-DB (z.b. "master_db_old")
> entspricht, also der DB vor dem Abgleich. Letztere nenn ich immer
> "Schatten-DB".
>
> Auf dem Slave steht natürlich auch eine DB (z.B. "slave_db").
>
> Zum Replikationszeitpunkt läuft dann ein (hier perl) script, daß die
> Datenbanken master_db und master_db_old vergleicht und aus der Differenz
> sql-script(s) mit haufenweise update,insert und delete-statements (jeweils
> auf einen record bezogen) erstellt.
>
> Nach Abschluß der Differenzbildung werden die Scripts in die master_db_old
> eingespielt, somit sind danach master_db und master_db_old identisch
(sofern
> nicht zwischenzeitlich Änderungen in master_db liefen).
>
> Dann bzw parallel werden die gleichen Scripts an den slave übermittelt und
> in slave_db eingespielt, welcher dann auch abgeglichen ist.
>
>
> Sollten mal fehlerhafte SQL-Statements im Differenz-Script enthalten sein
> ist das kein (großes) Problem, da die Fehler sowohl beim Einspielen in
> master_db_old als auch in slave_db auftreten (sollten) und somit die nicht
> beseitigte Differenz solange erhalten bleibt, bis das Problem behoben ist.
>
>
> Nachteile:
> - Programme müssen selbst erstellt bzw. zugekauft werden.
> - Master wird stark belastet
> - DB auf Master ist redundant (Platzbedarf).
> - Sollten (echte) Foreign Keys definiert sein wird es knifflig, dann muß
> (mindestens) eine spezielle Reihenfolge bei Replikation der Tabellen
> beachtet werden
>
> Vorteile:
> - Transfervolumen gering (vor allem wenn scripts gepackt werden).
> - Slave-Belastung leidlich gering, und keine "ungeplanten" Belastungen
durch
> "fiese" replizierte SQL-Statements.
>
> alle Klarheiten beseitigt?
>
> Zur Performance:
> Zur Replikation einer 3,5GB DB braucht der Master immerhin so ca. 1h bis
> maximal ca. 3h (nach Blick auf die cpu-last statistik :), je nachdem
> wieviele Tabellen geändert wurden).
>
> Grüße,
> Michael Donning
>
> -- 
> Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
> -->>  http://www.4t2.com/mysql
>
>
>

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql