Maya wird morgens um 4:30 durch ihr Mobiltelefon geweckt. Sie erhält eine Textnachricht nach der anderen, jede Minute eine Neue. Zum Schluss ruft John sie an. John ist ganz ausser sich, aber Maya versteht nicht ganz was John sagen will. Trotz aller Anstrengung hat sie Mühe zu verstehen was John ihr sagen will, und das mitten in der Nacht. Plötzlich erinnert sie sich: John hat einen Onlineshop für Sportgeräte auf einem ihrer Server installiert, and er ist wütend wieso der Server nicht mehr erreichbar ist und seine Kunden in Neuseeland sind wütend weil sie nicht auf seinen Onlineshop zugreiffen können.
Dieses Szenario ist typisch, und wahrscheinlich hast du schon mehrere Variationen davon gesehen, sei es in der Rolle von Maya, John oder beiden. Falls du in der Rolle von Maya bist willst du in der nacht schlafen. Falls du dich in der Rolle von John wiederfindest dann willst du dass deine Kunden bei dir bestellen köennen wann und wo sie sind.
Das Problem bleibt bestehen: Computer fallen aus, und dies auf unterschiedliche Varianten. Probleme mit der Hardware, Stromausfall, Fehler im Betriebssystem oder in der Software, etc. Nur CouchDB hat keine Fehler. (Naja, das stimmt so natrlich nicht. Jede Software hat Fehler mit der wahrscheinlichen Ausnahme von Dingen welche von Daniel J. Bernstein and Donald Knuth geschrieben wurden.)
Normalerweise willst du soweit möglich die Garantie bieten dass jene Dienste die du bereitstellst (in Mayas und Johns Fall die Datenbank für den Onlineshop) zuverlässig und robust laufen. Der Weg zur Zuverlässigkeit und Robustheit ist das entfernen des sogenannten "Single Point of Failure" (frei Übersetzt: der eine zentral wichtige, fehleranfällige Punkt). Ein Netzteil kann ausfallen. Um den Server dennoch in Betrieb zu halten werden sie meist mit zwei Netzteilen ausgeliefert. Um die Zuverlässigkeit weiter zu erhöhen könntest einen Server kaufen in dem alles dupliziert ist. Dies wäre aber ein ziemlich spezieller - und teurer - Server. Es ist viel billiger wenn du zwei ähnliche Server zu haben bei welchem der eine den anderen bei einem Problem ersetzen kann. Dennoch musst du sicherstellen das beide Server dieselben Daten haben damit sie einander Ersetzen können ohne dass es jemand bemerkt.
Nach dem Ausmerzen aller zentral verwundbaren Punkten (single point of failure) bekommst du ein hoch verfügbares und fehlertollerantes System. Die Toleranz des Systemes wird nur von deinen finanziellen Möglichkeiten beschränkt. Wenn du es dir nicht leisten kannst dass ein Kunde seine Einkaufliste bei einem Fehlereintritt verliert, musst du sicherstellen dass die Daten mindestens auf zwei Servern an mindestens zwei unterschiedlichen geographischen Orten gespeichert werden.
Amazon macht dies for die Amazon.com website. Wenn ein Datenzenter Opfer eines Erdbebens würde könnten die Benutzer dennoch einkaufen.
Es ist ähnlich, obwohl Amazons Probleme nicht deine Probleme sind und du einen Berg weiterer Probleme hättest wenn dein Datenzenter plötzlich nicht mehr ereichbar währe. Aber dennoch, du willst sicherstellen dass du trotz eines Serverfehlers deine Dienste anbieten kannst.
Bevor wir in die Tiefe des Einrichten eines hoch verfügbahren CouchDB Systems gehen, lass uns eine andere Situation noch anschauen. John ruft Maya während der normalen Büroöffnungszeiten an und leitet dir die Meldung weiter dass seine Kunden sich über die langen Ladezeiten des Onlineshops beschweren. Maya wirft einen kleinen Blick auf den Server und folgert dass Johns Problem ein "Glücksproblem" sei, was wiederum John verwirrt. Maya erklährt ihm dass es plötzlich viel mehr aktive Benutzer auf dem System gäbe welche bei John einkaufen wollen. Darauf klingeln bei John die Glocken: "Ich habe einen sehr gute Bewertung in einem Blog erhalten. Die neuen Benutzer kämen währscheinlich via diesen Blogbeitrag.". Nach einer kurzen Überprüfung bewahrheitet sich diese Vermutung. Auf diesem Blogbeitrag gibt es auch schon viele Kommentare von unzufriedenen Neukunden dass der Shop sehr träge sei. John möchte die Neukunden nicht verärgern und fragt Maya was man machen könne. Maya schlägt vor einen zusätzlichen Server bereitzustellen welcher die Last zur Hälfte übernehmen kann. Dies ermögliche eine akzeptable Antwortzeit. John ist damit einverstanden und Maya beginnt den neuen Server aufzusetzen.
Die Lösung für dieses beschriebene Problem ist ähnlich dem Vorhergehenden zu einem fehlertoleranten System: Einen neuen Server bereitstellen und alle Daten synchronisieren. Der Unterschied zur Fehlertoleranz ist dass der zweite Server nicht nur "Stand-By" ist und auf einen Fehler wartet, sondern die Hälfte der Last übernimmt wenn eine Überlast der Anfragen ansteht. Dieser Fall ist nicht Fehlertollerant: Wenn einer der Server abstürzt wird der andere alle Anfragen erhalten und wird möglicherweise in die Knie gezwungen, oder wird zumindest einen sehr lange Antwortzeit benötigen. Weder das eine noch das andere ist akzeptabel.
Merke dass - obwohl beide Lösungen ähnlich aussehn - hohe Verfügbarkeit und Fehlertoleranz nicht dasselbe sind. Wir werden zu einem zweiten Szenario später kommen aber zuerst lass uns anschauen wie man ein fehlertolerantens CouchDB System einrichtet.
Wir haben es im vorhergehenden Kapitel schon vorweggenommen: Die Lösung der Synchronisation ist die Replikation.