Ubuntu 16
Clicé sur la mise à jour Web comme nous l’avons fait plusieurs fois. Échoué, maintenant l’application ne peut pas reconstruire une version de Docker non supportée.
Des idées ? Je pourrais essayer de mettre à jour l’OS, etc., mais ce serait beaucoup de temps que je n’avais pas aujourd’hui.
Y a-t-il un moyen de revenir en arrière ?
J’ai essayé de définir la version sur l’ancien hash, mais je reçois immédiatement la message de version de Docker non supportée lorsque j’essaie de reconstruire.
Je déplacerais vers une nouvelle machine virtuelle (VM) et restaurerais la base de données là-bas. C’est plus facile, avec peu de temps d’arrêt, et si quelque chose ne va pas, vous continuez simplement à utiliser le serveur fonctionnel.
J’ai effectué la mise à niveau du système d’exploitation, etc., et cela s’est déroulé après la mise à niveau de PostgreSQL 15, mais maintenant lorsque je reconstruis l’application, je reçois
2025-05-18 14:58:28.208 UTC [1455] discourse@discourse ERROR: la colonne "require_message" n'existe pas à la position 72
2025-05-18 14:58:28.208 UTC [1455] discourse@discourse STATEMENT: SELECT id, name, name_key, description, notify_type, auto_action_type, require_message, applies_to, position, enabled, score_type FROM "flags" ORDER BY "flags"."position" ASC
** ÉCHEC DU PLUG-IN **
Vous ne pouvez pas démarrer Discourse à cause de cette erreur lors de l'initialisation du plug-in :
PG::UndefinedColumn: ERROR: la colonne "require_message" n'existe pas
LINE 1: ..._key, description, notify_type, auto_action_type, require_me...
^
Après avoir lancé la reconstruction (après la mise à niveau de PostgreSQL)
Mise à niveau en cours
------------------
Analyse de toutes les lignes dans le nouveau cluster ok
Gel de toutes les lignes dans le nouveau cluster ok
Suppression des fichiers du nouveau pg_xact ok
Copie de l'ancien pg_xact vers le nouveau serveur ok
Configuration de l'XID le plus ancien pour le nouveau cluster ok
Configuration du prochain ID de transaction et de l'époque pour le nouveau cluster ok
Suppression des fichiers du nouveau pg_multixact/offsets ok
Copie de l'ancien pg_multixact/offsets vers le nouveau serveur ok
Suppression des fichiers du nouveau pg_multixact/members ok
Copie de l'ancien pg_multixact/members vers le nouveau serveur ok
Configuration du prochain ID multixact et de l'offset pour le nouveau cluster ok
Réinitialisation des archives WAL ok
Configuration des counters frozenxid et minmxid dans le nouveau cluster ok
Restauration des objets globaux dans le nouveau cluster ok
Restauration des schémas de la base de données dans le nouveau cluster ok
Copie des fichiers de relation utilisateur ok
Configuration du prochain OID pour le nouveau cluster ok
Synchronisation des données sur le disque ok
Création du script pour supprimer l'ancien cluster ok
Vérification des mises à jour des extensions notice
Votre installation contient des extensions qui devraient être mises à jour
avec la commande ALTER EXTENSION. Le fichier
update_extensions.sql
lorsqu'il est exécuté par psql avec le superutilisateur de la base de données permettra de mettre à jour
ces extensions.
Mise à niveau terminée
----------------
Les statistiques de l'optimiseur ne sont pas transférées par pg_upgrade.
Une fois que vous démarrez le nouveau serveur, envisagez d'exécuter :
/usr/lib/postgresql/15/bin/vacuumdb --all --analyze-in-stages
L'exécution de ce script supprimera les fichiers de données de l'ancien cluster :
./delete_old_cluster.sh
-------------------------------------------------------------------------------------
MISE À NIVEAU DE POSTGRES TERMINÉE
L'ancienne base de données 13 est stockée à /shared/postgres_data_old
Pour terminer la mise à niveau, reconstruisez à nouveau en utilisant :
./launcher rebuild app
Que puis-je faire ? Je ne suis pas sûr de comment il manque une colonne.
Je ne suis pas sûr de comment faire cela, plus précisément à quelle table, etc. Y a-t-il des informations à ce sujet que je peux trouver ? J’ai trouvé ce post que vous mentionnez, mais il n’y avait pas de détails spécifiques.
Je ne peux même pas monter la base de données suffisamment pour ajouter la colonne. Je vais essayer de désactiver tous les plugins pour voir si je peux au moins faire démarrer le conteneur.
Voici comment nous avons résolu le problème (ce n’est pas pour les âmes sensibles)
Mettre à niveau Ubuntu vers une version qui prend en charge Docker 20+
Nous étions sous Ubuntu 16, j’ai dû passer à au moins Ubuntu 20, nous avons donc effectué cette mise à niveau deux fois
Une fois la base de données mise à niveau avec succès, exécutez
./launcher rebuild app
Cela a généré une erreur concernant une colonne manquante
2025-05-18 14:58:28.208 UTC [1455] discourse@discourse ERROR: column "require_message" does not exist at character 72
2025-05-18 14:58:28.208 UTC [1455] discourse@discourse STATEMENT: SELECT id, name, name_key, description, notify_type, auto_action_type, require_message, applies_to, position, enabled, score_type FROM "flags" ORDER BY "flags"."position" ASC
** PLUGIN FAILURE **
Vous ne pouvez pas démarrer Discourse en raison de cette erreur lors de l'initialisation du plugin :
PG::UndefinedColumn: ERROR: column "require_message" does not exist
LINE 1: ..._key, description, notify_type, auto_action_type, require_me...
^
À ce stade, il n’y a aucun moyen de démarrer le conteneur, j’ai donc modifié app.yml pour désactiver tous les plugins, puis j’ai relancé la reconstruction.
L’application a finalement été reconstruite, puis j’ai pu accéder à la console Rails pour ajouter manuellement la colonne ci-dessus.
./launcher enter app
rails db
ActiveRecord::Base.connection.execute("ALTER TABLE flags ADD COLUMN require_message BOOLEAN DEFAULT FALSE;")
exit
exit
Une fois la colonne présente, je suis retourné dans app.yml, j’ai réactivé tous les plugins et j’ai relancé la reconstruction.
La reconstruction a réussi… et nous sommes en ligne !
Merci @pfaffman pour votre réponse rapide, même un week-end. Nous allons créer un nouveau droplet mis à jour et migrer. Il était censé s’agir d’une mise à niveau rapide sur place depuis l’interface web. Mais je suppose que le script ne teste pas la compatibilité de Docker. Lorsqu’il a mis à jour Docker pour Discourse, il a ensuite généré une erreur de Docker incompatible.
C’était entièrement de notre faute de rester sur une version aussi ancienne d’Ubuntu 16. L’une des bonnes et des mauvaises choses d’un système stable est qu’il a tendance à perdurer.