Die Installation von MongoDB ist der erste praktische Schritt auf dem Weg zur Arbeit mit der Datenbank. Während Cloud-Services wie MongoDB Atlas die Installation komplett abstrahieren, ist das Verständnis einer lokalen Installation wertvoll – für Entwicklungsumgebungen, On-Premise-Deployments oder einfach zum Lernen der Mechanismen. MongoDB läuft auf allen gängigen Betriebssystemen, und der Installationsprozess ist mittlerweile gut standardisiert. Die folgenden Abschnitte behandeln Installation und grundlegende Konfiguration, wobei der Fokus auf Linux liegt, das in Produktionsumgebungen dominiert.
Bevor MongoDB installiert wird, sollten einige grundlegende Fragen geklärt sein. Das Betriebssystem ist offensichtlich, aber auch die Hardware-Dimensionierung verdient Aufmerksamkeit. MongoDB profitiert stark von RAM – je mehr Daten ins Working Set passen, desto schneller die Queries. Für Entwicklungszwecke reichen 2-4 GB RAM völlig aus. Produktionsumgebungen sollten großzügiger dimensioniert sein, typischerweise mindestens 16 GB, oft deutlich mehr.
Das Dateisystem spielt eine überraschend wichtige Rolle. MongoDB schreibt kontinuierlich Daten und Journal-Einträge. Dateisysteme mit guter Performance und Zuverlässigkeit sind essentiell. Unter Linux sind ext4 und XFS die empfohlenen Optionen. XFS wird oft für sehr große Datenmengen bevorzugt, während ext4 einen guten Allrounder darstellt. Windows-Installationen nutzen NTFS, was funktioniert, aber typischerweise nicht die Performance von Linux-Dateisystemen erreicht.
Speicherplatz sollte nicht knapp kalkuliert werden. Neben den eigentlichen Daten fallen Logs, Journal-Dateien und bei WiredTiger auch Checkpoints an. Als Faustregel: Das 1,5-fache der erwarteten Datenmenge als Minimum, besser das 2-3-fache für Wachstum und Overhead. Bei 100 GB erwarteter Daten also mindestens 150 GB, besser 200-300 GB freier Speicher.
Linux ist das bevorzugte Betriebssystem für MongoDB in Produktionsumgebungen. Die Installation erfolgt typischerweise über Package Manager wie apt (Debian/Ubuntu) oder yum/dnf (RedHat/CentOS). MongoDB stellt offizielle Repositories bereit, die stets aktuelle Versionen liefern – deutlich aktueller als die oft veralteten Pakete in den Standard-Repositories der Distributionen.
Der Prozess beginnt mit dem Hinzufügen des MongoDB-Repositories. Für Ubuntu sieht dies exemplarisch so aus:
# GPG-Schlüssel importieren
wget -qO - https://www.mongodb.org/static/pgp/server-7.0.asc | \
sudo apt-key add -
# Repository hinzufügen
echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu \
$(lsb_release -sc)/mongodb-org/7.0 multiverse" | \
sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list
# Paketliste aktualisieren
sudo apt-get updateDie Versionsnummer im Repository-Pfad (hier 7.0) sollte der gewünschten MongoDB-Version entsprechen. Es ist wichtig, bewusst eine Version zu wählen, nicht einfach die neueste zu nehmen. In Produktionsumgebungen will man oft LTS-Versionen (Long Term Support), die länger gepflegt werden. Die MongoDB-Versionierung folgt einem semantischen Schema: Major.Minor.Patch. Major-Releases (5.0, 6.0, 7.0) bringen neue Features, Minor-Releases bringen Verbesserungen, Patch-Releases beheben Bugs.
Nach dem Hinzufügen des Repositories erfolgt die eigentliche Installation:
sudo apt-get install -y mongodb-orgDieses Meta-Paket installiert alle notwendigen Komponenten: mongod (der Datenbank-Server), mongos (der Sharding-Router, optional), mongo/mongosh (die Shell) und diverse Tools wie mongodump und mongorestore. Die Installation legt auch einen systemd-Service an, was das Lifecycle-Management erheblich vereinfacht.
Für RedHat-basierte Systeme ist der Prozess analog, verwendet aber
yum/dnf statt apt. Die Repository-Konfiguration erfolgt über eine
.repo-Datei in /etc/yum.repos.d/. Die
Kommandos unterscheiden sich syntaktisch, konzeptionell ist es
identisch.
Windows-Installationen nutzen ein klassisches MSI-Paket, das von der MongoDB-Website heruntergeladen wird. Der grafische Installer führt durch den Prozess und bietet Optionen wie die Installation als Windows-Service oder nur der Binaries. Die Service-Installation ist für dauerhafte Setups praktisch, erlaubt aber weniger Flexibilität als manuelle Starts.
Eine Besonderheit von Windows: Der Standard-Datenpfad ist
C:\data\db\, und dieser muss explizit angelegt werden,
bevor MongoDB startet. Viele Anfänger stolpern darüber, dass MongoDB
nicht automatisch dieses Verzeichnis erstellt. Ein simples
mkdir C:\data\db in der Kommandozeile löst dies.
Unter macOS hat sich Homebrew als Standard-Installationsmethode etabliert:
brew tap mongodb/brew
brew install mongodb-community@7.0Homebrew verwaltet nicht nur die Installation, sondern auch Updates
und Services. Ein brew services start mongodb-community
startet MongoDB als Background-Service, der bei jedem Login automatisch
startet. Für Entwicklung ist dies komfortabel, für temporäre Tests kann
MongoDB auch manuell mit mongod gestartet werden.
Die folgende Tabelle fasst die plattformspezifischen Besonderheiten zusammen:
| Aspekt | Linux | Windows | macOS |
|---|---|---|---|
| Installation | Package Manager (apt/yum) | MSI-Installer | Homebrew |
| Service-Management | systemd | Windows Services | launchd/brew services |
| Standard-Datenpfad | /var/lib/mongodb |
C:\data\db |
/usr/local/var/mongodb |
| Standard-Logpfad | /var/log/mongodb |
C:\data\log |
/usr/local/var/log/mongodb |
| Konfigurationsdatei | /etc/mongod.conf |
Im Installationsverzeichnis | /usr/local/etc/mongod.conf |
| Empfehlung | Produktion & Entwicklung | Entwicklung | Entwicklung |
Nach der Installation sollte MongoDB gestartet und die Funktionsfähigkeit verifiziert werden. Unter Linux mit systemd ist dies elegant gelöst:
# Service starten
sudo systemctl start mongod
# Status prüfen
sudo systemctl status mongod
# Automatischen Start beim Booten aktivieren
sudo systemctl enable mongodDer status-Befehl zeigt nicht nur, ob der Service läuft,
sondern auch die letzten Log-Zeilen. Ein erfolgreich gestartetes MongoDB
zeigt Meldungen wie “Waiting for connections” und die Bind-Adresse
(typischerweise localhost:27017).
Die Verbindung zur Shell verifiziert, dass MongoDB Anfragen entgegennimmt:
mongoshIn neueren MongoDB-Versionen (ab 5.0) ist mongosh die
moderne Shell, die die alte mongo-Shell ersetzt. Die neue
Shell basiert auf Node.js, unterstützt moderne JavaScript-Syntax und
bietet bessere Fehlermeldungen. Ältere Versionen verwenden noch
mongo als Shell-Kommando.
In der Shell angekommen, sollten ein paar grundlegende Befehle funktionieren:
// MongoDB-Version anzeigen
db.version()
// Verfügbare Datenbanken auflisten
show dbs
// Testdatenbank erstellen und verwenden
use testdb
// Testdokument einfügen
db.test.insertOne({ message: "Hello MongoDB" })
// Dokument abfragen
db.test.find()Wenn diese Kommandos ohne Fehler durchlaufen, ist die Installation
erfolgreich. Das eingefügte Dokument sollte mit seiner automatisch
generierten _id zurückkommen.
MongoDB kann ohne Konfigurationsdatei gestartet werden und nutzt dann Standardwerte. Für alles außer Quick-Tests ist eine explizite Konfiguration aber unerlässlich. Die Konfigurationsdatei verwendet YAML-Syntax und ist in thematische Sektionen gegliedert.
Ein typisches mongod.conf für eine
Entwicklungsumgebung:
# Speicher-Konfiguration
storage:
dbPath: /var/lib/mongodb
journal:
enabled: true
engine: wiredTiger
wiredTiger:
engineConfig:
cacheSizeGB: 2
# Logging
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
verbosity: 0
# Netzwerk-Einstellungen
net:
port: 27017
bindIp: 127.0.0.1
# Prozess-Management
processManagement:
fork: true
pidFilePath: /var/run/mongodb/mongod.pid
# Sicherheit (initial deaktiviert für Setup)
#security:
# authorization: enabledDie storage-Sektion definiert, wo Daten liegen und
welche Storage Engine verwendet wird. WiredTiger ist seit MongoDB 3.0
der Standard und sollte beibehalten werden, es sei denn, es gibt sehr
spezifische Gründe dagegen. Die Journal-Einstellung sollte immer enabled
sein – das Journal ist MongoDBs Write-Ahead-Log, das Datenverlust bei
Crashes verhindert.
Der Cache-Size-Parameter ist kritisch für Performance. WiredTiger nutzt standardmäßig 50% des verfügbaren RAMs minus 1 GB. Auf einem Server mit 16 GB RAM wären das etwa 7 GB Cache. Für Entwicklung kann man dies reduzieren, um Ressourcen zu sparen. Produktionssysteme sollten den Standard verwenden oder erhöhen, wenn dedizierte Datenbank-Server vorliegen.
Die systemLog-Sektion steuert Logging.
logAppend: true fügt neue Logs an die bestehende Datei an,
statt sie zu überschreiben – wichtig für Debugging. Die Verbosity
steuert den Detail-Level: 0 ist normal, höhere Werte (1-5) erzeugen mehr
Details, nützlich für Debugging, aber Performance-intensiv.
Die net-Sektion ist sicherheitskritisch.
bindIp: 127.0.0.1 bedeutet, dass MongoDB nur Verbindungen
von localhost akzeptiert. Dies ist der sichere Standard für Entwicklung.
In Produktionsumgebungen, wo Anwendungen von anderen Servern verbinden,
muss dies angepasst werden. bindIp: 0.0.0.0 erlaubt
Verbindungen von überall – kombiniert mit deaktivierter
Authentifizierung ist dies ein massives Sicherheitsrisiko. Besser ist
es, spezifische IP-Adressen oder Netzwerkbereiche anzugeben.
Die auskommentierte security-Sektion ist für das
initiale Setup bewusst deaktiviert. MongoDB startet ohne
Authentifizierung, was die ersten Schritte erleichtert. Aber bereits
nach der ersten Einrichtung sollte Authentifizierung aktiviert werden.
Die Kommandos dazu folgen einem klaren Muster:
// Mit lokaler MongoDB verbinden (ohne Auth)
use admin
// Ersten Admin-User erstellen
db.createUser({
user: "admin",
pwd: "sicheres_passwort_hier",
roles: [ { role: "root", db: "admin" } ]
})Nach Erstellung des Admin-Users wird Authentifizierung in
mongod.conf aktiviert (Kommentar entfernen bei
authorization: enabled) und MongoDB neugestartet. Ab jetzt
erfordert jede Verbindung Credentials:
mongosh -u admin -p --authenticationDatabase adminEine funktionierende Installation ist nur der Anfang. Einige Schritte sollten standardmäßig folgen, besonders wenn die Installation produktionsnah sein soll.
Die Aktivierung der Authentifizierung wurde bereits erwähnt – sie ist nicht optional für Systeme, die über localhost hinaus erreichbar sind. Selbst für lokale Entwicklung ist sie gute Praxis, um produktionsnahe Bedingungen zu simulieren.
Die Firewall-Konfiguration sollte MongoDB-Ports explizit absichern. Port 27017 (Standard für mongod) sollte nur für vertrauenswürdige Quellen geöffnet sein. Idealerweise läuft MongoDB in einem privaten Netzwerk, unerreichbar vom Internet.
Monitoring sollte von Anfang an eingerichtet werden. MongoDB bietet
eingebaute Metriken über db.serverStatus() und
db.stats(). Für ernsthafte Überwachung sollten Tools wie
MongoDB Ops Manager, Prometheus mit MongoDB Exporter oder
Cloud-Monitoring bei Atlas zum Einsatz kommen.
Regelmäßige Backups sind nicht optional. Selbst in Entwicklung kann
ein Backup Stunden an Arbeit retten. MongoDB bietet mehrere
Backup-Strategien: mongodump für logische Backups,
Filesystem-Snapshots für konsistente Punkt-in-Zeit-Kopien, und
kontinuierliche Backups in Atlas.
Die Log-Rotation sollte konfiguriert werden, damit Logfiles nicht unbegrenzt wachsen. Unter Linux erledigt logrotate dies elegant:
# /etc/logrotate.d/mongodb
/var/log/mongodb/mongod.log {
daily
rotate 7
compress
delaycompress
notifempty
missingok
postrotate
/bin/kill -SIGUSR1 $(cat /var/run/mongodb/mongod.pid 2>/dev/null) 2>/dev/null || true
endscript
}Diese Konfiguration rotiert Logs täglich, behält sieben Tage, komprimiert alte Logs und signalisiert MongoDB, das Logfile neu zu öffnen.
Mit einer soliden Installation und Grundkonfiguration steht der eigentlichen Arbeit mit MongoDB nichts mehr im Weg. Die folgenden Kapitel bauen auf diesem Setup auf und zeigen fortgeschrittene Konfigurationen wie Replica Sets und Sharding.