Einen kleinen Nachteil hat das Shadow allerdings doch : wenn ich mich nicht irre, dann geht das nur mit einem Rechner, das darf also kein Netzlaufwerk sein. Externe Festplatte mit USB 3.0 dürfte dann wohl das beste sein. Oder ist das vielleicht seit
FB 2.5 anders ?
ja, das geht bei aktuellen
FB Versionen mit Windows nur auf einer lokalen physikalischen Platte, da aber egal ob an SATA, SCSI, USB o.ä. Über ein Netzwekkabel würde ich das aber auch nicht unbedingt machen (geht bei Linux schon länger, ich meinte auch was zu fb25 oder fb3 gelesen zuhaben, das das dann ggf auch unter windows via netzwerk geht, bin mir da aber nicht sicher).
Mit ist aber e-Sata sympatischer, weil schon länger verfügbar und auch heute schon 08/15 Technik, trotzdem fast genauso schnell wie USB3. Ein E-SATA Leergehäuse kostet keine 30 Euro, ein Controller mit externem Anschluß oder Kabel zum internen auch nicht mehr, 08/15 s-sata platte rein (lieber klein und schnell als groß und lahm) und schon hat man eine recht gute absicherung, auch wenn die eigene
DB auf der internen Platte ohne
RAM Disk läuft. So kann man auch mal ein Worst case Szenario durchspielen, nämlich zum Beispiel Mainboardausfall auf dem Server.
Wie lange braucht man um unter der gleichen
IP wieder eine Kiste am laufen zu haben mit dem letzten Stand der
DB?
Das kann bei Backup-Restore und vorher auf band suchen wo was zum restoren hat, ganz schön lange dauern, je nach Datenbankgröße auch mal diverse Stunden. Das wir das bei Kunden auch via Replikation live machen ist eine andere Baustelle, erspart viel Heckmeck bei Mission Critical Anwendungen, die mal nicht eben eine Stunde stehen können.
Replikation ist nicht im Lieferumfang von
FB, lässt sich aber mit vergleichsweise wenig Aufwand mit internen Objekten realisieren, wenn das
DB Modell den prinzipiell dafür geeignet ist. Das bekommt man aber als OneWay Replikation eigentlich immer hin (Master Slave Replikation). Wenn das
DB Modell passt ist aber auch eine Multimaster Replikation im Online/Offline Betrieb realisierbar, haben wir mehrfach für Kunden gemacht. Das eignet sich das nicht nur als Ausfallsicherheit, sondern auch für Skalierbarkeit.
Beim Betrieb einer
DB via Netzwerk erhöht sich die Wahrscheinlichkeit von Schreibfehlern erheblich. Wenn die internen Platten nicht reichen, dann würde ich schon eher ein SAN anschliessen und fertig. Da kann im fehlerfall auch gleich ein anderer Server auf das gleich Volume ohne hin und her kopieren. So was kann leider ziemlich teuer sein, bringt aber teilweise irre Performance (setzt ein Kunde in einer süddeutschen Uniklinik mit fb21 ein, lesen und schreiben ging mit je ca. 1GB pro Sekunde, das war schon ein Feeling wie in der RAMdisk, aber im Vergleich dazu wesentlich sicherer, weil weiß ich wie oft intern gespiegelt. Soweit ich gehört hatte, war das wohl aber auch preislich irgendwo im Breich mit 6 Stellen vor dem Komma nicht für jeden geeignet. Das SAN verhält sich intern aber wie eine physikalische Platte, hat daher weder mit
DB noch mit Shadow Probleme.
Beim Netzwerk hast du auch schnell mal den Draht voll, weil das Kabel im Gegensatz zu SATA von allen Netzwerkclients gemeinsam benutzt wird, um da auch nur annähernd auf SATA Speed zu kommen (300MB pro sekunde theoretisch, mit schnellen Platten bzw SSD auch problemlos zu 50-75% erreichbar). Das muß schon ein dicker Draht sein, Gigabit reicht da nicht annähernd aus. Daher arbeiten SAN Systeme meistens auch mit eigenen Protokollen und eigener Hardware.
Ich stimme aber Hansa zu, ich würde bei einer SSD als einzigem physikalischen Datenräger für das Shadow der Ramdisk
DB auch nicht so wirklich ruhig schlafen, gebranntes Kind scheut das Feuer. Ein Crash kann zwar auch mit einer normalen Festplatte passieren, aber in den letzten 5 Jahren hatte ich bisher nur mit SSD unvorhersehbare Totalausfälle, HDDs haben sich da immer irgendwie zickig gezeigt, seltsame Geräusche von sich gegeben oder waren ruckelig, so das man noch mal eben den Kram zumindest noch ein mal absichern konnte. Auch die SMART Infos sollte man nicht ignorieren.
Auf der SSD jedoch war in beiden Fällen gar nichts mehr, das hat in einem Fall auch der SSD Hersteller untersucht, weil der sich nicht erklären konnte, wie die SMART Daten der SSD aus meinem letzten Test vor dem Crash zustande kamen. Der Hersteller hat auf jeden Fall von deutlicher Überlastung gesprochen, außerhalb der Spezifikation liegende zu hohe Frequenz von Schreibvorgängen. Die SSD war auch eine MLC, evtl. hätte eine SLC das überlebt, aber mit Produktivdaten werde ich das nicht ausprobieren ohne Plan B. Und ohne produktiv entstandene Schreiblast über mehrere Monate bekommt man kein wirklich relevantes Ergebnis, Benchmark hin oder her.