Laissez Discourse gérer la mise à niveau. Cela nécessite trois fois l’espace disque actuel. Ainsi, si votre base de données fait 100 Go, vous auriez besoin de 200 Go libres supplémentaires pour effectuer la mise à niveau. Évidemment, cela pose un énorme problème pour les installations de grande taille.
Suivez leur procédure de « mise à niveau manuelle ». Cela nécessite deux fois l’espace disque actuel, donc si votre base de données fait 100 Go, vous auriez besoin de 100 Go libres supplémentaires. Cela représente également un gros problème pour certains.
Dans ce post, @Falco a suggéré d’utiliser l’option --link pour effectuer la mise à niveau sur place en utilisant des liens physiques. Le conteneur Docker qu’ils suggèrent d’utiliser prend en charge cet argument, mais les développeurs de Discourse ne le recommandent pas dans le post.
Ma question est donc la suivante : l’option 3 devrait-elle être :
Exécuter la commande ci-dessous, qui nécessitera une très petite quantité d’espace disque supplémentaire. Ainsi, si votre base de données fait 100 Go, cela pourrait nécessiter, par exemple, 10 Go supplémentaires ? Si c’est le cas, est-ce une procédure recommandée par les développeurs de Discourse, et quelqu’un l’a-t-il déjà faite avec succès ?
Nouvelle commande pour une mise à niveau sur place :
docker run --rm \
-v DIR:/var/discourse/shared/standalone/postgres_data:/var/lib/postgresql \
tianon/postgres-upgrade:12-to-13 \
--link
Par rapport à l’ancienne commande pour une mise à niveau vers un nouveau répertoire (nécessitant le double de l’espace) :
P.S. : J’aurais simplement répondu à ce fil de discussion sur la mise à niveau vers PG13, mais il supprime les messages après 7 jours. Pourquoi est-ce configuré ainsi ? Je sais qu’il y a eu beaucoup de discussions lorsque cela a été proposé pour la première fois, qui auraient été utiles comme référence.
Si c’est le cas, ils ne l’ont pas mentionné ici. La plupart des instructions ici tentent d’être aussi infaillibles que possible et de nécessiter le moins de connaissances en administration système possible. La plupart des gens préfèrent agir de la manière la plus sûre et la plus éprouvée possible plutôt que d’opter pour une méthode conçue pour économiser quelques dollars.
Si cela fonctionne pour vous, vous pouvez mettre à jour la mise à jour vers PostgreSQL 13 en conséquence, mais avant de le faire, vous sentez-vous à l’aise pour recommander à quelqu’un qui ne sait pas ce qu’est Bash de procéder ainsi ? Êtes-vous certain que cela ne détruira pas sa base de données et que son site ne sera pas ruiné à jamais ?
L’idée est que si d’autres bonnes informations sont présentées, elles soient ajoutées au message d’origine (OP) plutôt que de demander aux gens de lire des années de messages qui risquent d’être inutiles ou erronés.
Non, je ne suis pas sûr. Je n’ai pas beaucoup d’expérience avec PostgreSQL et j’espérais qu’un des développeurs de Discourse pourrait confirmer que cela fonctionnerait.
Même si cela fonctionne, je ne le recommanderais pas comme procédure de mise à niveau par défaut, car l’ancienne méthode conserve une copie séparée de la base de données pour le retour en arrière. Si cela fonctionne, ce serait cependant une excellente option pour les environnements à espace limité.
Une autre méthode simple consiste à déployer un nouveau serveur, migrer les données, puis désactiver l’ancien. Si vous devez utiliser l’ancien, effectuez la mise à niveau sur un serveur temporaire, puis installez une version neuve sur le serveur d’origine (qui a probablement besoin d’une mise à jour du système d’exploitation) avant de rétablir les données.
C’est sûr, simple et bien documenté. Des centaines de personnes l’ont déjà fait.
Oui, mais cela prendrait un jour ou deux. Pendant ce temps, nous pourrions soit a) informer les utilisateurs que leurs publications durant cette période seront perdues, soit b) rendre le forum en lecture seule. Aucune des deux options n’est idéale.
Je ne pense pas que le serveur sera hors ligne beaucoup plus longtemps que pendant la reconstruction. Et si vous migrez vers le nouveau serveur et y restez, vous pouvez laisser l’ancien serveur en mode lecture seule pendant la migration. Si l’indisponibilité vous inquiète, passer à un nouveau serveur sera bien, bien meilleur.
Nous avons un forum assez vaste, mais je n’ai jamais essayé de restaurer une sauvegarde, donc je ne sais pas combien de temps cela prendrait. Nous resterions effectivement sur le nouvel hébergeur si nous le faisions. J’aimerais éviter cela, si possible, pour éviter le travail supplémentaire et les tracas.
Une autre façon de résoudre le problème de mise à niveau avec un espace limité est de faire une sauvegarde, de supprimer le répertoire postgres avec rm -r, de reconstruire, puis de restaurer la sauvegarde. J’ai fait cela sur un site la semaine dernière.
La sauvegarde ne prendra-t-elle pas presque autant de place que la duplication du répertoire de données (voire plus, puisqu’elle doit également compresser) ?
Non, jamais mis à niveau. Supprimer la base de données et restaurer la sauvegarde semble assez risqué. Nous avons besoin que la mise à niveau sur place fonctionne, en gros.
Nous utilisons Ubuntu 18.04 qui sera obsolète en 2023, donc je pense qu’à ce moment-là, nous n’aurons pas d’autre choix que de migrer vers un nouvel hôte de toute façon, et nous prévoyons de mordre la balle alors, de construire un nouvel hôte exécutant 22.04 LTS, et de restaurer à partir de la sauvegarde.
Hmm. Cela pourrait être une perte. Je pense qu’avec le modèle de sauvegarde, l’une des copies est compressée, ce qui pourrait faire une différence ? Et le site sur lequel je l’ai fait avait des sauvegardes sur S3. Et c’était un site de test, donc les enjeux étaient faibles en cas de problème.
Sauf que les sauvegardes sont utilisées beaucoup plus souvent dans beaucoup plus de situations que la mise à niveau sur place. Je considère que c’est beaucoup plus sûr.
Peut-être, mais je n’ai pas beaucoup d’expertise avec postgres et je ne me sens pas à l’aise pour le faire. Restaurer tout le site à partir d’une sauvegarde sur une VM entièrement différente, cela, je me sens à l’aise pour le faire, cependant, cela signifierait perdre des publications pendant le nombre d’heures qu’il faut pour restaurer, donc je ne suis pas non plus très enthousiaste à ce sujet. Mais comme 18.04 n’est plus pris en charge, je n’aurai pas beaucoup le choix l’année prochaine.
À moins que votre base de données ne fasse des dizaines de gigaoctets, cela ne prendra pas des heures. Et vous mettrez le forum en mode lecture seule avant de sauvegarder et de restaurer, donc vous ne perdrez aucune publication. Ce n’est pas si difficile à faire avec pratiquement aucun temps d’arrêt, juste du temps en lecture seule.
root@forum-app:/shared/postgres_data# du -sh
97G .
Je ne le mettrais pas en lecture seule, je mettrais une bannière indiquant aux gens que leurs publications d’aujourd’hui sont éphémères. Mieux vaut les laisser en discuter même si ces publications seraient perdues, à mon avis.
D’ici là, vous aurez également accès au chat intégré de Discourse, une fonctionnalité qui sera livrée dans la version 2.9 (probablement désactivée par défaut, mais en bêta et prise en charge pour utilisation).