ZODB reparieren

erstellt von Veit Schiele — zuletzt verändert: 19.04.2010 09:32

Mitwirkende: Simon Pamies, Andreas Jung

Eine Zope-Datenbank kann z.B. durch einen Systemabsturz oder einen Festplattendefekt korrumpiert werden. Dies macht sich meist durch einen POSKeyError oder einen CorruptedError und nicht mehr bearbeitbare Objekte bemerkbar.

CorruptedError

Dieser Fehler kann verschiedene Ursachen haben, z.B. falsche Längen oder Zeiten von Transaktionen.

fsrecover.py ist ein Skript, das die Integrität von Transaktionen überprüft und diejenigen mit korrupten Daten entfernt. Daher ist es auch nicht für POSKeyErrors geeignet sondern empfiehlt sich vielmehr für CorruptedErrors. Darüberhinaus kann es auch zu weiteren POSKeyErrors führen wenn eine fehlerhafte Transaktion entfernt wird und dadurch den Verweis auf ein nicht mehr vorhandenes Objekt zurücklässt:

$ ./bin/zopepy parts/zope2/lib/python/ZODB/fsrecover.py -P 0 var/filestorage/Data.fs var/filestorage/Data.fs.recovered &> logrecover.txt

In logrecover.txt können Sie anschließend nachschauen, wieviele Daten Ihnen verloren gingen.

POSKeyError

Um diesen Fehler zu verstehen ist es wichtig zu wissen, dass jedes Objekt in der Datenbank eine eindeutige ID (OID) zugewiesen bekommen hat. Diese OID ist eine binäre Zahl, wie z.B. 0x40A90L, die auf ein serialisiertes Objekt verweist. Bei einem POSKeyError kann nun für eine OID kein passendes Objekt gefunden werden. So speichert z.B. ein Ordner, der von OFS.ObjectManager abgeleitet ist, die enthaltenen Objekte als Werte des _objects-Attributs. Die daraus resultierende Liste wird beim Speichern in eine Liste von OIDs übersetzt. Kann nun beim Laden von objectValues() eine OID nicht mehr einem serialisierten Objekt zugewiesen werden, wird ein POSKeyError ausgegeben.

Mit zc.zodbdgc kommt ein Skript mit, das multi-zodb-check-refs. Es überprüft eine Sammlung von Datenbanken wobei ab der Wurzel durch die gesamten Datenbanken traversiert wird. Dies soll sicherzustellen, dass alle Objekte erreichbar sind und jedes nichterreichbare Objekt protokolliert werden kann. Darüberhinaus wird bei Blob-Eintragen überprüft, ob ihre Dateien geladen werden können.
Zum Installieren von zc.zodbdgc wird zunächst eine virtuelenv-Umgebung aufgesetzt:
```
$ easy_install-2.6 virtualenv
$ virtualenv --no-site-packages zeo_check
```
Anschließend wird in dieser virtuelenv-Umgebung zc.zodbdgc installiert:
```
$ cd zeo_check
$ ./bin/easy_install zc.zodbdgc
```
Packen Sie anschließend Ihre ZODB und kopieren diese in Ihre virtuelenv`-Umgebung.

Erzeugen Sie eine Konfigurationsdatei storages.cfg mit folgendem Inhalt:

<zodb 1>
  <filestorage>
      path /path/to/copy_of_Data.fs
  </filestorage>
</zodb>

Anschließend kann das multi-zodb-check-refs-Skript aufgerufen werden mit:
```
$ ./bin/multi-zodb-check-refs storages.cfg
```
Sind alle Referenzen Ihrer Datenbank gültig, so erhalten Sie keine Ausgabe. Bei POSKeyErrors sieht die Ausgabe beispielsweise so aus:
```
!!! 1 167688 ? POSKeyError: 0x028f08
!!! 1 167687 ? POSKeyError: 0x028f07
!!! 1 167686 ? POSKeyError: 0x028f06
!!! 1 167685 ? POSKeyError: 0x028f05
```

Regelmäßige Überprüfung und E-Mail-Benachrichtigung

Dieses Skript sollte nun regelmäßig als Cronjob ausgeführt werden:

# Check ZEO Storages
0 6 * * * cd /home/veit/zeo_check; ./multi-zodb-check-refs |mailx -s "Check Storages" -c admin@veit-schiele.de

Wiederherstellen

Möglicherweise können die fehlenden Objekte aus dem Backup zurückgespielt werden.
Mit der -r-Option erhalten Sie eine Datenbank mit entgegengesetzten Referenzen, womit sich gegebenenfalls herausfinden lässt, welche Objekte fehlen.

Weitere nützliche Werkzeuge

analyze.py: zeigt Informationen wie OID, Größe etc. der Objekte in der Datenbank.
fstest.py: überprüft die Datenbank auf korrupte Transaktionen.
fsrecover.py: repariert Transaktionsfehler in der Datenbank.

Benutzerspezifische Werkzeuge