Nous exploitons une installation Discourse plus importante sur une configuration VPS qui fonctionne très bien pour nous. En termes de performances CPU/Mémoire, nous avons de la marge. L’espace disque est cependant un peu un problème - pas dans les opérations quotidiennes, mais lorsqu’il s’agit de mettre à niveau Postgres par exemple (la mise à niveau 13->15 est en suspens à cause de cela), nous manquons d’espace et ne pouvons pas facilement l’étendre.
Je sais qu’il existe d’autres options pour la mise à jour de postgres, mais considérez cela plutôt comme une question générale.
Nous fonctionnons sur Hetzner où le stockage réseau est facilement disponible pour une utilisation temporaire.
Sur notre serveur de test, je suis en train de jouer avec pour que cela fonctionne de manière temporaire - d’abord pour restaurer une sauvegarde du site en production, puis pour tester la mise à niveau de Postgres. Jusqu’à présent, je n’ai pas réussi.
J’ai déjà essayé de créer des liens symboliques (symlinking), mais j’ai remarqué que cela ne fonctionnait pas et j’ai également lu ici quelque part que ce n’est pas la méthode recommandée. J’ai également essayé de déplacer le partage /shared de /var/discourse/shared/standalone vers /mnt/ext-storage/standalone et j’y ai déplacé les fichiers - malheureusement, pas sans problèmes. Je ne peux même pas terminer la construction (build).
Existe-t-il un moyen qui fonctionne pour ce genre de cas ? Je suis conscient que les performances du lecteur sont bien pires que celles du lecteur local, mais je ne prévois pas de faire fonctionner le forum dessus. J’aimerais vraiment avoir un moyen confortable de l’utiliser pour certains scénarios.
Si votre objectif est de faire la mise à niveau, le plus simple est de créer une nouvelle VM et d’y migrer. Vous évitez ainsi la nécessité de mettre à niveau la base de données et vous obtenez un nouvel OS sur votre VM, ce que vous devrez probablement faire de toute façon.
Si vos sauvegardes sont sur s3, il est très simple de geler l’ancienne, de faire une sauvegarde et de restaurer la sauvegarde sur la nouvelle machine.
Si hetzner dispose d’une sorte d’IP permanente qui peut être attribuée à différents serveurs, vous n’avez même pas besoin de changer le DNS.
Vous voulez savoir que vous pouvez construire un nouveau serveur afin de pouvoir le faire si jamais vous devez le faire pour une raison quelconque. C’est une excellente occasion de vous entraîner.
En fait, ce n’est pas une option. De toute façon, il n’y a pas de manque d’espace pour les besoins quotidiens. De plus, nous sommes actuellement sur un disque de 600 Go et en utilisons environ 50 %. Il n’y a pas d’option plus grande, du moins pas chez Hetzner.
C’est pourquoi je demandais explicitement le disque externe.
Avez-vous effectué un ./launcher cleanup app par curiosité ? Cela n’a-t-il pas libéré suffisamment d’espace pour effectuer la mise à niveau sur place ?
Je ne suggérais pas de passer à un disque plus grand, juste d’obtenir un nouveau serveur exactement comme celui-ci. Installez Discourse, restaurez votre base de données.
C’est une très bonne question.
Oui. Chaque reconstruction crée un nouveau conteneur et chacun d’eux prend de la place. Si vous ne l’avez jamais fait, vous pourriez libérer des dizaines de Go.
Notre guide de mise à jour comprend un guide pour votre cas d’utilisation exact
Nous avons ajouté cette option pour les personnes qui se trouvent dans la même situation que vous. Assurez-vous simplement de stocker une sauvegarde hors site avant d’essayer cela !
Si vous êtes sur une machine virtuelle, il est beaucoup, beaucoup plus facile de simplement en déplacer vers une nouvelle, et il y a de nombreux avantages. En voici quelques-uns :
risque nul — si quelque chose tourne mal, vous avez toujours votre ancien serveur
temps d’arrêt nul (juste en lecture seule sur l’ancien serveur)
vous obtenez la mise à niveau du système d’exploitation dont vous avez probablement besoin de toute façon
vous pouvez vérifier que vous savez comment démarrer un nouveau serveur en cas de catastrophe
vous n’avez pas besoin de réindexer et de faire un vacuum
Il peut être utile de conserver vos téléchargements, ou, disons, /var/discourse/shared/web_only sur un stockage réseau. Vous devez modifier le fichier yml pour qu’il pointe vers celui-ci plutôt que d’utiliser un lien symbolique (le lien symbolique ne fonctionne pas car le conteneur ne peut pas accéder à l’emplacement vers lequel votre lien symbolique pointe).
Ensuite, si vous migrez vers une nouvelle VM, vous pouvez simplement remonter ce stockage réseau au lieu de le copier.
Je ne recommande pas le stockage réseau pour la base de données car il est plus lent.
Je pense qu’il est utile de détailler votre utilisation. La taille réelle de votre base de données n’est peut-être pas si importante, si la plupart de votre utilisation concerne les téléchargements, et que seule la partie base de données nécessite environ 3 fois plus d’espace lors de la mise à niveau.
Une chose que vous pouvez vérifier est la taille relative d’une sauvegarde avec téléchargements par rapport à une sauvegarde sans téléchargements.
Ou, utilisez la ligne de commande. Voici quelques sorties de mon forum plutôt petit :
J’aurais dû être plus précis au départ, mais je ne m’attendais pas à recevoir autant de commentaires.
Nos téléchargements et sauvegardes sont sur S3. La taille de la base de données sur le système en direct est maintenant d’environ 230 Go. Les sauvegardes compressées pèsent environ 25 Go, je pense.
Je pense que c’est censé le faire. Je ne sais pas ce qui le déclenche. Je pense que faire un nettoyage supplémentaire ne fait pas de mal et pourrait vous faire économiser de l’espace. Il est recommandé de le faire après la mise à niveau si vous la faites sur place. Je l’ai vu nettoyer considérablement de l’espace à quelques reprises.
Si votre base de données fait 230 Go, je la restaurerais certainement sur un nouveau serveur. Le temps d’arrêt pour lire et écrire 230 Go sera important.