Pourriez-vous s’il vous plaît nous indiquer quel fichier nous devons modifier dans l’archive de sauvegarde tar ?
Il y a un fichier dump.sql inclus dans les archives. Vous devez le modifier, puis le recompresser avec la version modifiée. J’ai également résolu mes autres problèmes en le modifiant : j’ai supprimé certains champs personnalisés erronés qui provoquaient des plantages après la connexion.
Merci.
Je vais essayer de télécharger la sauvegarde, de la décompresser et de modifier ce fichier en suivant vos instructions.
C’est assez effrayant de devoir faire tout cela pour restaurer une sauvegarde.
Je suppose qu’il s’agit d’un bug de la nouvelle version.
Cependant, la sauvegarde et la restauration sont des pierres angulaires d’un plan de reprise après sinistre.
Elles devraient être aussi robustes que possible, et un bug dans ces processus a un impact considérable.
1 « J'aime »
Eh bien, j’ai pu effectuer la restauration sans modifier quoi que ce soit dans le fichier de sauvegarde.
J’ai simplement essayé plusieurs fois et, curieusement, à un moment, la restauration s’est déroulée sans erreur.
J’ai été déconnecté de Discourse et cela ne fonctionnait pas jusqu’à ce que je crée une application de reconstruction du lanceur.
Mais maintenant, tout fonctionne correctement.
Un problème étrange.
Cela me pose toujours problème pour restaurer mon forum à partir d’une sauvegarde. Cela fait plusieurs semaines et la fonctionnalité de restauration à partir d’une sauvegarde semble toujours être défectueuse.
Y a-t-il une solution à cela ?
À ma connaissance, il faut alterner entre les mises à jour, la vérification du formatage des tableaux, s’assurer que tout est similaire entre la source et l’hôte, et observer les échecs répétés. Cela peut ou non fonctionner sans quelques modifications mineures de la base de données.
J’ai réussi à migrer 2 sites sur 3 et je suis contraint de consacrer moins d’une heure par jour à cette tâche pour préserver ma santé mentale. J’ai commencé à discuter avec les clients des problèmes que cela pourrait causer à l’avenir dans toute situation similaire. haussement d’épaules
Je tiens simplement à insister sur la restauration, et j’ai réussi à la faire fonctionner.
L’erreur signale une colonne qui n’existe pas dans la table du profil utilisateur.
Cependant, il doit s’agir d’un problème de délai d’attente ou d’un problème similaire du côté de la base de données, peut-être un bug du côté de PostgreSQL. Si la colonne n’existe pas, elle n’est pas créée automatiquement lorsque vous insistez pour restaurer.
Jaromir indique que modifier le script résout le problème.
Aucun développeur de Discourse ici ne semble s’être préoccupé de ce problème, mais c’est une erreur étrange et très perturbante, car elle affecte votre plan de reprise après sinistre.
Il est possible que le sujet soit passé inaperçu parmi les autres.
Cela n’a pas échappé à mon attention. Ce sera la première chose que j’examinerai demain.
Et je commence à travailler sur l’amélioration des sauvegardes et des restaurations, car personne ne devrait avoir à s’inquiéter de ces aspects en cas de catastrophe ou simplement lorsqu’on souhaite migrer vers un nouveau serveur.
11 « J'aime »
Parfait. Merci.
Ravi de l’entendre.
Merci, Gerhard. Je ne sais pas si cela vous intéresse actuellement, mais je rencontre également des problèmes avec un site utilisant PG 11 sur GCP. Cela vaut peut-être la peine de vérifier cela, car cela pourrait affecter la future migration vers PG 12, qui, si je comprends bien, devrait avoir lieu plus tard cet automne.
Je viens de mettre à niveau deux instances partageant un même bucket de sauvegarde S3. J’ai effectué une sauvegarde sur l’une d’elles et tenté de restaurer sur l’autre, mais j’obtiens :
No migration with version number 20191007140446.
PostgreSQL 11 et 12 ne sont actuellement pas pris en charge.
4 « J'aime »
D’accord, j’ai installé la dernière version de Discourse (tests-passed) sur un droplet et la restauration des sauvegardes (incluant les fichiers uploadés, sans utiliser S3 pour les uploads) s’est déroulée sans problème.
Si vous rencontrez toujours des problèmes lors d’une restauration, veuillez procéder comme suit :
-
Reconstruisez le conteneur :
cd /var/discourse git pull ./launcher rebuild app -
Restaurez la sauvegarde soit via l’interface web, soit en ligne de commande :
cd /var/discourse ./launcher enter app discourse enable_restore discourse restore <filename>
Si cela ne fonctionne pas, veuillez publier le numéro de version du fichier de sauvegarde que vous essayez de restaurer ainsi que le message d’erreur affiché pendant la restauration.
6 « J'aime »
Les deux sites sont en version 2.4.0.beta6 (8fc0cc9aaa). Les sauvegardes (mais pas les fichiers uploadés) sont stockées sur S3.
discourse restore renvoie :
Starting restore: wonderful-community-2019-10-10-184822-v20191007140446.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2019-10-10-211121 exists...
Downloading archive to tmp directory...
Unzipping archive, this may take a while...
EXCEPTION: Compression::Strategy::ExtractFailed
/var/www/discourse/lib/compression/gzip.rb:49:in `block in extract_file'
/var/www/discourse/lib/compression/gzip.rb:45:in `open'
/var/www/discourse/lib/compression/gzip.rb:45:in `extract_file'
Bien sûr, et je pense que ce site se contentera de sauvegardes directes de base de données sur GCP de toute façon, mais à un moment donné, Sam a mentionné qu’il utilisait PG 11 sur son site de développement et qu’il serait intéressé de connaître les problèmes liés à PG 11.
@pfaffman Veuillez augmenter le paramètre de site decompressed_file_max_size_mb (il est masqué). La valeur par défaut est actuellement fixée à 1 Go.
J’ai une PR prête à porter la valeur par défaut à 100 Go, mais elle n’a pas encore été fusionnée :
7 « J'aime »
Merci, @Roman. Cela a résolu ce problème.
Mais maintenant, j’ai toute une série de invalid command \N (et ils ont rempli le tampon avant que je puisse voir ce qui les précédait), mais peut-être que
ERROR: syntax error at or near "Shiny"
LINE 1: Shiny contest submission 2019-01-07 20:00:05.570573 2019-01-...
^
EXCEPTION: psql failed
/var/www/discourse/lib/backup_restore/restorer.rb:324:in `restore_dump'
/var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
c’est ce dont vous avez besoin.
Oui, je pense que cela est dû à PG11.
2 « J'aime »
Si c’était l’instance pg11, je serais d’accord ! Mais il s’agit d’une installation standard à deux conteneurs.
Attends ! Il y a une incompatibilité de version.
root@community:/var/discourse# ./launcher enter data root@staging-data:/# psql --version
psql (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg16.04+1)
Celui sur lequel je restaure est la version 10.9 ! Je parie que c’est ça. (Je pense que pg11 échoue de manière similaire, mais là, j’essaie de restaurer sur la même instance).
Je vais mettre à niveau les conteneurs de données demain et je te tiendrai au courant. Merci pour ton aide.
3 « J'aime »
Eh bien, j’ai mis à jour les deux vers la version 10.10 (en utilisant les modèles de données standard), mais j’ai toujours eu les erreurs de « commande invalide ».
Lorsque les erreurs de « commande invalide » ont commencé, j’ai forcé l’arrêt du script de restauration. De nouvelles tentatives de restauration (pour obtenir la première erreur avant les messages de « commande invalide ») ont abouti à :
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: la relation « theme_fields » n'existe pas
J’ai ensuite exécuté rake db:migrate sur les deux instances, effectué une nouvelle sauvegarde et la restauration a réussi. Peut-être qu’une migration a été manquée quelque part en cours de route ?
(après avoir modifié le paramètre mentionné ci-dessus—voici les instructions complètes pour ceux qui pourraient en avoir besoin dans le peu de temps avant que cela ne devienne inutile)
./launcher enter app
rails c
SiteSetting.decompressed_file_max_size_mb=1000000
1 « J'aime »
Je viens d’en avoir un autre qui a échoué. Les deux sont en version 2.4.0.beta6 (l’un est 2c011252f1, l’autre est peut-être un peu plus récent).
Je restaure via S3. J’ai essayé avec et sans les fichiers joints. Les deux semblaient fonctionner, puis ont échoué comme ceci :
...
COPY 11871
COPY 3689
COPY 0
COPY 36550
COPY 0
COPY 14736
/usr/local/bin/discourse: ligne 2 : 3232 Tué RAILS_ENV=production sudo -H -E -u discourse bundle exec script/discourse "$@"
Est-ce le seul message que vous recevez ?
Et si vous essayiez de supprimer toute dépendance S3 et de copier d’abord le fichier de sauvegarde en local ?
@pfaffman, il serait bon de savoir que les deux (ou trois) problèmes de restauration que vous avez signalés dans ce sujet ne sont pas des occurrences du bug dont ce sujet traitait à l’origine (le problème PG::UndefinedColumn: ERROR). Vous pourriez envisager d’ouvrir de nouveaux sujets pour ces problèmes, car il s’agit clairement de problèmes différents.
4 « J'aime »