Hands On: Installation einer Single Instance von MongoDB

Die Installation von MongoDB ist der erste Schritt von der Theorie zur Praxis. Während die vorherigen Kapitel Konzepte und Architekturen erklärten, wird es jetzt konkret: Eine funktionierende MongoDB-Instanz auf einem Linux-System aufsetzen, konfigurieren und erste Operationen durchführen. Diese Anleitung orientiert sich an Ubuntu, aber die Prinzipien gelten mit minimalen Anpassungen für alle gängigen Linux-Distributionen.

Wir installieren zunächst eine einzelne Standalone-Instanz – das einfachste Deployment-Modell. Dies eignet sich hervorragend für lokale Entwicklung, Experimente und erste Schritte. Später werden wir Replica Sets und Sharded Clusters aufsetzen, aber der Anfang ist bewusst schlicht. Eine funktionierende Standalone-Instanz ist die Basis für alles Weitere.

17.1 Systemvorbereitung: Updates und Dependencies

Bevor MongoDB installiert wird, sollte das System aktuell sein. Veraltete Systempakete können zu Inkompatibilitäten oder subtilen Bugs führen. Die Aktualisierung ist mit zwei Befehlen erledigt:

sudo apt update && sudo apt upgrade -y

Der erste Befehl (apt update) aktualisiert die Paketlisten – Ubuntu erfährt, welche Versionen von Software verfügbar sind. Der zweite Befehl (apt upgrade) installiert tatsächlich die Updates. Das -y-Flag bestätigt automatisch alle Nachfragen, was in Scripts nützlich ist.

Diese Aktualisierung kann je nach Zustand des Systems einige Minuten dauern. Wichtige System-Libraries wie glibc oder OpenSSL werden dabei oft aktualisiert. Ein Neustart ist danach empfehlenswert, wenn Kernel-Updates dabei waren, aber nicht zwingend notwendig für MongoDB.

17.2 MongoDB-Repository einrichten: Aktuelle Versionen garantieren

Ubuntu’s Standard-Repositories enthalten MongoDB, aber oft veraltete Versionen. Ubuntu 20.04 LTS liefert etwa MongoDB 3.6 aus – eine Version von 2018, die längst End-of-Life ist. Für produktive Arbeit und um aktuelle Features zu nutzen, brauchen wir die offiziellen MongoDB-Repositories.

MongoDB signiert seine Pakete mit einem GPG-Key. Dieser Key stellt sicher, dass Pakete tatsächlich von MongoDB Inc. stammen und nicht manipuliert wurden. Der Import des Keys ist der erste Schritt:

wget -qO - https://www.mongodb.org/static/pgp/server-7.0.asc | sudo apt-key add -

Dieser Befehl lädt den Public Key für MongoDB 7.0 herunter und fügt ihn zum System-Keyring hinzu. Das -qO - in wget bedeutet: leise downloaden und auf stdout ausgeben. Die Pipe leitet dies zu apt-key add, das den Key installiert.

Mit dem Key vorhanden können wir das Repository selbst hinzufügen. Die Repository-URL ist distributionsspezifisch – Ubuntu 20.04 (“Focal”), 22.04 (“Jammy”) und 24.04 (“Noble”) haben unterschiedliche Repositories. Für Ubuntu 22.04 wäre der Befehl:

echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list

Diese Zeile erstellt eine neue Datei in /etc/apt/sources.list.d/ – dem Verzeichnis, wo Ubuntu zusätzliche Paketquellen speichert. Die Datei enthält die URL zum MongoDB-Repository, spezifiziert für Jammy (Ubuntu 22.04) und MongoDB 7.0. Die arch=amd64,arm64-Angabe bedeutet, dass dieses Repository sowohl für x86_64- als auch ARM64-Systeme funktioniert.

sudo apt update

Apt kontaktiert nun das MongoDB-Repository, lädt die Paketlisten herunter und integriert sie in seine Datenbank. Sollten Fehler auftreten – etwa “GPG error” oder “repository not found” – sind typischerweise der Key nicht korrekt importiert oder die URL falsch. Ein apt-key list | grep MongoDB zeigt, ob der Key vorhanden ist.

17.3 Installation: MongoDB und Tools

sudo apt install -y mongodb-org

Dieses Meta-Paket installiert eine Handvoll Komponenten: mongodb-org-server (mongod selbst), mongodb-org-mongos (der Sharding-Router), mongodb-org-shell (die Shell, mittlerweile mongosh), mongodb-org-tools (mongodump, mongorestore und andere Utilities) und mongodb-org-database-tools-extra (zusätzliche Tools).

Die Installation dauert typischerweise unter einer Minute. Apt lädt die Pakete herunter, entpackt sie, installiert Binaries nach /usr/bin/, Konfigurationen nach /etc/, und richtet einen systemd-Service ein. Nach Abschluss ist MongoDB installiert, aber noch nicht gestartet.

Sollte die Installation fehlschlagen mit Abhängigkeitsproblemen, ist oft libssl betroffen. MongoDB benötigt eine spezifische OpenSSL-Version. Ubuntu 20.04 und 22.04 sind kompatibel, aber bei älteren oder neueren Versionen kann es zu Konflikten kommen. Ein apt-cache policy libssl1.1 zeigt die verfügbare Version.

17.4 Erster Start: MongoDB zum Leben erwecken

MongoDB ist installiert, läuft aber noch nicht. Der systemd-Service muss manuell gestartet werden:

sudo systemctl start mongod

Dieser Befehl ist synchron – er kehrt zurück, sobald mongod gestartet ist. Sollte der Start fehlschlagen, gibt systemctl einen Fehlercode zurück. Die erste Anlaufstelle für Troubleshooting ist der Service-Status:

sudo systemctl status mongod

Ein erfolgreich gestartetes MongoDB zeigt “active (running)” in grüner Farbe. Die letzten Log-Zeilen sind ebenfalls sichtbar und sollten etwas wie “Waiting for connections on port 27017” enthalten. Sollte der Status “failed” zeigen, geben die Logs Hinweise. Typische Probleme sind:

Das Datenverzeichnis /var/lib/mongodb existiert nicht oder hat falsche Permissions. MongoDB läuft unter dem User mongodb, und dieser muss Schreib- und Lesezugriff haben. Ein sudo chown -R mongodb:mongodb /var/lib/mongodb korrigiert dies meist.

Der Port 27017 ist bereits belegt – ein anderer Prozess lauscht darauf. Ein sudo netstat -tlnp | grep 27017 zeigt, wer den Port hält. Oft ist es eine alte MongoDB-Instanz, die nicht sauber beendet wurde. Ein Kill des Prozesses und erneuter Start löst dies.

Die Konfigurationsdatei /etc/mongod.conf hat Syntaxfehler. MongoDB startet nicht, wenn die YAML-Syntax inkorrekt ist. Ein YAML-Validator kann helfen, oder einfach die Default-Config wiederherstellen.

Wenn MongoDB läuft, sollte es beim Systemstart automatisch starten. Dies erreichen wir mit:

sudo systemctl enable mongod

Dieser Befehl erstellt einen Symlink, der systemd anweist, mongod beim Booten zu starten. Ein Reboot-Test bestätigt, dass dies funktioniert – nach dem Neustart sollte MongoDB ohne manuelle Intervention laufen.

17.5 Verbindung testen: Die erste Interaktion

Mit laufendem MongoDB ist der nächste Schritt die Verbindung. Die moderne Shell ist mongosh (MongoDB Shell), die die alte mongo-Shell seit Version 5.x ersetzt:

mongosh

Ohne weitere Parameter verbindet mongosh sich mit localhost:27017 – den MongoDB-Defaults. Die Shell zeigt einen Willkommenstext, die MongoDB-Version, und einen Prompt:

Dieser Prompt zeigt die aktuelle Datenbank – “test” ist der Default. Von hier können wir erste Befehle absetzen:

// MongoDB-Version anzeigen
db.version()

// Verfügbare Datenbanken listen
show dbs

// Eine neue Datenbank erstellen durch Nutzung
use handson

// Ein Dokument einfügen
db.testcollection.insertOne({ 
  message: "Hello MongoDB",
  timestamp: new Date(),
  author: "Hands-On Tutorial"
})

// Das eingefügte Dokument abfragen
db.testcollection.find()

Diese einfachen Operationen verifizieren, dass MongoDB funktioniert. Das insertOne sollte erfolgreich sein und eine acknowledged: true-Response zurückgeben, zusammen mit der generierten _id. Das find() sollte das Dokument zurückgeben.

Sollte die Verbindung fehlschlagen mit “connection refused”, läuft MongoDB entweder nicht (Status prüfen) oder lauscht nicht auf dem erwarteten Port/Interface. Die /etc/mongod.conf definiert net.bindIp – standardmäßig 127.0.0.1, also nur localhost. Für Remote-Verbindungen muss dies angepasst werden, aber für lokale Tests ist der Default korrekt.

17.6 Konfiguration verstehen und anpassen

Die Konfigurationsdatei /etc/mongod.conf steuert MongoDB’s Verhalten. Sie ist in YAML geschrieben und in thematische Sektionen gegliedert. Ein unmodifiziertes Default-Config sieht ungefähr so aus:

# Speicher-Konfiguration
storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

# Logging
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

# Netzwerk
net:
  port: 27017
  bindIp: 127.0.0.1

# Prozess-Management
processManagement:
  timeZoneInfo: /usr/share/zoneinfo

Der dbPath definiert, wo MongoDB Daten speichert. Der Standard /var/lib/mongodb ist sinnvoll, aber wenn mehr Speicherplatz auf einem anderen Volume verfügbar ist, kann man dies ändern. Nach der Änderung muss das Verzeichnis existieren und dem mongodb-User gehören.

Die bindIp definiert, auf welchen Netzwerkinterfaces MongoDB lauscht. 127.0.0.1 bedeutet nur localhost – Verbindungen von anderen Maschinen werden abgelehnt. Für Entwicklung auf einem Remote-Server oder für Anwendungen, die von anderen Hosts verbinden, muss dies auf 0.0.0.0 geändert werden (lauscht auf allen Interfaces) oder auf spezifische IPs. Achtung: 0.0.0.0 ohne Authentifizierung ist ein Sicherheitsrisiko. Kapitel 35 behandelt User-Management.

Der port ist normalerweise 27017. Änderungen sind nur nötig, wenn mehrere MongoDB-Instanzen auf demselben Server laufen oder wenn 27017 bereits belegt ist.

sudo systemctl restart mongod

Ein Neustart bedeutet kurze Downtime – Sekunden typischerweise, aber bestehende Verbindungen werden getrennt. Für Produktionssysteme sollten Config-Änderungen geplant werden.

17.7 Mehrere Instanzen: Manuelles Starten für Experimente

Manchmal ist es nützlich, mehrere MongoDB-Instanzen auf demselben Host zu betreiben – etwa um Replica Sets lokal zu simulieren oder verschiedene Versionen zu testen. Der systemd-Service managed nur eine Instanz, aber MongoDB kann auch manuell gestartet werden.

Für eine zweite Instanz brauchen wir ein separates Datenverzeichnis und einen anderen Port:

# Verzeichnis erstellen
mkdir -p ~/mongodb-data/instance1
mkdir -p ~/mongodb-data/instance2

# Erste Instanz starten (Vordergrund, für Tests)
mongod --port 27017 --dbpath ~/mongodb-data/instance1

# In neuem Terminal: Zweite Instanz
mongod --port 27018 --dbpath ~/mongodb-data/instance2

Diese Befehle starten MongoDB im Vordergrund – die Shell bleibt blockiert, Logs erscheinen direkt. Dies ist ideal für Experimente, wo man Logs live sehen will. Für Hintergrund-Betrieb fügt man --fork hinzu und muss dann auch --logpath angeben:

mongod --port 27017 \
       --dbpath ~/mongodb-data/instance1 \
       --logpath ~/mongodb-data/instance1/mongod.log \
       --fork

Der --fork-Parameter weist mongod an, sich in den Hintergrund zu forken. Der Elternprozess terminiert, das Kind läuft weiter. Die PID wird ausgegeben – notieren, um den Prozess später zu stoppen.

# Zu Instanz auf 27017 verbinden
mongosh --port 27017

# Zu Instanz auf 27018 verbinden
mongosh --port 27018

Jede Instanz ist völlig isoliert – separate Datenbanken, separate Users, separate Collections. Änderungen in einer betreffen die andere nicht. Dies ist nützlich, um verschiedene Szenarien parallel zu testen oder um lokale Replica-Set-Experimente durchzuführen (Kapitel 17 behandelt dies im Detail).

Das Stoppen manuell gestarteter Instanzen erfolgt über die Shell oder direktes Kill des Prozesses:

// In mongosh verbunden mit der Instanz
use admin
db.shutdownServer()

# PID finden
ps aux | grep mongod

# Graceful Shutdown mit SIGTERM
kill -TERM <pid>

# Forciertes Kill nur im Notfall
kill -9 <pid>

Ein graceful Shutdown ist wichtig – SIGTERM gibt MongoDB Zeit, aktive Operationen abzuschließen und sauber zu beenden. SIGKILL (-9) terminiert sofort, was zu inkonsistentem Zustand führen kann. Nach einem Kill-9 startet MongoDB beim nächsten Start in Recovery-Mode und replayed das Journal.

17.8 Logs verstehen: Was MongoDB erzählt

MongoDB ist gesprächig. Die Logs in /var/log/mongodb/mongod.log enthalten wertvolle Informationen über Startup, laufende Operationen und Probleme. Nach dem Start zeigt das Log typischerweise:

Die Logs sind im JSON-Format, was maschinelle Verarbeitung erleichtert. Wichtige Felder:

"s" ist die Severity: “I” für Info, “W” für Warning, “E” für Error. Warnings sollten beachtet, Errors umgehend adressiert werden.

"c" ist die Komponente: “STORAGE” für Storage-Engine-Messages, “NETWORK” für Netzwerk-Events, “QUERY” für Query-Logs.

"msg" ist die eigentliche Message. “Waiting for connections” bedeutet, MongoDB ist bereit. “Connection accepted” erscheint bei jeder neuen Verbindung.

Sollten Probleme auftreten, sind die Logs die erste Anlaufstelle. Ein häufiges Warning: “Using the XFS filesystem is strongly recommended with the WiredTiger storage engine”. Dies erscheint, wenn MongoDB auf ext4 oder anderen Dateisystemen läuft. Es ist ein Hinweis, keine Blockade, aber für Produktion sollte XFS verwendet werden (siehe Kapitel 11).

// In mongosh
db.setLogLevel(2, "query")  // Detaillierte Query-Logs

Dies erzeugt deutlich mehr Output – jede Query wird geloggt mit Execution-Plan und Timing. Nützlich für Performance-Analysen, aber zu viel für normalen Betrieb. Nach dem Debugging sollte es zurückgesetzt werden:

db.setLogLevel(0, "query")  // Zurück zu Standard

17.9 Nächste Schritte: Von Standalone zu Replica Sets

Eine Standalone-Instanz ist funktional, aber nicht produktionsreif. Kapitel 17 führt Replica Sets ein – der Standard für jedes produktive Deployment. Ein Replica Set bietet Hochverfügbarkeit und automatisches Failover, Eigenschaften, die eine Standalone-Instanz nicht hat.

Für jetzt aber ist das Ziel erreicht: MongoDB läuft, akzeptiert Verbindungen, und erste CRUD-Operationen funktionieren. Die Basis für alles Weitere steht. Die folgenden Kapitel bauen darauf auf und führen schrittweise in fortgeschrittenere Konzepte ein.

17 Hands On: Installation einer Single Instance von MongoDB