Problème avec la mise à niveau vers la dernière version

Bonjour, j’essaie de mettre à jour Discourse vers la dernière version.

ÉCHEC
--------------------
Pups::ExecError : /root/upgrade_postgres a échoué avec le statut de retour #<Process::Status: pid 45 exit 1>
Emplacement de l'échec : /pups/lib/pups/exec_command.rb:112:in `spawn'
exec a échoué avec les paramètres "/root/upgrade_postgres"
1cafe54cd6661316d8e9e393c54f73ab89bc3f5e70e104f6c5e4f8794053c09c
** ÉCHEC DU BOOTSTRAP ** veuillez défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.

Aussi

 Succès. Vous pouvez maintenant démarrer le serveur de base de données en utilisant :

    pg_ctlcluster 10 main start

Avertissement : Le répertoire stats_temp_directory sélectionné /var/run/postgresql/10-main.pg_stat_tmp
n'est pas accessible en écriture pour le propriétaire du cluster. Ce paramètre n'est pas ajouté dans
postgresql.conf.
Ver Cluster Port Statut Propriétaire Répertoire de données              Fichier journal
10  main    5433 arrêté postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
update-alternatives : avertissement : forcer la réinstallation de l'alternative /usr/share/postgresql/12/man/man1/postmaster.1.gz car le groupe de liens postmaster.1.gz est cassé
invoke-rc.d : impossible de déterminer le niveau d'exécution actuel
invoke-rc.d : policy-rc.d a refusé l'exécution du démarrage.
Traitement des déclencheurs pour postgresql-common (213.pgdg100+1) ...
Construction des dictionnaires PostgreSQL à partir des paquets myspell/hunspell installés...
Suppression des fichiers de dictionnaire obsolètes :
Arrêt du serveur de base de données PostgreSQL 10 : main.
Arrêt du serveur de base de données PostgreSQL 12 : main.
Exécution des vérifications de cohérence
-----------------------------
Vérification des versions des clusters                                   ok

Le cluster source n'a pas été arrêté proprement.
Échec, sortie

Sortie de la commande tail -f shared/standalone/log/var-log/postgres/current :

2020-06-14 01:37:02.155 UTC [3508] FATAL : le répertoire de données "/shared/postgres_data" a une propriété incorrecte
2020-06-14 01:37:02.155 UTC [3508] HINT : le serveur doit être démarré par l'utilisateur qui possède le répertoire de données.

Report de la mise à jour

Si vous devez reporter la mise à jour lors de votre prochaine reconstruction, vous pouvez remplacer le modèle PostgreSQL dans votre fichier app.yml en modifiant "templates/postgres.template.yml" par "templates/postgres.10.template.yml".

Ceci n’est pas recommandé, car certains administrateurs de site oublieront de rétablir le changement par la suite.

J’ai appliqué cela et le forum Discourse est maintenant en ligne. Que pouvons-nous faire ensuite ? Actuellement, j’utilise “templates/postgres.10.template.yml”.

Des idées ? J’utilise toujours « templates/postgres.10.template.yml ».

Essayez ce qui suit :

  1. Modifiez le fichier app.yml et remplacez "templates/postgres.10.template.yml" par "templates/postgres.template.yml".

  2. Arrêtez l’application : ./launcher stop app

  3. Lancez une reconstruction : ./launcher rebuild app

2 « J'aime »

Mise à jour terminée

Les statistiques de l’optimiseur ne sont pas transférées par pg_upgrade, donc, une fois que vous démarrez le nouveau serveur, envisagez d’exécuter :
./analyze_new_cluster.sh

L’exécution de ce script supprimera les fichiers de données de l’ancien cluster :
./delete_old_cluster.sh

MISE À JOUR DE POSTGRES TERMINÉE

L’ancienne base de données 10 est stockée dans /shared/postgres_data_old

Pour terminer la mise à jour, reconstruisez à nouveau en utilisant :

./launcher rebuild app

Et le forum Discourse est hors ligne pour le moment.

J’essaie à nouveau ./launcher rebuild app comme indiqué ci-dessus.

Oui, c’est normal.

Oui, suivez les instructions et cela devrait être de nouveau opérationnel bientôt.

1 « J'aime »

C’est intéressant et génial, la mise à jour est maintenant terminée avec succès. J’ai essayé la même méthode à de nombreuses reprises auparavant, mais cela n’a jamais fonctionné.

Dois-je utiliser les commandes suivantes pour libérer de l’espace ?

Les statistiques d'optimiseur ne sont pas transférées par pg_upgrade, donc,
une fois le nouveau serveur démarré, envisagez d'exécuter :
    ./analyze_new_cluster.sh

L'exécution de ce script supprimera les fichiers de données de l'ancien cluster :
    ./delete_old_cluster.sh

Merci !

Vous pouvez exécuter les tâches optionnelles de mise à jour des publications répertoriées dans notre FAQ.

1 « J'aime »

Magnifique. Merci encore !

1 « J'aime »

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.