Mögliche Probleme beim Sichern offener GeoPackages mithilfe der Python-Routine
Ich möchte eine einfache Sicherungsroutine mit Standard-Python erstellen, um meine GeoPackages zu sichern. Die Routine muss flexibel genug sein, um das Geopaket sichern zu können, während es geöffnet ist (im Lesemodus). Ich muss zwar nicht im Schreibmodus sichern, bin mir aber sicher, dass dies irgendwann auftreten wird. Mein Entwurf besteht einfach darin, eine Liste der GeoPackages, die ich hier habe, zu kopieren und zu komprimieren.
Meine Fragen sind also
- Gibt es bekannte Probleme beim Kopieren / Komprimieren eines GeoPackage, das sich derzeit im Lesemodus befindet (sowohl aus Sicht des Endbenutzers als auch aus Sicht der Sicherungsroutine?
- Wie oben, aber wenn sich das GeoPackage im Schreibmodus befindet?
Außerdem möchte ich eine einfache Python-Routine schreiben (eigentlich werde ich wahrscheinlich nur online nach einer suchen, so einfach wie möglich). Gibt es jedoch bekannte Funktionen in QGIS oder einer anderen Software, die diese Anforderung möglicherweise besser erfüllen?
Antworten
GeoPackages sind SQLite-Dateien. Daher sollten hier Techniken zum Sichern von SQLite-Dateien angewendet werden.
Die SQLite-Dokumente enthalten hier einige Informationen zu Sicherungen: https://sqlite.org/backup.html und gibt ein paar Methoden:
- Verwenden Sie die SQLite-Sicherungs-API aus C-Code. Ich bin mir nicht sicher, ob es dafür Python-Bindungen gibt.
- Öffnen Sie die Datenbank und führen Sie sie aus.
VACUUM INTO 'backup.gpkg';Dadurch wird die geöffnete Datenbank in eine neue Datenbank kopiertbackup.gpkgund gesaugt, um als gelöscht markierte Daten zu entfernen.
Wenn diese Methoden fehlerfrei ausgeführt werden (dh keine "Festplatte voll" oder Netzstecker entfernt), sollte die resultierende Ausgabedatei eine gültige SQLite-Datenbank und damit eine gültige GeoPackage-Sicherung des Originals sein. Es sollte auch konsistent sein (dh alle atomaren Operationen sind abgeschlossen) und sich nur geringfügig auf andere Prozesse auswirken, die die Datenbank verwenden (dh sie werden nicht für längere Zeit gesperrt).
Die VACUUM INTOMethode erfordert eine neuere Version von SQLiteTools als ich sie gerade auf meinem System hatte, aber das Herunterladen und Ausführen der neuesten Version ist wirklich einfach - ich musste nur die Linux-Binärdateien herunterladen, die einige Megabyte groß waren.
Es sollte keine Rolle spielen, ob die Datenbank von einem anderen Prozess beschrieben wird. Dieser Prozess kann während der Sicherung fortgesetzt werden. Wie viel des aktuell geschriebenen Inhalts jedoch gesichert wird, hängt vom genauen Zeitpunkt der Sicherung ab. In jedem Fall stellt die Konsistenz-Eigenschaft sicher, dass Ihre Sicherung bis zur Transaktionsebene des Schreibvorgangs abgeschlossen ist.
Sie erhalten möglicherweise mehr und bessere Antworten von http://dba.stackexchange.com/ denn schließlich ist GeoPackage nur eine SQLite-Datenbank.
Eine einfache Sicherungsmethode in einer GIS-Umgebung wäre, nur auszuführen
ogr2ogr -f gpkg backup.gpkg input.gpkg.
Dasselbe kann mit GDAL-Python-Bindungen durchgeführt werden, ohne die ausführbare Datei ogr2ogr zu verwenden. Da Daten in eine neue Datenbank geschrieben werden, wird die Datenbank effektiv von derselben vakuumiert. Wenn das GeoPackage jedoch im Lese- / Schreibmodus verwendet wird und ausstehende Transaktionen vorliegen, bin ich mir nicht sicher, welche Daten in der Kopie gespeichert werden.
Wenn Sie lieber mit Dateien spielen und wissen, dass die Datenbank schreibgeschützt geöffnet ist, können Sie sicher nur die Haupt-DB-Datei .gpkg sichern. Alle möglichen temporären Dateienhttps://sqlite.org/tempfiles.html kann übersprungen werden.
Sie können auch nur die .gpkg-Datei sichern, wenn die Datenbank als Lese- / Schreibzugriff geöffnet wird. Dann ist jedoch nicht sicher, was Ihre Sicherung enthalten wird. Eine bessere Option ist das Sichern auch der Journaldateien. Was sie sind, hängt vom Journalmodus ab, den die GeoPackage-Datenbank verwendet.
Wenn die GeoPackage-Datenbank Rollback-Journale verwendet https://sqlite.org/lockingv3.html#rollbackSie können überprüfen, ob die Journaldatei vorhanden ist. Wenn keine Journaldatei vorhanden ist, ist .gpkg auf dem neuesten Stand und Sie können genau das sichern. Wenn es eine Journaldatei gibt, können Sie auch diese sichern oder eine Schleife ausführen und warten, bis das Journal verschwindet. Normalerweise sind es nur Sekunden, aber manchmal kann es ein langes Warten bedeuten.
Wenn GeoPackage auf Write-Ahead-Protokollierung eingestellt ist https://sqlite.org/wal.htmlEine Sidecar-Wal-Datei wird auch erstellt, wenn die Datenbank schreibgeschützt geöffnet wird. Soweit ich weiß, ändert QGIS GeoPackages in WAL. Die Wal-Datei verschwindet erst, wenn die letzte Verbindung zur Datenbank ordnungsgemäß geschlossen wurde. Im Rollback-Journal-Modus enthält die .gpkg-Datei garantiert alle Änderungen, wenn keine Journaldatei vorhanden ist. Im WAL-Modus kann diese Logik jedoch nicht verwendet werden. Wenn Sie das System steuern und wissen, dass GeoPackage schreibgeschützt geöffnet ist, können Sie die Wal-Datei überspringen, da sie neuere ausstehende Transaktionen enthält. Andernfalls sollten Sie .gpkg- und wal- und shm-Dateien zusammen sichern, und die Sicherung würde genau von diesem Moment an einen Schnappschuss enthalten.
Ihr Sicherungssystem für den Lese- / Schreibfall könnte auch die .gpkg- und entweder die Journaldatei oder wal + shm an einen temporären Ort kopieren und dann die Datenbank öffnen und schließen. Auf diese Weise würden die ausstehenden Änderungen in die Hauptdatenbankdatei integriert, die Sidecar-Dateien würden verschwinden und Sie hätten nur eine .gpkg-Datei, die Sie in die endgültige Sicherung einfügen könnten.