PostgreSQL 13 Update von PostgreSQL 10 schlägt fehl

Fortsetzung der Diskussion aus PostgreSQL 13-Update:

Ich betreibe ein Multisite-System mit einer 2-Container-Konfiguration (nur die Vorlagen postgres.10 und redis im Datencontainer). Die aktuelle PostgreSQL-Version ist 10, und ich möchte auf Version 13 aktualisieren. Hier ist der Fehler, der beim Neuaufbau des data-Containers auftritt:

fixing permissions on existing directory /shared/postgres_data_new ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok


Success. You can now start the database server using:

    /usr/lib/postgresql/13/bin/pg_ctl -D /shared/postgres_data_new -l logfile start

Get:1 http://security.debian.org/debian-security buster/updates InRelease [65.4 kB]
Hit:2 http://deb.debian.org/debian buster InRelease
Get:3 http://deb.debian.org/debian buster-updates InRelease [51.9 kB]
Get:4 http://apt.postgresql.org/pub/repos/apt buster-pgdg InRelease [104 kB]
Get:5 http://security.debian.org/debian-security buster/updates/main amd64 Packages [291 kB]
Get:6 http://apt.postgresql.org/pub/repos/apt buster-pgdg/main amd64 Packages [231 kB]
Hit:7 https://deb.nodesource.com/node_15.x buster InRelease
Fetched 743 kB in 1s (944 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  postgresql-client-10
Suggested packages:
  postgresql-doc-10
The following NEW packages will be installed:
  postgresql-10 postgresql-client-10
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 6,441 kB of archives.
After this Operation, 30.6 MB of additional disk space will be used.
Get:1 http://apt.postgresql.org/pub/repos/apt buster-pgdg/main amd64 postgresql-client-10 amd64 10.17-1.pgdg100+1 [1,439 kB]
Get:2 http://apt.postgresql.org/pub/repos/apt buster-pgdg/main amd64 postgresql-10 amd64 10.17-1.pgdg100+1 [5,002 kB]
Fetched 6,441 kB in 0s (34.9 MB/s)
Selecting previously unselected package postgresql-client-10.
(Reading database ... 43021 files and directories currently installed.)
Preparing to unpack .../postgresql-client-10_10.17-1.pgdg100+1_amd64.deb ...
Unpacking postgresql-client-10 (10.17-1.pgdg100+1) ...
Selecting previously unselected package postgresql-10.
Preparing to unpack .../postgresql-10_10.17-1.pgdg100+1_amd64.deb ...
Unpacking postgresql-10 (10.17-1.pgdg100+1) ...
Setting up postgresql-client-10 (10.17-1.pgdg100+1) ...
update-alternatives: warning: forcing reinstallation of alternative /usr/share/postgresql/13/man/man1/psql.1.gz because link group psql.1.gz is broken
Setting up postgresql-10 (10.17-1.pgdg100+1) ...
Creating new PostgreSQL cluster 10/main ...
/usr/lib/postgresql/10/bin/initdb -D /var/lib/postgresql/10/main --auth-local peer --auth-host md5
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "C.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/10/main ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default timezone ... Etc/UTC
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

Success. You can now start the database server using:

    pg_ctlcluster 10 main start

Ver Cluster Port Status Owner    Data directory              Log file
10  main    5433 down   postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
update-alternatives: warning: forcing reinstallation of alternative /usr/share/postgresql/13/man/man1/postmaster.1.gz because link group postmaster.1.gz is broken
invoke-rc.d: could not determine current runlevel
invoke-rc.d: policy-rc.d denied execution of start.
Processing triggers for postgresql-common (226.pgdg100+1) ...
Building PostgreSQL dictionaries from installed myspell/hunspell packages...
Removing obsolete dictionary files:
Stopping PostgreSQL 10 database server: main.
Stopping PostgreSQL 13 database server: main.
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok

The source cluster was not shut down cleanly.
Failure, exiting
-------------------------------------------------------------------------------------
UPGRADE OF POSTGRES FAILED

Please visit https://meta.discourse.org/t/postgresql-13-update/172563 for support.

You can run ./launcher start app to restart your app in the meanwhile




FAILED
--------------------
Pups::ExecError: /root/upgrade_postgres failed with return #<Process::Status: pid 49 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params "/root/upgrade_postgres"
1f253827e5700e1861c4e586213aaffa8994e452e43b9336301dcd02072e00f4
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.

Wenn ich die Vorlage postgres.10 wieder aktiviere, funktioniert alles.
Wissen Sie, was ich tun kann, um auf PostgreSQL 13 zu aktualisieren?

PS: Das Upgrade auf PostgreSQL 12 schlägt ebenfalls fehl.

2 „Gefällt mir“

Ich habe gesehen, dass es erforderlich ist, den Datencontainer vorher zu stoppen:

Das ist das Ergebnis, das ich erhalte, wenn ich nach dem Stoppen der beiden Container tail -f shared/data/log/var-log/postgres/current ausführe:

2021-06-06 16:38:37.411 UTC [113] HINT:  The server must be started by the user that owns the data directory.
2021-06-06 16:38:38.424 GMT [114] LOG:  skipping missing configuration file "/shared/postgres_data/postgresql.auto.conf"
2021-06-06 16:38:38.424 UTC [114] FATAL:  data directory "/shared/postgres_data" has wrong ownership
2021-06-06 16:38:38.424 UTC [114] HINT:  The server must be started by the user that owns the data directory.
2021-06-06 16:38:39.439 GMT [115] LOG:  skipping missing configuration file "/shared/postgres_data/postgresql.auto.conf"
2021-06-06 16:38:39.439 UTC [115] FATAL:  data directory "/shared/postgres_data" has wrong ownership
2021-06-06 16:38:39.439 UTC [115] HINT:  The server must be started by the user that owns the data directory.
2021-06-06 16:38:40.461 GMT [116] LOG:  skipping missing configuration file "/shared/postgres_data/postgresql.auto.conf"
2021-06-06 16:38:40.461 UTC [116] FATAL:  data directory "/shared/postgres_data" has wrong ownership
2021-06-06 16:38:40.461 UTC [116] HINT:  The server must be started by the user that owns the data directory.

Das ist wahrscheinlich die Ursache des Problems. Wie kann ich das beheben?

3 „Gefällt mir“

Aus Neugier: Wer ist der Besitzer deines postgres_data-Verzeichnisses?

2 „Gefällt mir“

Hier ist es

root@forum:/var/discourse/shared/data# ls -al
total 32
drwxr-xr-x  8 root root   4096 Jun  6 16:56 .
drwxr-xr-x  4 root root   4096 Mar  3  2019 ..
drwxr-xr-x  3 root root   4096 Jul  8  2018 log
drwxr-xr-x  2 _apt netdev 4096 Jul  7  2018 postgres_backup
drwx------ 20 _apt netdev 4096 Jun  6 17:29 postgres_data
drwx------ 19 _apt netdev 4096 Jun  6 16:56 postgres_data_new
drwxrwsr-x  5 _apt netdev 4096 Jun  6 17:29 postgres_run
drwxr-xr-x  2 lxd  lxd    4096 Jun  6 17:34 redis_data

Ist das in Ordnung?

1 „Gefällt mir“

Für mein Setup (2 Container, PostgreSQL 13) ist die Gruppe für postgres_* render und nicht netdev, und die richtige Gruppe für postgres_run ist x, nicht setgid. Aber ich weiß nicht wirklich, was das impliziert :sweat_smile:

P.S. Und redis_data ist uuidd syslog …

2 „Gefällt mir“

Danke, ich weiß es auch nicht :slight_smile:
Ich hoffe, jemand kann helfen!

1 „Gefällt mir“

Könntest du bitte denselben Befehl mit ls -lan ausführen? Das hilft bei der Ermittlung der Eigentümer (-n wandelt den Benutzernamen in die UID und den Gruppennamen in die GID um). Hier ist ein Beispiel von meiner eigenen Site mit einem 2-Container-Setup:

[root@/var/discourse/shared/data]$ ls -lan
total 28
drwxr-xr-x.  7   0   0 4096 Jun  7 22:15 .
drwxr-xr-x.  5   0   0 4096 Jun  7 22:28 ..
drwxr-xr-x.  3   0   0 4096 Jun  7 22:15 log
drwxr-xr-x.  2 105 109 4096 Jun  7 22:15 postgres_backup
drwx------. 19 105 109 4096 Jun  7 22:27 postgres_data
drwxrwxr-x.  3 105 109 4096 Jun  7 22:27 postgres_run
drwxr-xr-x.  2 106 110 4096 Jun  8 00:17 redis_data
1 „Gefällt mir“

Sicher! Hier ist es:

root@forum:/var/discourse/shared/data# ls -lan
total 32
drwxr-xr-x  8   0   0 4096 Jun  6 16:56 .
drwxr-xr-x  4   0   0 4096 Mar  3  2019 ..
drwxr-xr-x  3   0   0 4096 Jul  8  2018 log
drwxr-xr-x  2 105 109 4096 Jul  7  2018 postgres_backup
drwx------ 20 105 109 4096 Jun  6 17:29 postgres_data
drwx------ 19 105 109 4096 Jun  6 16:56 postgres_data_new
drwxrwsr-x  5 105 109 4096 Jun  6 17:29 postgres_run
drwxr-xr-x  2 106 110 4096 Jun  9 14:10 redis_data

Hallo,

wir befinden uns in derselben Situation, allerdings in einer Standalone-Installation. Der Pfad shared/standalone/log/var-log/ zeigt keinerlei Dateien an, doch nach dem Betreten des Containers sehen wir identische Ergebnisse:

root@pulp-discourse-iptools:/var/www/discourse# tail -n 3 /var/log/postgres/current
2021-10-13 18:33:04.027 GMT [917] LOG:  skipping missing configuration file "/shared/postgres_data/postgresql.auto.conf"
2021-10-13 18:33:04.028 UTC [917] FATAL:  data directory "/shared/postgres_data" has wrong ownership
2021-10-13 18:33:04.028 UTC [917] HINT:  The server must be started by the user that owns the data directory.
root@pulp-discourse-iptools:/var/www/discourse# ls -lan /shared
total 8
drwxr-xr-x 12    0   0  178 Oct 13 18:01 .
drwxr-xr-x 56    0   0  167 May 10  2020 ..
drwxr-xr-x  3 1000  33   21 Apr  3  2019 backups
drwxr-xr-x  4    0   0   34 Apr  3  2019 log
drwxr-xr-x  2  106 110    6 Apr  3  2019 postgres_backup
drwx------ 20  105 109 4096 Oct 13 17:57 postgres_data
drwx------ 19  105 109 4096 Oct 13 18:02 postgres_data_new
drwxrwsr-x  4  105 109   60 Oct 13 17:56 postgres_run
drwxr-xr-x  2  108 111   41 Oct 13 18:26 redis_data
drwxr-xr-x  4    0   0   44 Apr  3  2019 state
drwxr-xr-x  4 1000  33   37 Oct 13 18:26 tmp
drwxr-xr-x  4 1000  33   38 Apr  3  2019 uploads

Dennoch wirkt das immer noch seltsam:

root@pulp-discourse-iptools:/var/www/discourse# ls -alF /shared | grep postgres_
drwxr-xr-x  2 postgres    postgres    6 Apr  3  2019 postgres_backup/
drwx------ 20 Debian-exim ssh      4096 Oct 13 18:53 postgres_data/
drwx------ 19 Debian-exim ssh      4096 Oct 13 18:02 postgres_data_new/
drwxrwsr-x  4 Debian-exim ssh        60 Oct 13 17:56 postgres_run/

Um auf der sicheren Seite zu sein, haben wir in app.yml wieder auf \"templates/postgres.10.template.yml\" umgestellt und streben derzeit nur an, die alte Instanz wieder hochzufahren.

Vielleicht ist es sinnvoll zu erwähnen, dass wir bereits auf dem neuesten Commit von https://github.com/discourse/discourse_docker.git sind, nachdem wir auf den main-Branch gewechselt sind. Da der Neuaufbau jedoch nicht erfolgreich war, hat dies beim Start des vorherigen Images wahrscheinlich keine Auswirkungen, oder?

Falls jemand eine Idee hat, wie wir diese Situation lösen können, wären wir Ihnen sehr dankbar. Andernfalls melden wir uns möglicherweise mit weiteren Berichten.

Mit freundlichen Grüßen,
Andreas.

Hallo nochmal,

Nach dem Rat von Update failed (postgresql) - #8 by noezDE von @noezDE (vielen Dank dafür!) konnten wir uns aus dieser Situation befreien.

Die Seite läuft nun wieder, und wir werden uns erneut um ein Upgrade kümmern.

Mit freundlichen Grüßen,
Andreas.


Wiederherstellungsprozedur

Zunächst wurde Fortschritt erzielt durch die Ausführung von:

chown -R postgres /shared/postgres_data
sv restart postgres

Danach hieß es in den Logs:

2021-10-13 18:52:12.437 UTC [3357] FATAL:  konnte keine Sperrdatei "/var/run/postgresql/.s.PGSQL.5432.lock" erstellen: Zugriff verweigert

Also sind wir ganz tief eingestiegen und haben ausgeführt:

chown -R postgres:postgres /shared/postgres_*
sv restart postgres

Und fertig.

5 „Gefällt mir“

Nochmal ein Versuch mit \"templates/postgres.template.yml\". Alles lief reibungslos, und das Upgrade von PostgreSQL 10 auf PostgreSQL 13 war erfolgreich. Nochmals vielen Dank an das gesamte Discourse-Team für die großartige Arbeit an dieser Software.

5 „Gefällt mir“