Vous n'êtes pas identifié(e).
Bonjour,
Je suis en train d'upgrader de Postgres 9.6 vers Postgres 13.4.
J'ai bien lancé l'étape init_db, mais j'ai une erreur "No such file or directory" lors de la phase pg_upgrade :
[postgres_artifactory@sxxxxxxxxxx bin]$ /usr/pgsql-13/bin/pg_upgrade -v -b /usr/pgsql-9.6/bin -B /usr/pgsql-13/bin -d /applis/24140-tdgg/artifactory/postgres/data/9.6/db -D /applis/24140-tdgg/artifactory/postgres/data/13.4/db
bash: /usr/pgsql-13/bin/pg_upgrade -v -b /usr/pgsql-9.6/bin -B /usr/pgsql-13/bin -d /applis/24140-tdgg/artifactory/postgres/data/9.6/db -D /applis/24140-tdgg/artifactory/postgres/data/13.4/db: No such file or directoryC'est étrange car tous les répertoires utilisés en valeur des options existent bien :
/usr/pgsql-9.6/bin
/usr/pgsql-13/bin
/applis/24140-tdgg/artifactory/postgres/data/9.6/db
/applis/24140-tdgg/artifactory/postgres/data/13.4/db
Auriez-vous une idée SVP ?
Si vous avez des questions/remarques, n'hésitez pas.
Merci d'avance.
Cdt.
Hors ligne
Bonjour,
Etes-vous sûr que le binaire /usr/pgsql-13/bin/pg_upgrade existe, ou pointe vers un fichier existant ?
Julien.
https://rjuju.github.io/
Hors ligne
Le message d'erreur me donne plutôt l'impression qu'il prend la ligne complète comme la commande. N'auriez vous pas fait un copier/coller d'un document Word ou PDF ? Avez-vous tapé la commande vous même ou est-ce un copier/coller ?
Guillaume.
Hors ligne
Bonjour,
@rjuju : Oui, j'ai vérifié l'existence des fichiers/répertoires
@gleu : En effet, c'est un soucis de copier-coller. Le bash ne doit pas être top, j'ai fait un CC à partir de la commande de l'history bash et il y a du y avoir des caractères mal traduits.
Je viens de relancer la commande, ça a avancé mais j'ai cette erreur maintenant :
[postgres_artifactory@sxxxxxxxxxx ~]$ /usr/pgsql-13/bin/pg_upgrade -v -b /usr/pgsql-9.6/bin -B /usr/pgsql-13/bin -d /applis/24140-tdgg/artifactory/postgres/data/9.6/db -D /applis/24140-tdgg/artifactory/postgres/data/13.4/db
...
executing: SELECT pg_catalog.set_config('search_path', '', false);
Checking database user is the install user executing: SELECT rolsuper, oid FROM pg_catalog.pg_roles WHERE rolname = current_user AND rolname !~ '^pg_'
database user "postgres_artifactory" is not the install user
Failure, exiting
"/usr/pgsql-9.6/bin/pg_ctl" -w -D "/applis/24140-tdgg/artifactory/postgres/data/9.6/db" -o "" -m fast stop >> "pg_upgrade_server.log" 2>&1Pourtant, j'ai bien fait l'initdb du cluster d'origine version 9.6 et du cluster cible 13.4 avec le user postgres_artifactory.
Merci d'avance.
Cdt.
Dernière modification par Imagin0s (17/11/2021 10:40:06)
Hors ligne
Il y a bien un rôle postgres_artifactory de créer sur les deux instances ?
Guillaume.
Hors ligne
J'ai démarré le service de postgres 9.6 pour me connecter à la DB et lister les rôles et j'ai ce résultat :
[postgres_artifactory@xxxxxxxxxxx ~]$ psql -d postgres
psql (13.4, server 9.6.11)
Type "help" for help.
postgres=# \du
List of roles
Role name | Attributes | Member of
----------------------------------+------------------------------------------------------------+-----------
admin_pgsql | Create role, Create DB | {}
artifactory | | {}
artifactory_tower | | {}
cbe5b6d305d0d2393a438cb6d8efb534 | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
postgres_artifactory | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
replication | Replication | {}
xray | | {}J'ai également démarré le service de postgres 13.4 mais lorsque j'essaie de me connecter à la DB j'ai cette erreur :
root@xxxxxxxxxxx:/etc/systemd/system$ psql -d postgres
psql: error: FATAL: role "root" does not existJe n'ai rien créée en terme de rôle sur la nouvelle instance en 13.4, juste lancé un initdb. Etant donné que l'ancienne instance a été créée avec un user non standard "postgres_artifactory", voulez-vous dire qu'il faut que je créée également ce rôle dans la nouvelle instance avant de lancer le pg_upgrade ?
Comment puis-je le faire ?
Merci d'avance.
Cdt.
Hors ligne
Tout dépend de comment vous avez fait l'installation (plus exactement l'initdb). Si je devais deviner, je dirais qu'il vous manque juste un "-U postgres" pour pg_upgrade, mais c'est vraiment de la devinette, faute d'informations suffisantes.
Guillaume.
Hors ligne
Voici la commande qui a été lancée pour initier la DB postgres en 9.6 :
su - postgres_artifactory
/usr/pgsql-9.6/bin/initdb --pgdata=/applis/24140-tdgg/artifactory/postgres/data/9.6/db --xlogdir=/applis/24140-tdgg/artifactory/postgres/backup/9.6/current_xlog -E 'UTF-8' --lc-collate='en_GB.UTF-8' --lc-ctype='en_GB.UTF-8' -U postgres_artifactory -WJ'ai essayé de refaire le pg_upgrade en ajoutant -U postgres :
/usr/pgsql-13/bin/pg_upgrade -v -b /usr/pgsql-9.6/bin -B /usr/pgsql-13/bin -d /applis/24140-tdgg/artifactory/postgres/data/9.6/db -D /applis/24140-tdgg/artifactory/postgres/data/13.4/db -U postgres
mais nous avons la même erreur :
...
database user "postgres" is not the install user
Failure, exiting
"/usr/pgsql-9.6/bin/pg_ctl" -w -D "/applis/24140-tdgg/artifactory/postgres/data/9.6/db" -o "" -m fast stop >> "pg_upgrade_server.log" 2>&1Hors ligne
Après quelques recherches, j'ai trouvé un sujet sur un autre forum qui indique que l'install user est celui avec un OID de 10 (cf. https://issueexplorer.com/issue/zalando/spilo/602)
En listant l'ensemble de mes rôles sur le base postgres 9.6 d'origine, j'obtiens ceci :
postgres=# SELECT * FROM pg_roles;
rolname | rolsuper | rolinherit | rolcreaterole | rolcreatedb | rolcanlogin | rolreplication | rolconnlimit | rolpassword | rolvaliduntil | rolbypassrls | rolconfig | oid
----------------------------------+----------+------------+---------------+-------------+-------------+----------------+--------------+-------------+---------------+--------------+-----------+-------
pg_signal_backend | f | t | f | f | f | f | -1 | ******** | | f | | 4200
cbe5b6d305d0d2393a438cb6d8efb534 | t | t | t | t | t | t | -1 | ******** | | t | | 10
postgres_artifactory | t | t | t | t | t | t | -1 | ******** | | t | | 16385
replication | f | t | f | f | t | t | -1 | ******** | | f | | 16384
artifactory | f | t | f | f | t | f | -1 | ******** | | f | | 16387
admin_pgsql | f | t | t | t | t | f | -1 | ******** | | f | | 16386
postgres | t | t | t | t | t | t | -1 | ******** | | t | | 16388
xray | f | t | f | f | t | f | -1 | ******** | | f | | 24629
artifactory_tower | f | t | f | f | t | f | -1 | ******** | | f | | 36418
(9 rows)Le 2ème rôle " cbe5b6d305d0d2393a438cb6d8efb534" a l'OID 10. Je me demande s'il faut le renommer en postgres_artifactory (si c'est possible d'avoir un doublon) ou bien attribuer l'OID 10 à mon userpostgres_artifactory.
Aurez-vous une suggestion ? J'aimerai éviter de tout casser.
Cdt.
Dernière modification par Imagin0s (17/11/2021 14:43:31)
Hors ligne
Il n'est pas possible d'avoir deux rôles de même nom. Ce nom (cbe5b6d305d0d2393a438cb6d8efb534) est très étonnant. Vous ne pourrez pas le supprimer car il s'agit du rôle d'install. Je ne vois que deux solutions :
1. renommer postgres_artifactory en n'importe quoi (postgres_artifactory_old par exemple), puis renommer cbe5b6d305d0d2393a438cb6d8efb534 en postgres_artifactory (si c'est possible)
2. créer la nouvelle instance avec cbe5b6d305d0d2393a438cb6d8efb534 comme nom d'install et faire le pg_upgrade avec un "-U cbe5b6d305d0d2393a438cb6d8efb534"
Guillaume.
Hors ligne
Bonjour @gleu,
Oui, j'ai résolu ce soucis en utilisant la méthode 1. en tant que user postgres (car pas possible de renommer le user de la session active)
Pour info, suite à 5/6 problèmes à résoudre en utilisant la méthode pg_upgrade, j'ai laissé tomber et je me suis dirigé vers la méthode "18.6.1. Upgrading Data via pg_dumpall"
Ca a l'air de mieux marcher.
Par contre, je n'ai pas l'étape "Post-upgrade processing" (cf. cette doc : https://www.postgresql.org/docs/13/pgupgrade.html) qui me semble utile.
Cette étape a-t-elle une utilité ds notre cas présent ?
Merci d'avance.
Cordialement.
Hors ligne
La méthode pg_dumpall est beaucoup simple que la méthode pg_upgrade. Elle est sûre de fonctionner. Par contre, elle est aussi sûrement plus lente.
Comme ce sont deux méthodes très différentes, il n'est pas étonnant que les étapes ne soient pas identiques. ET donc l'étape "Post-upgrade processing" n'existe pas pour pg_dumpall.
Guillaume.
Hors ligne