Grande restauration échouant à mi-chemin

Soutien
1

Bonjour ! J’ai mis de côté la dernière migration dont j’ai parlé, mais je l’ai reprise. Elle est devenue un peu plus urgente avec certains problèmes sur l’hôte (obsolète) sur lequel l’installation d’origine se trouvait.

Contexte : Lors de la migration vers une nouvelle instance, j’ai décidé de migrer vers une instance PG et Redis externe. La mise en place de la nouvelle installation s’est bien déroulée, et je prévois de faire une sauvegarde + restauration à partir de la ligne de commande pour la migration elle-même. J’essaie actuellement de tester le flux de travail et de m’assurer que la nouvelle instance restaurée fonctionne comme prévu avant de rendre l’instance d’origine en lecture seule et de procéder, d’autant plus qu’il s’agit d’une instance assez ancienne/grande que je migre.

Ancienne instance : configuration simple d’auto-hébergement, une instance avec PG, Postgres, Redis standard co-localisés.
Nouvelle instance : même app.yml, mais avec PG + Redis externe géré (DigitalOcean).

La commande de restauration semble fonctionner pendant un bon moment. Puis, après un temps considérable, j’obtiens systématiquement une erreur qui ressemble à ceci (y compris des logs de succès pour le contexte) :

COPY 99820
COPY 3216770
COPY 3251307
SSL connection has been closed unexpectedly
FATAL:  terminating connection due to administrator command
CONTEXT:  COPY post_timings, line 63404000: "8311	4897	1816	6999"
SSL connection has been closed unexpectedly
FATAL:  terminating connection due to administrator command
CONTEXT:  COPY post_timings, line 63404000: "8311	4897	1816	6999"
invalid socket
connection to server was lost
EXCEPTION: psql failed: connection to server was lost
/var/www/discourse/lib/backup_restore/database_restorer.rb:95:in `restore_dump'

Elle s’est produite à différents points de copie spécifiques au cours des exécutions, donc à ma connaissance, ce n’est rien de spécifique à la migration elle-même. Étant donné que les connexions à la base de données fonctionnent clairement, je pense qu’il est prudent de supposer que cela est lié au comportement de DigitalOcean, mais j’espère que quelqu’un d’autre ici a déjà vu quelque chose de similaire et peut m’orienter dans la bonne direction.

2

Étant donné qu’il s’agit d’une instance PG gérée, vous voudrez vérifier les journaux de ce service.

(regardez toujours les journaux !)

Vous pourriez y trouver la raison pour laquelle cela s’est produit, par exemple, peut-être qu’une durée de vie maximale de connexion est configurée et que la restauration prend plus de temps à se terminer.

2 « J'aime »
3

Eh bien… euh… j’ai vérifié les journaux et c’était à peu près la même information que celle que je voyais dans les journaux Discourse, mais en creusant dans ceux-ci, j’ai fini par vérifier les graphiques historiques autour de cette période… j’avais sous-dimensionné la base de données de test :facepalm: donc elle s’est remplie et DO coupe la connexion. Zut.

J’ai redimensionné le tout et nous nous sentons stupides mais nous sommes de retour à la course.

2 « J'aime »
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.