Vous n'êtes pas identifié(e).
Bonjour,
Samedi dernier nous avons upgradé un de nos Postgres de prod en v13 (VM sur Linux 7.9) avec l'option --link de pg_upgrade mais après cela nous avons remarqué que les liens du répertoire de la db applicative pointent toujours sur le répertoire de la v11.
Commande éxecutée sans erreur :
time /usr/pgsql-13/bin/pg_upgrade --link --old-datadir=/opt/postgres/bsi/11 --new-datadir=/opt/postgres/bsi/13 --old-bindir=/usr/pgsql-11/bin --new-bindir=/usr/pgsql-13/binVoici le "du -h" des 2 répertoires et nous remarquons que le répertoire de la db "/11/base/16792" avec 990GB pointe toujours sur la v11
0 ./11/pg_serial
1.6M ./11/pg_stat_tmp
1.1G ./11/log
0 ./11/pg_wal/archive_status
2.1G ./11/pg_wal
0 ./11/pg_tblspc
7.9M ./11/base/1
13M ./11/base/13881
990G ./11/base/16792
7.7M ./11/base/13880
0 ./11/base/pgsql_tmp
990G ./11/base
0 ./11/pg_replslot
8.0K ./11/pg_notify
0 ./11/pg_dynshmem
14M ./11/pg_stat
0 ./11/pg_twophase
0 ./11/pg_snapshots
0 ./11/pg_logical/snapshots
0 ./11/pg_logical/mappings
4.0K ./11/pg_logical
0 ./11/pg_commit_ts
8.0K ./11/pg_multixact/offsets
8.0K ./11/pg_multixact/members
16K ./11/pg_multixact
48M ./11/pg_xact
184K ./11/pg_subtrans
30M ./11/global
994G ./11
0 ./tablespaces/bsi_data/PG_11_201809051
0 ./tablespaces/bsi_data/PG_13_202007201
0 ./tablespaces/bsi_data
0 ./tablespaces/bsi_document/PG_11_201809051
0 ./tablespaces/bsi_document/PG_13_202007201
0 ./tablespaces/bsi_document
0 ./tablespaces/bsi_staging/PG_11_201809051
0 ./tablespaces/bsi_staging/PG_13_202007201
0 ./tablespaces/bsi_staging
0 ./tablespaces/bsi_email/PG_11_201809051
0 ./tablespaces/bsi_email/PG_13_202007201
0 ./tablespaces/bsi_email
0 ./tablespaces
0 ./13/pg_wal/archive_status
4.3G ./13/pg_wal
22M ./13/global
0 ./13/pg_commit_ts
0 ./13/pg_dynshmem
0 ./13/pg_notify
0 ./13/pg_serial
0 ./13/pg_snapshots
6.6M ./13/pg_subtrans
0 ./13/pg_twophase
8.0K ./13/pg_multixact/offsets
8.0K ./13/pg_multixact/members
16K ./13/pg_multixact
8.0M ./13/base/14173
8.2M ./13/base/16404
44G ./13/base/16405
94M ./13/base/200946
0 ./13/base/pgsql_tmp
44G ./13/base
0 ./13/pg_replslot
0 ./13/pg_tblspc
0 ./13/pg_stat
32M ./13/pg_stat_tmp
0 ./13/pg_logical/snapshots
0 ./13/pg_logical/mappings
4.0K ./13/pg_logical
82M ./13/log
48M ./13/pg_xact
48G ./13
1.1T .Comment pouvons-nous corriger cette situation ?
Merci d'avance pour vos réponses et bonne journée
Daniel
Hors ligne
C'est le principe d'un hard link et la raison pourquoi c'est si rapide: les fichiers aux 2 emplacements pointent vers les même données. Comme indiqué dans la documentation, vous pouvez supprimer le répertoire source une fois l'opération terminée avec succès, et potentiellement après toute autre vérification. La volumétrie sera alors correctement reportée.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
de plus pg_upgrade vous indique 2 scripts (ou 3 selon les cas) à exécuter en fin de migration. Dont un, de mémoire, qui vous propose de supprimer l'ancienne instance migrée.
L'avez-vous fait ?
Cordialement,
Sébastien.
Hors ligne
Merci pour vos réponses.
Si je lance le script "delete_old_cluster.sh" qui effectue simplement un "rm -rf '/opt/postgres/bsi/11'" la db aura des problèmes car certains fichiers de l'ancien répertoire V11 sont toujours touchés.
Par exemple :
-rw-------. 2 postgres postgres 17358848 Mar 8 09:15 21823741
-rw-------. 2 postgres postgres 706199552 Mar 8 09:15 17401164Hors ligne
Merci pour vos réponses.
Si je lance le script "delete_old_cluster.sh" qui effectue simplement un "rm -rf '/opt/postgres/bsi/11'" la db aura des problèmes car certains fichiers de l'ancien répertoire V11 sont toujours touchés.
Par exemple :-rw-------. 2 postgres postgres 17358848 Mar 8 09:15 21823741 -rw-------. 2 postgres postgres 706199552 Mar 8 09:15 17401164
tiens... ce n'est pas normal ça...
vous êtes sûr ?
Pas de message d'erreur du tout lors du pg_upgrade ?
Je ne comprends pas, ce ne devrait vraiment pas être le cas.
Dernière modification par ruizsebastien (08/03/2022 10:25:58)
Cordialement,
Sébastien.
Hors ligne
Non, pas eu de message d'erreur. c'est très curieux.
Voici les derniers accès à la db dans le répertoire v11 :
...
-rw-------. 2 postgres postgres 668590080 Mar 8 09:57 19729529
-rw-------. 2 postgres postgres 164839424 Mar 8 09:57 38464246
-rw-------. 2 postgres postgres 13008896 Mar 8 09:57 38464252et dans le répertoire V13 :
...
-rw-------. 2 postgres postgres 165543936 Mar 8 09:57 8472048
-rw-------. 2 postgres postgres 21913600 Mar 8 09:57 9495352
-rw-------. 2 postgres postgres 13066240 Mar 8 09:57 8472076Hors ligne
L'instance en v11 est bien éteinte ?
Julien.
https://rjuju.github.io/
Hors ligne
si je ne me trompe pas, s'agissant de hard link, si vous supprimez les fichiers v11, les v13 seront préservés.
Normalement...
Peut être pouvez-vous tenter votre chance en ayant fait une sauvegarde complète et cohérente de l'instance v13 au préalable.
Cordialement,
Sébastien.
Hors ligne
oui elle est éteinte, seul l'instance 13 est startée :
postgres 58310 1 0 Mar05 ? 00:34:09 /usr/pgsql-13/bin/postmaster -D /opt/postgres/bsi/13
postgres 58314 58310 0 Mar05 ? 00:00:00 postgres: logger
postgres 58316 58310 0 Mar05 ? 00:36:40 postgres: checkpointer
postgres 58317 58310 0 Mar05 ? 00:02:10 postgres: background writer
postgres 58318 58310 0 Mar05 ? 00:04:57 postgres: walwriter
postgres 58319 58310 0 Mar05 ? 00:00:06 postgres: autovacuum launcher
postgres 58320 58310 0 Mar05 ? 00:00:09 postgres: archiver last was 0000000100002C190000000F
postgres 58321 58310 12 Mar05 ? 09:07:34 postgres: stats collector
postgres 58322 58310 0 Mar05 ? 00:00:00 postgres: logical replication launcherHors ligne
de plus "delete_old_cluster.sh" est sans danger si pg_upgrade s'est terminé avec succès et sans erreur.
Cordialement,
Sébastien.
Hors ligne
Merci pour vos réponses.
Si je lance le script "delete_old_cluster.sh" qui effectue simplement un "rm -rf '/opt/postgres/bsi/11'" la db aura des problèmes car certains fichiers de l'ancien répertoire V11 sont toujours touchés.
Par exemple :-rw-------. 2 postgres postgres 17358848 Mar 8 09:15 21823741 -rw-------. 2 postgres postgres 706199552 Mar 8 09:15 17401164
Si la v13 écrit dans ces fichiers il est normal que la date de dernière modification change en regardant dans le répertoire de la v11.
Ces fichiers pointant sur le même inode, ils ont les mêmes données et aussi les mêmes métadonnées à part le nom.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Tout à fait, mais de ce que je comprends du message les meta données sont différentes d'un répertoire à l'autre. À priori la seule manière d'arriver à ça serait d'avoir un changement de relfilenode avec l'ancienne instance encore démarrée.
Julien.
https://rjuju.github.io/
Hors ligne
Je ne vois pas ce qui te fait dire que les métadonnées sont différentes. Pour moi, je ne vois rien dans les différents commentaires qui montreraient un problème. En ayant démarré la v13, les fichiers sont touchés, c'est normal. C'est d'ailleurs pour ça que, à partir du moment où on fait un pg_upgrade en mode link et qu'on démarre la nouvelle version, il n'est plus possible de revenir en arrière et d'utiliser l'ancienne version. Pour moi, dans tout ce que j'ai lu, je ne vois rien d'anormal.
Guillaume.
Hors ligne
Bonjour,
Merci pour vos réponses. Je peux maintenant supprimer l'ancien PGDATA de la v11 sans soucis.
Merci encore pour le support et bonne journée
Daniel
Hors ligne