Re: SQL Replikation

On Mon, Jan 12, 2004 at 10:36:51AM +1100, Peter Ross wrote:
> On Sun, 11 Jan 2004, Bernd Walter wrote:
> > On Sat, Jan 10, 2004 at 11:31:38PM +1100, Peter Ross wrote:
> > 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).

Natürlich - das ist Aufgabe des Systems, welche die Transaktion
entgegennimmt, dieses sicherzustellen.

> 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.

Natürlich.

> > 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.

Warum nicht?

> 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.

Der Fehler kannn damit nicht behoben sein - ist auch gar nicht die
Aufgabe.
Damit sollen ganz bewusst die Symptome behandelt werden.
Für die Ursache muss schon ein Admin ran, aber der Watchdog kann die
Maschine wesentlich schnell zum Produktionsbetrieb zurückführen, als
es ein Admin könnte.

> 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.

Solche Fehler lassen sich meist in folgende Ursachen einstufen:
IDE, Linux und Drecksapplikationen.
In dem Fall wird der Watchdog nicht helfen, aber es ist schon mal von
Vorteil, wenn er es wenigstens mal versucht 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 das System nicht mehr läuft wirst du auch keine Logs mehr
auswerten können.
IO Deadlocks im Kernel sind nicht unbedingt selten.

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

So einen reset sollte man nicht verhindern wollen.
Das geht schnell nach hinten los und man steht letzlich ohne da.

> > 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.

Wie oben schon erwähnt - der Reset ist kein Fall, den man so lassen
kann - wenn es auftritt ist eine Ursache zu suchen.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message