Datenbank Verbindungsabbruch - Prinzipfrage

[Dejan Vu]

Falls der Event bei einem TCP-Verbindungsabbruch gefeuert wird, bringt er wirklich nichts. Das Problem ist meistens, das die Verbindung nicht abgebrochen wurde, aber trotzdem nichts durch komme. Daher heartbeat, Keep alive etc.

A sendet alle X Sekunden ein 'Hallo' and B. B antwortet sofort mit 'Huhu'.
A wartet nach dem eigenen 'Hallo' maximal X Sekunden bis zum Huhu. Kommt es nicht, wird die Verbindung geschlossen.
Wenn B nicht alle X*f (f>1, z.B. 1.2) Sekunden ein "Hallo" bekommt, wird die Verbindung geschlossen.

Der Client (einer von beiden ist ja logischerweise der Client) baut die Verbindung dann wieder auf.

B muss nur 'X' kennen, also quasi den Timeout.

Bei einer SQL-Connection nehmen wir auch ein 'SELECT 1' oder den timestamp, wie Holger erwähnt hat und kicken die Verbindung bei einem Timeout. D.h. wir haben eine ständig aktive Connection.

[HolgerX]

Hmm..

Bei einigen unserer Kunden gibt es auch (jede Nacht) einen ConnectionLost...

Dies hat aber damit zu tun, das diese Kunden partu den SQL-Server in eine VM installiert haben und meinen pünktlich um 23:00 Uhr einen SnapShot von der VM ziehen zu müssen.

Dies führt beim Aushängen des SnapShots zur Sicherung zu einem kompletten NetzwerkCut, der zwischen Sekunden bis hin zu Minuten dauert.

Somit muss unserer (alte) Applikation jeden morgen neu gestartet werden, da die Connection in der Nacht gekickt wurde.

Dumm nur, das die mitunter 24h / 7 Tage die Woche arbeiten.. ;)

(Dieses Problem ist übrigens ein bei VMWare bekanntes Problem, wobei es angeblich gelöst sein soll ;) )

[IBExpert]

Zitat:

Zitat von HolgerX (Beitrag 1325158)

Dies hat aber damit zu tun, das diese Kunden partu den SQL-Server in eine VM installiert haben und meinen pünktlich um 23:00 Uhr einen SnapShot von der VM ziehen zu müssen.

Diese VM Fetischisten kenne ich auch. Ist immer lustig denen mal zu erklären, das deren sogenannte Sicherungsstrategie eher gefährlich ist als hilfreich. Der VM Snapshot hat eine ähnliche Funktion bei Firebird wie Forced writes zu deaktivieren. Das was gerade im Speicher ist und auf der Platte geändert wurde wird gesichert. Ob das zur careful write schreibreihenfolge von Firebird passt ist egal. Wenn nun beim Snapshot irgendwas schief läuft (und ja, auch das ist nur software, die ggf mal auf volle oder defekte Platten trifft und dann nicht weitermachen kann), ist es gar nicht mal so unwahrscheinlich, das die gesicherte VM nicht 100% sauber ist.

Wenn das die einzige Strategie ist, dann herzlichen Glückwunsch wenn es knallt. Wir bekommen ja aus verschiedenen Umgebungen Firebird Datenbanken zur Reparatur, vor kurzem war ein dabei, bei der die ersten ca 60% der Datei auch sauber gefüllt war, der Rest waren leider binäre Nullen. Leider zeigten diverse Pointer in diesen Bereich, unter anderem Teile der Transaktionsinventory Page. Nach kurzer Analyse war klar: Keine Reparatur möglich (Wenn bei einem Auto der Motor ausgebaut ist, kann die Werkstatt mit der Meldung, das Auto springt nicht an, auch nicht umgehend das Problem beheben, aber immerhin schnell ein Ergebnis melden).

Irgendwie haben die meisten Admins im Umfeld von Virtualisierung schon religiösen Charakter, wer dann Jehova sagt (oder VM sind nicht immer die optimale Lösung), wird gesteinigt. Gerade Firebird Server selbst zu sichern ist ziemlicher mumpitz, neben den Datenbanken ändert sich da hoffentlich fast nie was, wenn die dedicated sind. Warum also jeden Tag sichern? Die Datenbanken sollten eher noch öfter gesichert werden, ob stündlich durch Shadows oder in Realtime per Replikation, da steckt die Arbeit am Ende drin.

Kleiner Tip: Einfach mal in einem unscheinbaren Bereich der Datenbankdatei mit einem Hex Editor die DB bewusst beschädigen und dann abwarten, ob der Kunde mit seiner Strategie das merkt oder tagelang eine kaputte DB absichert, die unbrauchbar ist. Solche Diskussionen wecken viele Schlaumeier oder zumindest deren Vorgesetzte oft auf.

[hstreicher]

@HolgerX
wir verwenden Shadowprotect mit VMWare und ziehen stündlich incrementelle Snapshots auch vom DB Server und haben keine Verbindungsabbrüche

[Sir Rufo]

Zitat:

Zitat von hstreicher (Beitrag 1325214)

@HolgerX
wir verwenden Shadowprotect mit VMWare und ziehen stündlich incrementelle Snapshots auch vom DB Server und haben keine Verbindungsabbrüche

Es kommt wohl auch darauf an, was man von VMware da einsetzt. Es gibt da durchaus mehr als nur VMware Player oder VMware Workstation und die sind nicht einfach nur teurer :)

[mkinzler]

Wenn aber Virtualisierung richtig eingesetzt werden soll, kommt man aus meiner Sicht nicht um bare metal Lösungen wie VMWare esx(i) o.ä. herum.

[HolgerX]

Auf die beim Kunden eingesetzte VMWare haben wir keinen Einfluss..

Sollte aber ESX sein, da es sich um eine Cluster-Farm für mehrere Standorte handelt..

Ob diese Shadowprotect einsetzen kann ich nicht sagen, nur das dies ach andere VM-Server im Haus betraf (mit anderer Software) und bereits bei VMWare eskaliert und bekannt war (~ 08/2015) und diese an der einer Lösung suchten und für 09/2015 zugesagt hatten.

Leider habe ich keine Rückmeldung seitens des Kunden bekommen.

Ich bin auch kein VM Spezialist.. ;)