RE: SQL Replikation

On Thu, 8 Jan 2004, Hannes Widmer wrote:

> Ist denn die Last das Problem ?.....

Das musst Du besser wissen. Ich wollte mir sagen, dass prinzipiell der
Slave genau das macht, was der Master Slave tut, drum also die selbe Last
"vertragen" muss.

Wobei ich mir inzwischen nicht mehr ganz sicher bin, da der Slave ja die
SQL-Statements mundgerecht serialisiert von einer Quelle. dem Master
bekommt, und nicht parallel von evt. siebenundvierzig verschiedenen
Prozessen. Aber ich kann Dir nicht sagen, wieviel das ausmacht..

> Ich muss vielleicht noch sagen, dass alle Systeme 2 Nic's haben. Das Backup
> mach ich per rsync auf einem Privaten Netzwerk das getrennt ist. Somit ist
> auch der TRaffic getrennt...

Ist schon mal nicht verkehrt;-)

> > Der Nachteil waere, dass Du im Ausfallfall (schoenes Wort;-) vorm
> > Produktionseinsatz des Replica als Master die Indizierung nachholen
> > musst, um dann vernuenftige Performance zu erreichen.
> Hmm, aber das müsste man ja gerade vermeiden können, oder?...
>
> Das Problem was ich sehe ist, dass ich "eigentlich" 2 Master Server habe und
> den Backup. Jetzt, wenn ich den Backup Server zum Master mache, die anderen
> 2 als Slaves, müssen die Daten immer auf den Master geschrieben werden????
> Oder können die auch auf den Slave geschrieben werden und der gleicht dies
> dann mit dem Master ab?...

Nein, wie auch schon andere gesagt haben - der Master schreibt zuerst.
>
> Mir geht es darum, dass ich später auch die Idee zu einem Loadbalancing
> habe. Also 2 Webservers. Nur, ist es ja nicht so schlau, wenn beide Server
> auf die gleiche DB zugreifen, oder?.... und wenn die mal crasht, ist sense.

Wenn beide Webserver auf den gleichen Daten arbeiten, muessen sie auf die
gleiche DB zugreifen. Und die muss auf dem gleichen Server liegen, sonst
hast Du zwei DBs, die Du hinterher noch "mergen" musst. Das klappt fast
nie in "realexistierenden", komplexen Anwendungen und ist sehr
fehlertraechtig. Programmierfehler sind haeufiger als Hardwareausfaelle;-)

So "echte" Hochverfuegbarkeit ist bei gecrashter Master-DB mit MySQL nicht
hinzubekommen. Wenn der Master stirbt, sind bei den Clients die DB-Handles
ungueltig etc. Da hilft eh nur, die Clients mit einem Timeout zu
"bedienen" und dann bei neuen Clients auf den Slave, der erst als Master
restartet werden muss, umzuschwenken.

Eine Strategie, wie man den Master wiederbelebt (mit vorherigem
Aktualisieren etc.) sollte man sich auch schon mal ueberlegen, da das auch
tricky sein kann.

Ein Gewinn ist ein Slave trotzdem, geht einem doch bei einem Sterben des
Masters wenigstens keine Daten verloren. In dem Punkt liegt hier IMHO auch
der Nachteil von Bernds "Sicherheit durch hochverfuegbare Master-Loesung",
da die doch irgendwann mal crashen kann. Es ist doch etwas haesslich, wenn
der zuletzt online eingegangene 3Mio$-Auftrag futsch ist;-)

Aber an dem Punkt wird vielleicht auch deutlich, dass die Wichtigkeit der
Daten bei der Kosten/Nutzen-Beurteilung von Backuploesungen eine Rolle
spielen sollte.

Bei einem von mir mal betreuten Server, der ein aktualisiertes
Fernsehprogramm fuer ein paar Kunden ins Netz stellt, tut das gar nicht so
weh, wenn bei Ausfall die Kopie einen Aktualisierungsstand von vor einer
Stunde hat. Im Grunde juckt das keinen.

Der Grund fuer die Wichtigkeit eines anderen Serverbackups lag daran, dass
hier die ganze HW/SW-Loesung so unsicher war, dass taeglich mit dem Crah
gerechnet werden musste. Hier haette Bernds Ansatz Wunder bewirken
koennen, aber ich bin da, vornehm gesagt, an Kommunikationsschwierigkeiten
mit den Herren mit den $-Zeichen in den Augen und eingeschraenktem
Sichtwinkel gescheitert.

> Warum meinst du "bringts dies überhaupt?"... wie soll ich denn sonst einen
> sicheren SQL Backup haben ?.. Das Problem mit mysqldump ist, dass ich jedes
> Mal die Tables sperren muss..oder sollte um einen sauberen backup zu machen
> was dann die site kurz unbrauchbar macht. Da die datenmenge auch immer
> steigt, wird der backup immer länger...

Das stimmt. Mit "bringts das ueberhaupt?" meinte ich die Umkehr von Master
und Backup. Replication ist schon okay, das hat wirklich Vorteile
gegenueber mysqldump.

> > Hatte von langer Zeit mal irgendwo ein Perl Script gesehn, dass angeblich
> einen Realtime abgleich vom sql macht... könnte dies auch noch was sein
> ?....

Bei MySQl-Replikation schreibt der Master eine Log-Datei mit den
SQL-Kommandos und der Slave spielt die dann nach. Ist also ein "Realtime
Abgleich von SQL".

Es gruesst
Peter

To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 10 Jan 2004 - 13:31:46 CET