DB-Server Down => Fallback

[hotti]

Moin;

wie weit geht Ihr denn so in einem solchen Fall, wo Web-Inhalte aus der Datenbank geholt werden und der Datenbankserver ist mal down?

Stellt Ihr die Inhalte dann aus irgendwelchen anderen Quellen (Dateien) zur Verfügung oder zeigt Ihr eine schöne Seite wo steht, dass im Moment kein Zugriff möglich ist?

Die Frage ist ja auch die der doppelten Datenhaltung für den Fall, dass ein vollwertiger Ersatz zur Verfügung stehen sollte. Und die Frage ist auch die, was in einem solchen Fall den bots angeboten werden kann, damit die ihren Index nicht gleich wegschmeißen, wenn die ausgerechnet dann die Seiten spidern, wenn der DB-Server hops ist?

Also: Wie macht Ihr das?

Hotte

[Struppi]

Stellt Ihr die Inhalte dann aus irgendwelchen anderen Quellen (Dateien) zur Verfügung oder zeigt Ihr eine schöne Seite wo steht, dass im Moment kein Zugriff möglich ist?

Jein, Seite ja, schön nein.

Struppi.

[hotti]

»» Stellt Ihr die Inhalte dann aus irgendwelchen anderen Quellen (Dateien) zur Verfügung oder zeigt Ihr eine schöne Seite wo steht, dass im Moment kein Zugriff möglich ist?

Jein, Seite ja, schön nein.

Ja Struppi, so eine Seite kann _keine schöne_ Seite sein. Bei mir ist es mittlerweile ein Cgi geworden weil ich da evntl. noch was Serverseitiges einbaue...

Viele Grüße,
Horst

[Alexander (HH)]

Moin Moin!

wie weit geht Ihr denn so in einem solchen Fall, wo Web-Inhalte aus der Datenbank geholt werden und der Datenbankserver ist mal down?

500 oder 404 bei ungeplanter Downtime, lange Vorankündigung und Down-Seite bei geplanter Downtime.

Wenn es Dir nur um Ausfallsicherheit geht, mache Deine Systeme redundant. Da kann man sehr schöne Konstrukte bauen, mit redundant angebundenen Webservern hinter redundanten Loadbalancern, die auf redundante Application-Server hinter redundanten Loadbalancern zugreifen, die dann wiederum auf redundante Datenbanken hinter redundanten Loadbalancern zugreifen. Dazu gehören dann eigentlich noch jeweils redundante Firewalls zwischen Internet und Webservern, Webservern und Application-Servern, Application-Servern und Datenbanken.

Wenn man sowas mal aufgesetzt und zum Laufen gebracht hat, ist das echt cool. Man kann beliebige Komponenten komplett rausreißen, ohne dass die Funktion beeinträchtigt wird. Der Haken an der Sache ist, dass so eine Installation nicht für ein paar Hundert Euros zu haben ist und alle Beteiligten genau wissen müssen, was sie machen. Es darf keinen Single Point of Failure geben, alles muß redundant ausgeführt werden, auch die Loadbalancer. Kleinigkeiten wie die Stomversorgung natürlich auch.

Bei einem meiner Ex-Arbeitgeber hat irgendein geistiger Tiefflieger ohne Absprache in einer der Firewalls einen Content-Filter aktiviert, der nur in eine Richtung funktioniert hat. Ergebnis: PPTs mit Bildern konnte man zwar hochladen, aber nicht wieder runterladen. Und weil die FW-Software reichlich dämlich war, gab es keine Fehlermeldung, keinen Verbindungsabbruch, der Browser rannte einfach in einen Timeout. Den Quatsch zu finden hat TAGE gedauert.

Alexander

[hotti]

Moin Moin!

Wenn es Dir nur um Ausfallsicherheit geht, mache Deine Systeme redundant.

Um Gotteswillen ;-)

Es ist ja nur meine kleine WebSite. Also ich hab mir übers WE, nunmehr nachdem ich letzte Woche den ganzen Content-Kram auf MySQL umgestellt habe, nen riesen Kopf gemacht, ob ich für den Fall des Ausfalls des DB-Servers, und nur für diesen Fall was mache. Wenn der Webserver weg ist, geht sowieso nix mehr. Aber der DB Server war auch schonmal weg, wo der Webserver noch lebte.

Und gestern nachmittag baute ich tatsächlich einen fallback-Mechanismus für diesen Fall, womit der Content aus Dateiebene geladen wird. Nachdem ich das alles letzte Nacht überschlafen hatte, kam mir heute auf dem Weg in die Firma der entscheidende Gedanke in den Kopf: Alles nur halbsowild. Wozu den Aufwand mit doppelter (redundanter) Datenhaltung auf dem Server?

Und so dachte ich mir, dass beim Ausfall des DB-Servers nicht irgendeine schnöde Fehlermeldung (ja, solche Seiten hab ich oft genug gesehen, auch mit 500er und so) in den Browser kommt, sondern eine einheitliche Seite worin ich darum bitte, es später nochmal zu versuchen und für Bots den HTTP-Status wenigstens auf 302 zu bringen.

Bleibt evntl. noch die Frage, wie Bots mit dem Status 302 umgehen, dazu habe ich bisher nur wenig Informationen gefunden.

High available Zeugs ist freilich auch ein interessantes Betätigungsfeld, neben der Administration von SMTP-Gateways, Proxy-, Web- und Nameservern hatte ich eine Zeitlang beruflich damit zu schaffen. Meine private WebSite ist so wichtig nun auch wieder nicht ;-)

Vielen Dank für Deine Aufmerksamkeit Alexander,
Hotte