Re: SQL Replikation

From: Peter Ross <Peter.Ross(at)alumni.tu-berlin.de>
Date: Mon, 12 Jan 2004 10:36:51 +1100 (EST)

On Sun, 11 Jan 2004, Bernd Walter wrote:

> On Sat, Jan 10, 2004 at 11:31:38PM +1100, Peter Ross wrote:
> > 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;-)
>
> Nöh - es muss der Clientanwendung nur klar sein, dass die Transaktion zu
> wiederholen ist.

Wenn eine Transaktion _abgeschlossen_ ist, haette ich sie gern in den
Buechern (dafuer sind Transaktionen ja schliesslich da).

Da hilft ein Slave wesentlich, da er die Transaktion mit nur geringer
Verzoegerung im Sekundenbereich in seine Datenbank uebernimmt.

Crasht jetzt der Master, ist der Auftrag im Slave dokumentiert.

> Aus Sicht des Servers ist dabei eigendlich nur wichtig, dass der
> möglichst schnell wieder auf die Füße kommt wenn es doch mal zu einem
> Ausfall kommt.

Das ist ein anderer, sicherlich auch wichtiger Aspakt.

> Extrem wichtige Maschinen rüste ich mit Watchdog Timern aus.
> Auf dem System läuft dann eine Software, die den Service prüft und bei
> Erfolg den Timer bedient.
> Wenn auch nur irgendwas in der Kette klemmt iwrd das System resetet.

Ich gebe zu, mit dem "reset" so meine Probleme zu haben, ich mache es
ungern automatisch.

Es kann sein (und ist schon passiert), dass der Fehler damit nicht behoben
ist, d.h. das Klemmen sofort wieder auftritt und man in eine
Endlos-Reset-Schleife kommt.

Beispiele sind korrupte Filesysteme oder Datenbanken. Sowie Probleme aus
dem Bereich "gibt's doch gar nicht", von denen man vorm Auftreten nicht
mal getraeumt hat.

"Billigloesung" ist ja zunaechst einmal eine Auswerten eines Logs, um
beispielsweise ein zweites Reset nach drei Minuten zu verhindern und
stattdessen ein SOS zu senden.

Wenn Du aus dem Bereich ein paar Tricks hast, waere ich schon neugierig.

> Der Punkt ist mehr, dass es sehr einfach ist eine extrem hohe Ver-
> fügbarkeit mit einer Einzelmaschine zu ereichen,

Ganz klar - ja, die von mir bevorzugte Methode. Wenn eine Maschine, die
fuenf Jahre duchlaeuft, dann irgendwann SOS blinkt, ist das wesentlich
besser als irgendein automatischer Failover oder Reset alle drei Tage.

> während eine zweite
> Maschine bei weitem nicht mehr einfach ist und umso schwieriger ist es
> mit einer zweiten die Verfügbarkeit zu erhöhen und nicht zu reduzieren.
> Man sollte sich bei der Entscheidung zu einer Maschine nicht durch
> den Spieltrieb verleiten lassen - geht zumeist nach hinten los.

Ja. Bei zunehmender Komplexitaet verlagert sich die haeufigere
Fehlerursache auch eher in den Tastaturbereich;-)

> So kann man für einen Webshop z.B. Problemlos die Produktdaten
> replizieren und eine Bestellung oder Lagerabgleich kann dann auf einem
> Einzelserver mit weitaus weniger Grundlast erfolgen.

ACK.

Setzt auch ein wenig Verstaendnis der DB-Programmierer voraus.

Gruss
Peter

To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 12 Jan 2004 - 00:37:17 CET

search this site