Abfrage mehrere Datenbankserver

[Michael Donning]

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