Sie befinden sich hier:

    DATUM UHRZEIT FEHLER URSACHE
    2020
    26.02.2020 06:00-07:30 ca. 1.5 Std. nicht erreichbar. Serverstörung bei KDB, ZLO und DLDB von 06:00 bis 07:30 Uhr
    07.01. - 08.01.2020 14:00-10:00 ca. 20 Std. nicht erreichbar. Eine sehr hohe Anfrage-Flut an Kursangeboten von DRK Webseiten haben 1. Datenbank sehr belastet und verlangsamten das System ca. 20 Std. lang. Der Fehler wurde behoben.
    2019
    10.12.2019 11:30-13:00 1.5 Std. nicht erreichbar. Eine Indizierungsfehler erhöhte die Abfragezeit der Buchungen und verlangsamte das System. Der Fehler wurde behoben.
    27.11.2019 13:45-13:50 5 Minuten nicht erreichbar. Die Partition des Binär-Log vom 1. Datenbankserver war voll (200GB). Das Binär-Log enthält die zu synchronisierenden Daten für den 2. Datenbankserver. Es wurden noch mal 100GB hinzugegeben, so dass etwas mehr Luft nach oben ist... bis zum Umzug der auf die neuen Server.
    18.11.2019 10:45-10:55 10 Minuten nicht erreichbar. Eine hohe Systemauslastung hat den Ausfall verursacht. Nach dem Neustart ist der Fehler behoben.
    25.10.2019 10:33-10:38 5 Minuten nicht erreichbar. Eine querliegende Datenbankabfrage war die Ursache für den Ausfall. Nach dem Neustart ist der Fehler behoben.
    01.10.2019 11:15-11:26 11 Minuten nicht erreichbar. Es wurden Teile der VM (Virtuelle Maschine) umgezogen, dabei kam es zu einem Aussetzer.
    13.09.2019 10:31-10:41 10 Minuten nicht erreichbar. Hohe Last auf drk002/apache, drk003/apache & drk01/mysql waren die war die Ursache für den Ausfall. Nach dem Neustart ist der Fehler behoben.
    20.06.2019 13:10-14:20 70 Minuten nicht erreichbar. Der Rootserver ist abgestürzt, musste neu gestartet werden. Grund ist unbekannt. Nach dem Neustart ist der Fehler behoben.
    22.05.2019 09:40-09:51 / 11:30-11:50 Uhr 11 und 20 Minuten nicht erreichbar. Der Apache Webserver musste neu gestartet werden. Der Grund liegt in der Umstellung unserer Webserver auf die neueste "stable version" von PHP 7.0.33 und in manchen Teilen auch auf PHP 7.3. Da nicht alle Teile gleichzeitig aktualisiert werden können, kann es zu vorübergehenden Disparitäten kommen.
    16.01.2019 12:47-13:15 Uhr 28 Minuten nicht erreichbar. Kurze DRK-intern.de Störung 12.47 Uhr bis 13.15 Uhr. Ursache ist ein alter Webservice, der die Datenbank blockiert hat und nun in Kürze abgeschaltet wird.
    2018
    14.09.2018 08:15-08:48 Uhr KTV-Standalone: Webservice von KTV Standalone-Version war 33 Minuten nicht erreichbar. Aufgrund des Webservice Aktualisierung gab es bei der KTV Standalone Version, nicht bei der Vollversion, von 8.15 bis 8.48 Uhr Anmeldeprobleme. Die Störung ist inzwischen behoben.
    31.08.2018 14:54-15:09 Uhr Routerausfall von 15 Minuten bei Hetzner Routerausfall von 15 Minuten beim Internetprovider Bamsenet 14.54 bis 15.09 Uhr - Störung ist behoben.
    01.07.2018 13:09-15:05 Uhr Syntaxfehler im Anmeldung-Webservices Aufgrund eines Syntaxfehlers im Anmeldung-Webservices gab es von 13:09 bis 15:05 Uhr eine Störung, die inzwischen behoben wurde.
    24.05.2018 11:20-11:21 Uhr Nach Minuten-Störung sind die Datenbanken wieder erreichbar Für einzelne Minuten waren unsere Server um 11.20 Uhr nicht erreichbar. Offensichtlich bereiten die Wassermassen in Süddeutschland auch unserem Webhoster Fa. Hetzner Probleme.
    2017
    Gesamtergebnis 2017 max. 525.600 Minuten Erreichbarkeit, Summe der Störungen: 188 Minuten.
    Das entspricht einer Erreichbarkeit von 99,9 Prozent (genau: 99,99964 Prozent).
    23.11.2017 13:30-14:53 Uhr Aufgrund einer Serverstörung gab es Anmeldeprobleme Aufgrund einer Serverstörung gab es Anmeldeprobleme: Fa. Hetzner meldete, die Routerstörung sei behoben, fsn1-dc12-ex9k2 "Typ: Störungsmeldung Kategorien: Netzwerk Start: 23. November 2017 13:30:00 CET Ende: 14:53 Uhr Beschreibung: Derzeit liegt eine Störung am Router fsn1-dc12-ex9k2 vor. Unsere Techniker arbeiten mit Hochdruck an der Ursachenanalyse und der Behebung des Problems. Bitte haben Sie etwas Geduld. Sobald neue Informationen vorliegen, werden wir Sie auf dieser Website informieren. Bitte entschuldigen Sie die Unannehmlichkeiten. Vielen Dank für Ihr Verständnis. Fa. Hetzner"
    21.09.2017 11:00-11:30 Uhr DRK-Intern.de ist nicht erreichbar Aktualisierung des DRK-Templates auf DRK-Intern, Master und Musterseiten, welche eine Anpassung von Herrn Strobach beinhaltete.
    02.06.2017 14:30-15:45 Uhr Nach 75 Minuten-Störung sind die Datenbanken wieder erreichbar Die automatische Löschung alter Interessentendaten hat eine kurze Störung ausgelöst. Die anderen Datenbanken warteten auf die Erledigung dieser Aufgaben und verzögerten die Antwort. Dies ist die erste Störung in 2017.
    2016
    08.12.2016 10:12-10:30 Uhr Wissensbörse nicht erreichbar Kurze Nichterreichbarkeit der Wissensbörse, Ursache: Beim Erneuern eines SSL-Zertifikates war dieses defekt. Nachdem ein neues Zertifikat angefordert und installiert war, lief alles problemlos.
    08.12.2016 6:12-08:30 Uhr Kundendatenbank nicht erreichbar Überstarke Auslastung der vier CPUs durch komplexen Rechenabgleich einer Vielzahl von Tabellen. Datenauslagerung auf Festplatte fand statt, das Temporärverzeichnis war jedoch überfordert. Gegenmaßnahmen, kurzfristig:
    - Mysql-Temp-Verzeichnis nach /var/tmp verlegt (84/197 GB = 45% belegt)
    Gegenmaßnahmen, auf längere Sicht:
    Auslösender Prozess wird wie Suche mit Hilfe von Elastic Search ausgelagert, so dass die vier CPUs nicht belastet werden.
    16.09.2016 05-10:30 Uhr Kundendatenbank nicht erreichbar Hallo zusammen, bei der Server-VM wurde heute Nacht der Festplattenplatz verdoppelt. Diese Aktion hat sie wohl etwas durcheinander gebracht. Es wurden zuviele Hintergrunddienste wie Statuseintrag-Update, elastic search zur Indizierung bei Suchanfragen, usw. erneut und erneut gestartet, zudem kamen am Morgen viele aufwändige Anfragen von den KDB-Mandanten herein. Dadurch war der Arbeitsspeicher komplett ausgebucht, die aktuellen Anfragen wurden nicht mehr bearbeitet. Datenbanken mit ZLO, DLDB, Webservice und BVw waren davon nicht betroffen. Gegenmaßnahmen:
    1. Mehrfachstart von Hintergrunddiensten ist künftig nicht mehr möglich.
    2. Anzahl der Konnektoren (zeitgleiche Datenbankanfragen mit Rechenkapazitäten) wurde von 400 auf 600 hochgesetzt.
    3. Technischer Dienstleister erhält künftig Warnmeldung auf Handy, wenn Kapazitäten wie Arbeitsspeicher bei hohem Auslastungsniveau knapp werden.
    4. In den nächsten Monaten testen wir das schnelle Umschalten auf das Ersatzsystem im Bedarfsfall (Hierzu muss leider die Ursache der Störung bekannt sein, da andernfalls auch das Ersatzsystem durch die gleiche nicht-behobene Ursache in die Knie gehen kann).
    06.04.2016 12-13:30 Uhr Mailversand Postfach leer Dovecot neu gestartet. Die Prüfung auf dem Server ergab, das die Mails ins Postfach des Info-Benutzers einsortiert wurden und dort im Bereich INBOX/new = ungelesen liegen (Zeitraum 07.03.-06.04., aktuell 781 Mails, Tendenz steigend), d.h. Inxmail liest das Postfach nicht mehr aus. Auch ein Neustart von Inxmail scheint das Problem nicht zu lösen, die Mails bleiben weiterhin ungelesen. Inxmail-Logs kontrolliert: POP3: Connection timeout POP3? -> Dovecot neu gestartet, nach einigen Minute waren die ungelesenen Mails verschwunden, System läuft wieder normal. -- Mit freundlichen Grüßen (Rico Körner)
    22.03.2016 07:30-10:15 Uhr Login zu den DRK-internen Datenbanken nicht möglich Unmittelbarer Auslöser war Logrotate, ein Prozess, der Logfiles rotiert und alte Logs löscht. Dieser ist heute Morgen beim Rotieren der MySQL-Logfiles hängen geblieben, weil die entsprechende Partition auf der Festplatte voll war.
    Die Ursache dafür wiederum waren zu große/zu viele Binärlogs (30GB) von MySQL, die zum Abgleich mit dem redundanten MySQL-Server notwendig sind, aber nichts mit Logrotate zu tun haben.

    Folgende Gegenmaßnahmen wurden eingeleitet:
    1. Die Vorhaltezeit der Binärlogs wurde von 10 auf 5 Tage reduziert und damit sind aktuell dort nur 15 GB Verbrauch.
    2. Die Partition wurde von 50 auf 200 GB vergrößert.
    Trotz steigender Datenmengen wird der Platz in absehbarer Zeit nicht mehr aufgebraucht sein. Das Monitoring-System wird noch entsprechend erweitert, damit rechtzeitig eine Warnmeldung erzeugt wird.