Restauration de sauvegarde échouée, sidekiq ne s'arrête pas puis s'emballe

Soutien
1

J’ai effectué une reconstruction ce matin, puis j’ai tenté de restaurer une sauvegarde dans le conteneur. Je suis sur la version 2.6.0.beta5 (75a893fd61), avec tout installé dans le conteneur.

La restauration de la sauvegarde fonctionne normalement (elle l’a déjà fait par le passé), mais aujourd’hui elle a échoué comme suit :

Starting restore: app-2020-11-06-033740-v20201009190955.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2020-11-06-084354 exists...
Copying archive to tmp directory...
Unzipping archive, this may take a while...
Extracting dump file...
Validating metadata...
  Current version: 20201103103401
  Restored version: 20201009190955
Enabling readonly mode...
Pausing sidekiq...
Waiting up to 60 seconds for Sidekiq to finish running jobs...
Waiting for sidekiq to finish running jobs... #2
Waiting for sidekiq to finish running jobs... #3
Waiting for sidekiq to finish running jobs... #4
Waiting for sidekiq to finish running jobs... #5
Waiting for sidekiq to finish running jobs... #6
Waiting for sidekiq to finish running jobs... #7
Waiting for sidekiq to finish running jobs... #8
Waiting for sidekiq to finish running jobs... #9
Waiting for sidekiq to finish running jobs... #10
EXCEPTION: Sidekiq did not finish running all the jobs in the allowed time!
/var/www/discourse/lib/backup_restore/system_interface.rb:89:in `block in wait_for_sidekiq'
/var/www/discourse/lib/backup_restore/system_interface.rb:84:in `loop'
/var/www/discourse/lib/backup_restore/system_interface.rb:84:in `wait_for_sidekiq'
/var/www/discourse/lib/backup_restore/restorer.rb:47:in `run'
script/discourse:143:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Trying to rollback...
There was no need to rollback
Cleaning stuff up...
Removing tmp '/var/www/discourse/tmp/restores/default/2020-11-06-084354' directory...
Unpausing sidekiq...
Disabling readonly mode...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Finished!
[FAILED]
Restore done.

Après cela, un processus Ruby consomme 100 % du CPU depuis plusieurs heures. Ce processus est décrit comme suit :

# ps aux | grep sidekiq
discour+    141  100  5.0 9302596 401484 ?      SNl  06:34 127:46 sidekiq 6.1.2 discourse [5 of 5 busy]

Si j’arrête et redémarre le conteneur, ce processus Sidekiq revient à 100 %. Le fichier sidekiq.log est vide, et production.log ne m’indique pas grand-chose.

Comment puis-je savoir ce que fait ce processus Sidekiq ? Quelqu’un d’autre a-t-il rencontré ce problème lors de la restauration d’une sauvegarde avec cette version ?

2

Un gentil messager m’a orienté vers la console Sidekiq, et il semble que Sidekiq soit occupé par la génération de miniatures :

image
image2408×1277 526 KB

Les sauvegardes que j’utilise n’incluent pas les miniatures, donc cela pourrait être normal. Cependant, j’avais déjà exécuté rake posts:rebake, puis rake posts:rebake_uncooked_posts après la restauration précédente de la sauvegarde de test, pensant que cela aurait généré toutes les miniatures (le rebake a pris environ 1 heure pour environ 100 000 messages, tandis que rebake_uncooked n’a rien fait, car je suppose que le rebake complet avait déjà tout pris en charge).

En supposant que cette charge de travail est ce qui empêche la sauvegarde de réussir, la restauration d’une sauvegarde ne devrait-elle pas d’abord purger les files d’attente de tâches ?

De plus, pourquoi Sidekiq génère-t-il des miniatures alors qu’il n’y a apparemment rien à faire, ou bien les commandes rebake se contentent-elles de mettre le travail en file d’attente ?

# rake posts:rebake_uncooked_posts
Rebaking des messages non cuits par défaut

0 messages traités !
3

C’est exact. Le rebake met en file d’attente un tas de tâches plutôt que de les exécuter toutes immédiatement.

Probablement. Mais on suppose généralement que si vous en savez assez pour restaurer une sauvegarde, vous savez aussi comment vider la file d’attente Sidekiq au préalable ; habituellement, vous restaureriez sur un site vide.

Je crois que c’est bien le cas.

4

Merci, cela commence à avoir beaucoup plus de sens.

Donc, la bonne séquence serait de détruire d’abord, puis (re)construire le conteneur, puis d’y entrer et de restaurer la sauvegarde ?

Si c’est le cas, c’est excellent, bien que Discourse pourrait peut-être fournir cet indice/avertissement lors du début d’une restauration dans un conteneur non vide.

5

C’est l’option nucléaire (et vous n’auriez probablement besoin que de supprimer les données Redis, puis de reconstruire). En général, vous n’avez pas un million de tâches en cours d’exécution, donc ce n’est pas un problème. Mais comme vous effectuez apparemment deux restaurations consécutives et que la première n’est pas tout à fait terminée lorsque vous en relancez une, vous êtes un cas particulier.

L’autre chose à faire serait d’aller à /sidekiq et de supprimer toutes les tâches mises en file d’attente. Cela ne prend que quelques clics.

6

Un bon test pour la reprise après sinistre alors :smiley:

Vous avez raison, c’est probablement un cas un peu particulier. J’essaie de réduire le temps de re-cuisson, alors je restaure des sauvegardes et je mesure le temps dans différentes situations (restaurer sans les miniatures prend par défaut 2 à 3 jours pour terminer la re-cuisson !). Tout cela fait partie des préparatifs pour une migration de site.

Je pense comprendre beaucoup plus maintenant, merci. Mais pour quelque chose d’aussi critique que les sauvegardes, je pense qu’il serait raisonnable que Discourse s’assure qu’elle soit aussi fiable que possible (par exemple, purger les files d’attente Sidekiq avant de démarrer), ou émettre des avertissements clairs indiquant que d’autres étapes sont nécessaires si elle détecte des problèmes potentiels pour la restauration.

Seul vous savez lequel faire.

7

Je vous suggère de créer une sauvegarde avec les vignettes (paramètre du site include_thumbnails_in_backups) lorsque vous souhaitez migrer vers un autre serveur.

8

Merci ! C’est une option que j’ai également essayée, mais la sauvegarde, bien qu’elle ne représente qu’environ 6 Go supplémentaires, prend environ une heure de plus à créer. Il semble que ce soit l’étape tar qui prenne du temps – il se peut que sur mon matériel plus ancien, l’accès à de nombreux petits fichiers soit lent. Le niveau de compression gzip est défini sur 1, donc je pense que c’est une limitation d’E/S plutôt que de CPU. Le nouvel hôte peut effectuer la même sauvegarde en 30 à 40 minutes.

Il est possible que je sois simplement un peu impatient dans ce cas, et que je doive accepter que la sauvegarde prenne plus de temps, mais comme le site principal est en mode lecture seule pendant ce processus, je tiens à minimiser cette durée.