Speicherplatz einer MongoDB freigeben

Hat man viele Daten in einer Datenbank gelöscht und möchte den Speicherplatz freigeben, kann die Funktion „repairDatabase()“ verwendet werden.

Dabei ist zu beachten, dass die Datenbank in ein „_tmp_repairDatabase_0“ Verzeichnis kopiert wird. Damit muss bei großen Datenbanken darauf geachtet werden, dass immer genug Speicherplatz zur Verfügung steht. Im Idealfall sollte die Platte mit maximal 50% belegt sein.

Ist genug Platz vorhanden, kann die Größe wie folgt reduziert werden:

> db.repairDatabase()
{ "ok" : 1 }

Ist nicht genug Platz vorhanden, bekommt man eine Fehlermeldung:

> db.repairDatabase()
{
    "ok" : 0,
    "errmsg" : "Cannot repair database DBNAME having size: 
    12342263808 (bytes) because free disk space is: 5431107584 (bytes)"
}

Als zweiter Stolperstein könnte sich auch der zu gering bemessene Memory erweisen. Als Richtwert sollten zirka 20% der Größe der Datenbank zur Verfügung stehen. Ist das nicht der Fall, könnte „repairDatabase()“ mit einem OOM abbrechen:

[conn164] Assertion: 13524:out of memory AlignedBuilder

Bei einem OOM kann man direkt mit Backup/Restore weitermachen, da ein größeres Dateisystem nicht helfen wird.

Ob das Dateisystem erweitert werden kann, hängt von der Architektur ab. Setzt man z.B. LVM mit EXT3 ein, wäre folgender Weg möglich:

# lvextend -L XXG /dev/sdaX
# resize2fs /dev/sdaX

Kann das Dateisystem nicht erweitert werden, bleibt als Lösung noch ein Backup/Restore. Bei sehr großen Datenbanken sollte eine Downtime eingeplant werden.

Im ersten Schritt erstellt man ein aktuelles Backup:

# mongodump -o backup/mongodb/ --authenticationDatabase admin \
  -d DBBAME -u admin -p

Danach löscht man die Datenbank:

# mongo localhost/admin -u admin -p
> use DBNAME
> db.dropDatabase()

Jetzt kann das Backup wiederhergestellt werden:

# mongorestore backup/mongodb/DBNAME/ -u admin -p

Danach ist der überflüssige Speicherplatz wieder frei.

Service Level Report 2013

Die Auswertung der Verfügbarkeit im Jahr 2013 mit Nagios zeigt folgendes Ergebnis:

99,94%

Die Verfügbarkeit wird für das Gesamtsystem und die wichtigsten Dienste gemessen (DNS, SMTP, HTTP, IMAP). Hier eine Übersicht der einzelnen Dienste:

Die Antwortzeiten des Apache Webserver haben sich im Gegensatz zu 2012 (zirka 100 ms) etwas verlängert, liegen mit zirka 150 ms aber immer noch im tief grünen Bereich:

Damit werden die SLA’s von 99,5% Verfügbarkeit und unter 1 Sekunde Antwortzeit locker erfüllt.

In diesem Jahr wurde auch erstmals ein kompletter Restore der wichtigsten Dienste aus dem Backup auf ein Testsystem durchgeführt. Die MTTR liegt damit aktuell bei zirka 5 Stunden.

Zukünftig ist geplant, die Reports Live zur Verfügung zu stellen. Dazu wird im Moment an einer eigenen Reporting Software für Nagios geschrieben. Einen ersten Ausblick findet man in folgendem Screenshot:

Sobald die Software ausgereift ist, wird sie als Open Source veröffentlicht und mit Anbindung an die Nagios Datenbank zur Verfügung gestellt.