Nous utilisons PostgreSQL v12 car la mise à niveau vers v13 nécessite trop d’espace disque. Il semble que la compatibilité avec v12 ait pu être rompue ? Est-ce intentionnel ? Si c’est le cas, cela signifie que nous ne pourrons jamais mettre à jour Discourse à nouveau.
L’exécution de ./launcher start app nous a remis en ligne, donc ce n’est pas un problème de production pour l’instant, mais l’impossibilité de procéder à une mise à jour, même pour des raisons de sécurité, serait très problématique pour nous.
Dans app.yml :
- "templates/postgres.12.template.yml"
Résultat de ./launcher rebuild app :
ÉCHEC
--------------------
Errno::ENOENT : Aucun fichier ou répertoire de ce type @ rb_sysopen - /etc/postgresql/13/main/pg_hba.conf
Emplacement de l'échec : /pups/lib/pups/replace_command.rb:8:in `read'
La commande de remplacement a échoué avec les paramètres {"filename" => "/etc/postgresql/13/main/pg_hba.conf", "from" => "/^host.*all.*all.*::1\\128.*$/", "to" => "host all all ::/0 md5"}
0ba8112e6efa1ac2dd75af8a1da8eea0937e7aefbca2df28b22d27e9608d1479
** ÉCHEC DU BOOTSTRAP ** Veuillez remonter et rechercher les messages d'erreur antérieurs, il peut y en avoir plusieurs.
./discourse-doctor peut aider à diagnostiquer le problème.
Version actuellement en cours d’exécution : 2.8.0.beta4 75b0d6df93.
Pourquoi ne pas faire une sauvegarde, créer une instance Discourse complètement nouvelle (qui devrait utiliser Postgres 13 par défaut), restaurer la sauvegarde et mettre à jour l’enregistrement DNS du serveur ?
C’est moins effrayant que des tâches pénibles que j’aimerais éviter, combiné à devoir annoncer à mon forum qu’ils vont perdre un ou deux jours de publications. J’aimerais idéalement que l’équipe de Discourse réponde : « Bien sûr, nous travaillons toujours sur PG12, ce n’est qu’un bug, nous allons le corriger ».
Ah, je vois, c’est un bug introduit par une PR de la communauté. Comme nous n’utilisons pas PG12 nulle part, cela est passé inaperçu. Accordez-moi quelques minutes.
Pourriez-vous essayer de reconstruire à nouveau, @Wingtip ?
Cela dit, nous n’exécutons plus PG12, nous pourrions donc introduire à tout moment dans le cœur du système une syntaxe SQL exclusive à PG13+. Il serait donc judicieux de planifier la mise à niveau un jour.
Je vais jeter un coup d’œil juste après avoir pris un autre snapshot de ma VM.
C’est vraiment énervant que PG nécessite autant d’espace disque pour une mise à niveau. Je n’ai pas ce problème avec Oracle ou MySQL, qui se mettent à niveau directement sur place.
pg_upgrade offre un seul drapeau --link permettant des mises à jour sur place.
Nous avons choisi de ne pas l’utiliser dans notre script de mise à niveau « convivial pour les débutants », car 99 % des installations s’exécutent sur une machine virtuelle cloud où il est facile et peu coûteux d’augmenter la taille du disque.
Cependant, cette option reste disponible pour ceux qui préfèrent effectuer la mise à niveau manuellement afin d’économiser de l’espace disque pendant le processus.
Deux solutions ont été proposées ; si ma mémoire est bonne, l’une nécessitait environ trois fois la taille totale de la base de données et l’autre environ deux fois. Si cela peut être fait in situ, documenter cette possibilité serait très utile.
