Registerkarten

SimtippViewerServerKunstLL-BlogVideosVehikelAnleitungSansarARC

Mittwoch, 8. November 2017

[LL Blog] - Über den Ausfall: Ein typisches Montagsereignis

Quelle: SL Brand Center
Linden Lab am 08.11.2017 um 9:19 AM PST
(18:19 Uhr MEZ)
- Blogübersetzung -

Als Folge einer geplanten Code-Bereitstellung, waren die Dinge ein wenig holprig für die Nutzer, die sich am Montagmorgen in Second Life einloggen wollten (Montagnachmittag bei uns). Ich möchte euch mitteilen, was passiert ist und was wir tun werden, um dies in Zukunft zu verhindern.

An diesem Morgen habe ich versucht, eine Datenbankänderung für einen internen Dienst durchzuführen. Ohne zu sehr ins Detail zu gehen, bestand die Implementierung darin, eine vorhandene Datenbanktabelle zu ändern, um eine zusätzliche Spalte hinzuzufügen. Diese Änderungen wurden vorher mehrfach überprüft, sie hatten die entsprechenden QA-Tests in unseren Entwicklungs- und Bereitstellungsumgebungen bestanden und alle Kriterien für eine Implementierung in das Produktivsystem waren erfüllt. Obwohl dieser Dienst den Endbenutzern nicht direkt zur Verfügung steht, wird er als Teil des Anmeldevorgangs verwendet und ist so konzipiert, dass er auch im Fehlerfall funktioniert. Das bedeutet, wenn der Dienst nicht verfügbar ist, sollten sich die Benutzer dennoch ohne Probleme in Second Life anmelden können.

Während der Datenbankänderung wurde die zu ändernde Tabelle gesperrt, um Zugriffe zu verhindern, während sie angepasst wurde. Diese Tabelle hatte eine Größe von fast einer Milliarde Zeilen und die Änderung dauerte deutlich länger als erwartet. Darüber hinaus funktionierte der Dienst aufgrund der Sperrung nicht so wie es geplant war. Und das führte dazu, dass Anmeldungen in Second Life fehlschlugen, zusammen mit einer Handvoll anderer Zusatzdienste. Unsere Untersuchung wurde durch weitere Probleme erschwert, die am Montag aufgrund eines Konfigurationsfehlers bei einem der großen Internet Dienstanbieter in Nordamerika zu sehen waren. Viele von uns arbeiteten aus der Ferne (über Remote) und obwohl wir die Probleme frühzeitig bemerkten, war uns nicht sofort klar, dass es sich um interne Fehler handelte und nicht um die Fehler eines Drittanbieter Dienstes. Nach einigen Nachforschungen wurde die Sperre für die Datenbank aufgehoben und die Dienste begannen sich langsam zu erholen. Wir mussten einige zusätzliche Arbeit leisten, um den Anmeldedienst wiederherzustellen, da die Anmeldeserver der nächsten Generation (wie hier im April beschrieben) noch nicht vollständig bereitgestellt wurden.

Ich versuche immer noch, diese Datenbankänderung in naher Zukunft abzuschließen, aber dieses Mal werden wir eine andere Methode anwenden, die keine Sperrung der Datenbanktabellen erfordert, so dass kein ähnliches Problem verursacht werden kann. Wir untersuchen auch genau, warum der Service im Fehlerfall nicht funktionierte, so wie er entworfen wurde. Und wie wir verhindern können, dass dies noch einmal in der Zukunft passiert.

Steven Linden

Quelle: About That Outage: A Case of the Mondays

Keine Kommentare:

Kommentar veröffentlichen