bei der Erstellung eines Base Backups für die Point in Time Recovery sperrt der Copy Befehl scheinbar die einzelnen Dateien, die er gerade kopiert. Unter Unix werden Kopierprogramme wie cpio oder ähnliches empfohlen. Gibt es ein Kopierprogramm/Alternative unter Windows, dass das Kopieren des data-Verzeichnisses ohne Einfluss auf den laufenden Datenbankbetrieb gewährleistet?
Ja, wenn ich mit
SELECT pg_start_backup(‘label’);
ein Backup starte, dann ist alles noch in Ordnung. Erst wenn ich copy drauf los lasse wird die Datei gesperrt, die gerade kopiert wird.
Ich glaub für Cygwin müsste ich den Server neustarten, was nicht so schön wäre.
Außerdem habe ich noch einen anderen Ansatz. In der Mailinglist habe ich gelesen, dass so eine Fehlermeldung in einem anderen Kontext durch ein
Background-Virenscanner hervorgerufen wurde. Jetzt werd ich mal probieren diesen abzuschalten. Schließlich kann ich ja nicht der Einzige sein, der PostgreSQL unter Windows nutzt und Backups erstellen will.
muss nix anderes sein - wenn ein prozess eine datei oeffnet kann der prozess entscheiden ob andere prozesse zugriff haben duerfen (lesen schreiben etc) … im grunde ist das dann auch eine “permission”
ebenso wird ein prozess, der die datei oeffnet, sie ja auch in einem entsprechenden modus oeffnen wollen. wenn der andere prozess (copy) z.B. die datei fuer read - mit share read oeffnet, dann wird PG die gleiche datei nicht fuer read/write oeffnen koennen → permission denied.
und immer gilt - wer zuerst kommt, malt zuerst
deswegen soll der PG-dienst / deamon ja auch abgeschaltet (beendet) sein, wenn man die dateien wegkopieren will
moment … mit share read hatte ich eben ein denkfehler … es koennte durchaus sein, dass CP die datei öffnen kann wenn PG share-read erlaubt …
allerdings sollte es zum fehler kommen, wenn CP die datei zuerst oeffnet und auch nur share-read erlaubt - aber PG sie ja pauschal auch zum schreiben oeffnen wollen wird (vermutlich)
Ich wüsste nicht, was an: “du darfst der Datenbank die Dateien im laufenden Betrieb wegkopieren und das funktioniert hinterher noch” unsauber ist. So etwas nennt sich Online-Backup und sorgt für massiv verminderte Downtime.
daran ist nix unsauber - bis auf die methode schlechthin
was mich stark wundert ist dass man bei einem pg-dump das abknipsen des servers empfielt (aus gutem grund) aber bei einem copy nicht ? das macht irgendwie keinen sinn - zumal pg-dump eher in der lage waere mit dem server geeignet zu kommunizieren
das problem ist aber ein anderes - wenn COPY die datei geoeffnet hat und dann ein PG-prozess erzeugt wird (waerend das copy laeuft) dann wird dieser PG-prozess u.U. die datei nicht so öffnen dürfen wie es gern möchte, weil COPY vermutlich nur “share read” zulaesst → permission denied
ist zuerst ein PG-Prozess am ball … ist die situation eine andere
was mich stark wundert ist dass man bei einem pg-dump das abknipsen des servers empfielt (aus gutem grund) aber bei einem copy nicht ?
Wo steht das?
das macht irgendwie keinen sinn
Natürlich macht es keinen Sinn, einen Datenbankserver für ein Backup herunterzufahren - oder hast du etwas anderes gemeint?
das problem ist aber ein anderes - wenn COPY die datei geoeffnet hat und dann ein PG-prozess erzeugt wird (waerend das copy laeuft) dann wird dieser PG-prozess u.U. die datei nicht so öffnen dürfen wie es gern möchte, weil COPY vermutlich nur “share read” zulaesst → permission denied
Unter vernünftigen Betriebssystemen funktioniert das auch mit dem Kopieren geöffneter Dateien. Wenn das unter Windows nicht klappt … liegt das wahrscheinlich nicht an PostgreSQL.
das problem ist aber ein anderes - wenn COPY die datei geoeffnet hat und dann ein PG-prozess erzeugt wird (waerend das copy laeuft) dann wird dieser PG-prozess u.U. die datei nicht so öffnen dürfen wie es gern möchte, weil COPY vermutlich nur “share read” zulaesst → permission denied
Nein. Probier es aus. Erzeuge in einer TX eine neue Tabelle, ermittle die relfilenode, öffne diese mit vi, inserte etwas in die Tabelle. Geht alles. Auch als jemand, der Windows nicht mag: der dokumentierte Weg vom PITR funktioniert, auch unter Windows. Zumindest so lange, wie man kein Eiterpickel hat…