Le script de mise à jour vérifiera l’espace disponible et ne procédera que si cela est sans risque.
Il y a deux étapes au cours desquelles l’espace disque peut devenir critique. Si vous contourniez la vérification de l’espace libre, c’est à ces moments-là que vous pourriez rencontrer des problèmes :
- Lors de l’exécution de pg_dump pour extraire les données de l’ancienne base de données (2 fois l’espace de stockage de la base requis à ce stade).
- Lors de l’exécution de pg_restore pour réinsérer les données dans la nouvelle base de données (3 fois l’espace de stockage de la base requis à ce stade).
Pour récupérer de cet état, vous devriez supprimer /shared/postgres_dump et /shared/postgres_data_new.
Notez qu’à la fin de la mise à jour, nous supprimons les fichiers temporaires de pg_dump, mais conservons vos données de base de données pré-mise à jour dans /shared/postgres_data_old au cas où. Une fois que vous serez satisfait du bon fonctionnement de tout, vous voudrez probablement supprimer ce répertoire pour libérer de l’espace disque.
J’ai testé la création d’une sauvegarde Discourse sur un site PG15 et sa restauration sur un site PG18. Cela a fonctionné pour moi, mais sachez que ce n’est pas une méthode officiellement supportée. Testez minutieusement sur un environnement non de production en premier et assurez-vous d’avoir un plan de retour en arrière !
Je recommande d’étudier le processus utilisé par le script de mise à jour. Si vous avez des exigences de stockage particulières, vous devriez pouvoir l’adapter à vos besoins. Encore une fois, testez d’abord :
C’est maintenant dans discourse_docker, oui. Si vous faites un pull de main ou exécutez ./launcher rebuild app, vous l’aurez.
Désactiver discourse_docker de la branche main aidera à prévenir les mises à jour accidentelles si vous souhaitez la reporter.