Ich verwende Postgres schon seit einiger Zeit als Docker-Container. Anfangs waren TZ und PGTZ nicht eingestellt, daher denke ich, dass die Standardeinstellung UTC war. Auf meinem Entwicklungssystem habe ich Folgendes in docker-compose.yml ausprobiert:
postgres:
image: postgres:13
ports: ["5557:5432"]
restart: unless-stopped
volumes:
- ./Index:/var/lib/postgresql/data
environment:
TZ: "America/Cayman"
PGTZ: "America/Cayman"
POSTGRES_PASSWORD: "postgres"
und das scheint die Anpassung an die lokale Zeitzone vorzunehmen. Ich habe das nicht auf einem Live-System eingesetzt, weil ich mich frage, ob das irgendetwas in Bezug auf den DB-Transaktionsverlauf und die Protokolldateien usw. durcheinander bringen wird. Die DB-Integrität ist jetzt in Ordnung, und ich habe ein Backup, das ziemlich weit zurückreicht. Ich bin nicht sicher, ob es überhaupt wirklich notwendig ist, die Zeitzone einzustellen, aber es ist ganz nett, alle Container auf die lokale Zone statt auf UTC eingestellt zu haben.
Das andere Problem hat damit nichts zu tun und wird hier irgendwie erwähnt: WARNUNG: Statistikdatei „pg_stat_tmp/global.stat“ konnte nicht geöffnet werden: Vorgang nicht zulässig
Knapp:
Dieser Datenbankindex ist einem Ordner auf dem Host im Stammverzeichnis des Docker-Pakets zugeordnet, und alles andere scheint, soweit es die Datenbank betrifft, einwandfrei zu funktionieren. Ich verwende einen Mac, aber wenn ich die Berechtigung von der CLI für den DB-Ordner aufliste, erhalte ich:
-rw-------@ 1 sscotti staff 3 Feb 22 11:01 PG_VERSION
drwx------@ 6 sscotti staff 192 Feb 22 11:54 base
drwx------@ 60 sscotti staff 1920 Feb 22 16:00 global
drwx------@ 2 sscotti staff 64 Feb 22 11:01 pg_commit_ts
drwx------@ 2 sscotti staff 64 Feb 22 11:01 pg_dynshmem
-rw-------@ 1 sscotti staff 4782 Feb 22 11:02 pg_hba.conf
-rw-------@ 1 sscotti staff 1636 Feb 22 11:01 pg_ident.conf
drwx------@ 5 sscotti staff 160 Feb 22 17:46 pg_logical
drwx------@ 4 sscotti staff 128 Feb 22 11:01 pg_multixact
drwx------@ 2 sscotti staff 64 Feb 22 11:01 pg_notify
drwx------@ 2 sscotti staff 64 Feb 22 11:01 pg_replslot
drwx------@ 2 sscotti staff 64 Feb 22 11:01 pg_serial
drwx------@ 2 sscotti staff 64 Feb 22 11:01 pg_snapshots
drwx------@ 2 sscotti staff 64 Feb 22 16:00 pg_stat
drwx------@ 5 sscotti staff 160 Feb 22 17:50 pg_stat_tmp
drwx------@ 3 sscotti staff 96 Feb 22 11:01 pg_subtrans
drwx------@ 2 sscotti staff 64 Feb 22 11:01 pg_tblspc
drwx------@ 2 sscotti staff 64 Feb 22 11:01 pg_twophase
drwx------@ 4 sscotti staff 128 Feb 22 11:01 pg_wal
drwx------@ 3 sscotti staff 96 Feb 22 11:01 pg_xact
-rw-------@ 1 sscotti staff 88 Feb 22 11:01 postgresql.auto.conf
-rw-------@ 1 sscotti staff 28073 Feb 22 11:01 postgresql.conf
-rw-------@ 1 sscotti staff 36 Feb 22 16:00 postmaster.opts
-rw------- 1 sscotti staff 94 Feb 22 16:00 postmaster.pid
pg_stat folder is actually empty.
and pg_stat_temp has:
-rw------- 1 sscotti staff 1952 Feb 22 17:54 db_0.stat
-rw------- 1 sscotti staff 20360 Feb 22 17:54 db_13395.stat
-rw------- 1 sscotti staff 1151 Feb 22 17:54 global.stat
Das Problem scheint zu sein, dass die DB-Dateien an einen lokalen Ordner auf dem Host und nicht an ein Docker-Volume gebunden sind. Es ist viel bequemer, sie an einen lokalen Ordner zu binden, auf den vom Host aus leicht zugegriffen werden kann, aber ich denke, damit sind einige Berechtigungsprobleme verbunden. Vielleicht möchte ich tatsächlich zu einem Volume wechseln, aber das Volume muss weiterhin persistent sein und sich leicht auf einem lokalen NAS oder Cloud-Dienst sichern lassen, den wir für die Sicherung verwenden.
Bei Docker Desktop für MacOS scheint es bei der Verwendung gebundener Ordner anstelle von Volumes tatsächlich zu leichten Leistungseinbußen zu kommen, unter LINUX scheint dies jedoch kein Problem zu verursachen, obwohl die Warnung „Statistikdatei“ auch dort auftritt.
Danke.