Abfrage mehrere Datenbankserver

[Stefan Reinhardt]

Sub-Betreff: SchattenDB

Hi ....
sach mal bitte .... wofür kann man das brauchen?

Ich (als alter Standard Replizierer ;) kann ausser dem "Vorteil" der 
geringeren Bandbreiten-Nutzung nicht erkennen was das soll, wofür setzt Du 
das ein? .... Wenn ich das richtig verstehe hat Dein "slave" immer eine alte 
DB auf der er rumwerkelt, oder ( und dann ist das doch eigentlich ein 
Nachteil der in keinem Verhältnis zum Vorteil steht ?!) ? 

Ich würde mich über ein paar aufklärende Worte sehr freuen ...... :-)

Gruss
Stefan

On Wednesday 07 May 2003 21:16, Technik via echtwahr.com wrote:
> 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).
>

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