Le tableau de bord de Literate Computing a mis à niveau avec succès deux sites autonomes et un site à deux conteneurs sans incident. Dans la plupart des cas, il a suffi de modifier la version cible de Postgres dans une variable, donc, comme annoncé, le processus est le même que pour les dernières mises à niveau.
C’est en réalité assez bien supporté, et bien plus sûr que la mise à niveau majeure d’une base de données. Si quelque chose tourne mal, vous ne basculez tout simplement pas vers le nouveau serveur. Si vous êtes proche d’avoir besoin d’une mise à niveau du système d’exploitation et/ou souhaitez un temps d’arrêt minimal, c’est une bonne approche. Vous avez un accès en lecture seule pendant que vous construisez le nouveau serveur, puis vous basculez dessus. La méthode simple implique un temps d’arrêt pour la reconstruction finale, ou zéro temps d’arrêt si vous copiez les certificats depuis l’ancien serveur.
Si tout se passe mal lors d’une mise à niveau de la base de données, construire un nouveau serveur et restaurer la sauvegarde est la solution la plus simple.
Assurez-vous de faire une sauvegarde avant de commencer. Je fais une sauvegarde de la base de données uniquement, car vous ne perdrez pas vos téléchargements.
Juste pour confirmer, je n’utilise pas PostgreSQL fourni par Discourse et Discourse lui-même ne nécessite pas encore PG18, n’est-ce pas ? Donc je ne suis pas (encore) tenu de passer à PG18.
Bonne remarque. Mais l’autre point est que les versions LTS sortent tous les deux ans, donc ce n’est pas une mauvaise idée de le faire en même temps.
Vous avez encore tout votre temps. Ils ont poussé pour… euh, une sortie assez rapidement après la mise à jour à cause d’une fonctionnalité requise, mais vous pouvez probablement attendre jusqu’à un an. Je surveille le dépôt discourse_docker. À un moment donné, ils commenceront à parler de la suppression du support pour PG15 ; ce n’est pas particulièrement bruyant et c’est un moyen simple de rester au courant des mises à jour des composants internes.
Cela pourrait encourager d’autres à nous suivre dans nos pas intrépides plus rapidement.
Mon IA de recherche web gratuite me dit :
Pour une application Rails typique, passer de PostgreSQL 15 à 18 peut offrir ~10–25 % de performances de requête plus rapides sans modification du code, et jusqu’à 40 % pour certains modèles de requêtes si vous exploitez les nouvelles fonctionnalités d’indexation et de planification.
Si c’est vrai, c’est une mise à niveau assez impressionnante !
C’est vrai, mais nous visons un mécanisme de mise à jour simple et transparent. Il y a des avantages des deux côtés.
Je dirais que vous devez faire ce qui vous semble le plus confortable et ne pas avoir peur de personnaliser les modèles dans discourse_docker selon vos besoins. Évidemment, la clé est de tester en premier et d’avoir un plan de retour en arrière.
Sur notre plateforme hébergée, nous avons l’intention de faire plus de tests et de benchmarks avant de les activer, et donc je les ai désactivés dans discourse_docker également pour aligner la configuration. Ce n’est pas strictement nécessaire de les désactiver (nous n’utilisons que la partie conteneur web de discourse_docker en interne) et je ne serais pas contre les activer.
Un piège potentiel est que pg_upgrade ne fonctionnera pas si les anciens et nouveaux répertoires de données ont des paramètres de sommes de contrôle différents. Le processus consisterait à arrêter le serveur PG15, exécuter pg_upgrade pour le convertir en PG18 sans sommes de contrôle, exécuter pg_checksums pour activer les sommes de contrôle, puis démarrer PG18. Ce n’est pas un problème lors d’une sauvegarde et restauration (comme avec cette mise à niveau), mais c’est quelque chose à surveiller.
Notez que les sommes de contrôle de données sont disponibles depuis Postgres 9.3 mais ont été désactivées par défaut jusqu’à présent. Postgres 19 inclura également la possibilité de les activer/désactiver en ligne.
Pas à ce stade, non. La plupart des fonctionnalités de Discourse utilisent l’adaptateur PostgreSQL de Rails pour communiquer avec la base de données, mais la sauvegarde/restoration utilise pg_dump et psql dans le conteneur web. Pour l’instant, nous installons les clients PG15 et PG18 pour permettre la sauvegarde/restoration avec ces deux versions, mais à un moment donné dans le futur, nous supprimerons PG15.
Le facteur déterminant était le passage au nouveau fournisseur de locales intégré. Nous travaillons vers une mise à niveau du système d’exploitation sur notre plateforme hébergée et voulons briser le couplage avec glibc.
