Es scheint, als ob MongoDB 3.6 nicht automatisch so konfiguriert ist, dass es nach einem Absturz neu gestartet wird. Wenn man sich den systemd-Dienst ansieht, der mit dem neuesten .deb-Paket für Ubuntu 16.04LTS gebündelt ist, scheint dort kein Neustart konfiguriert zu sein:
$ sudo systemctl cat mongod
# /lib/systemd/system/mongod.service
[Unit]
Description=High-performance, schema-free document-oriented database
After=network.target
Documentation=https://docs.mongodb.org/manual
[Service]
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
PIDFile=/var/run/mongodb/mongod.pid
# file size
LimitFSIZE=infinity
# cpu time
LimitCPU=infinity
# virtual memory size
LimitAS=infinity
# open files
LimitNOFILE=64000
# processes/threads
LimitNPROC=64000
# locked memory
LimitMEMLOCK=infinity
# total threads (user+kernel)
TasksMax=infinity
TasksAccounting=false
# Recommended limits for for mongod as specified in
# http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings
[Install]
WantedBy=multi-user.target
Das Senden von SIGKILL und SIGSEGV beendet den Prozess und er wird nicht neu gestartet. Ich bin mir jedoch nicht sicher, ob diese von systemd „abgefangen“ und nicht einfach neu gestartet werden.
Also ein paar Fragen: Ist das für einen hochverfügbaren Dienst wie eine Datenbank entscheidend? Es scheint jedenfalls so. Gibt es einen Grund, warum MongoDB das nicht standardmäßig konfiguriert hat?
Antwort1
Bei einem unerwarteten Herunterfahren ist ein Eingreifen des Administrators auf jeden Fall dringend zu empfehlen. Sie können die Dienstvorgabe für Ihre Bereitstellungen jedoch jederzeit ändern.
Wenn der Grund für mongoddas Herunterfahren eines Prozesses eine Invariante ist, die nicht ohne manuelles Eingreifen behoben werden kann (z. B. zu wenig Speicherplatz oder beschädigte Datendateien), sind automatische Neustarts nicht hilfreich und könnten die Situation möglicherweise verschlimmern. Im Allgemeinen mongodsollte ein Prozess nicht bei behebbaren Fehlern heruntergefahren werden. Die MongoDBServer-Ausnahmearchitekturunterscheidet zwischen schwerwiegenden Fehlern pro Vorgang und solchen, die für den gesamten Prozess schwerwiegend sind. Prozessschwerwiegende Fehler sind Situationen, in denen die Fortsetzung zu schwerwiegenden Folgen wie Datenverlust oder beschädigten Daten auf der Festplatte führen kann. Ein vom Benutzer oder Betriebssystem initiiertes Signal zum Beenden des Prozesses (z. B. derOut-of-Memory, auch bekannt als OOM-Killerunter Linux) führt ebenfalls mongodzum Herunterfahren.
Ein Beispielfehler, der in den Kommentaren erwähnt wurde, war ein Indexaufbau, der auf einigen Sekundärservern mit einer älteren Version von MongoDB einen Segmentierungsfehler verursachte. Bei automatischen Dienstneustarts könnte dieses Szenario möglicherweise zu einer Endlosschleife führen, in der ein Sekundärserver abstürzt, neu startet, den Indexaufbau fortsetzt, auf denselben Zustand stößt und neu startet … nur um einen zum Scheitern verurteilten Indexaufbau fortzusetzen. Während diese Neustartschleife läuft, könnte die zeitweise Verfügbarkeit des Sekundärservers Clients beeinträchtigen, die sekundäre Leseeinstellungen oder andere Mitglieder des Replikatsatzes verwenden (z. B. wiederholtes Suchen in einem Upstream-Oplog, um die Synchronisierung fortzusetzen).
Als Systemadministrator würde ich lieber die MongoDB-Protokolle überprüfen und versuchen, herauszufinden, warum der Prozess beendet wurde, damit die Grundursache behoben werden kann. Im Idealfall verfügt eine Bereitstellung über ausreichendFehlertoleranzum mit der Nichtverfügbarkeit von Mitgliedern klarzukommen, sodass Zeit bleibt, die Situation zu untersuchen und zu beheben.
Je nach Art des Problems und der Bereitstellung (Standalone, Replikat-Set oder Sharded-Cluster) möchte ich möglicherweise auch eine Sicherungskopie der Datendateien erstellen, bevor ich eine automatische oder manuelle Wiederherstellung versuche. Wenn beispielsweise nach einem unsauberen Herunterfahren neu gestartet wird, mongodgibt es eine anfängliche Wiederherstellungsphase, in der ausstehende Journaleinträge angewendet und Speicher-Engine-Prüfungen wie die Integrität der Datendateien ausgeführt werden dbPath. Bei einem Standalone-Server wäre es ratsam, vor Wiederherstellungs-/Reparaturversuchen eine Kopie der unveränderten Datendateien zu erstellen. Bei einer Bereitstellung mit Replikat-Set sind die Daten bereits auf einem anderen Mitglied des Replikat-Sets dupliziert. Wenn die Standardwiederherstellung also nicht erfolgreich ist, würde ichdieses Mitglied erneut synchronisierenanstatt eine Reparatur zu versuchen.
Antwort2
Wenn Sie systemd verwenden, sollte Restart=alwaysin diesem [Service]Abschnitt ein Neustart des Dienstes nach einem Absturz zugelassen werden.
Antwort3
Wenn Ihnen eine hohe Verfügbarkeit wirklich wichtig ist, würden Sie ein Replikatset ausführen und mit dem Ausfall eines oder mehrerer Knoten umgehen können.
Nachdem ich persönlich fünf Jahre lang eine große, geteilte MongoDB-Bereitstellung in der Produktion verwaltet habe, würde ich es vorziehen, wenn die Instanzen NICHT automatisch neu gestartet würden, da ich alle Probleme untersuchen möchte, bevor sie wieder in die Rotation im Replikatsatz aufgenommen werden.
https://docs.mongodb.com/manual/core/replica-set-high-availability/