Backup-Wiederherstellung fehlgeschlagen, Sidekiq stoppt nicht und läuft dann davon

Unterstützung
1

Ich habe heute Morgen einen Neuaufbau durchgeführt und versucht, ein Backup im Container wiederherzustellen. Ich nutze Version 2.6.0.beta5
(75a893fd61) mit allen Komponenten im Container.

Normalerweise funktioniert die Wiederherstellung eines Backups (das ist bereits zuvor gelungen), aber heute ist sie wie folgt fehlgeschlagen:

Starting restore: app-2020-11-06-033740-v20201009190955.tar.gz
[STARTED]
'system' hat die Wiederherstellung gestartet!
Wiederherstellung als laufend markiert...
Sicherstellen, dass /var/www/discourse/tmp/restores/default/2020-11-06-084354 existiert...
Archiv in tmp-Verzeichnis kopieren...
Archiv entpacken, das kann eine Weile dauern...
Dump-Datei extrahieren...
Metadaten validieren...
  Aktuelle Version: 20201103103401
  Wiederhergestellte Version: 20201009190955
Nur-Lese-Modus aktivieren...
Sidekiq pausieren...
Bis zu 60 Sekunden warten, bis Sidekiq alle Jobs abgearbeitet hat...
Warten, bis Sidekiq alle Jobs abgearbeitet hat... #2
Warten, bis Sidekiq alle Jobs abgearbeitet hat... #3
Warten, bis Sidekiq alle Jobs abgearbeitet hat... #4
Warten, bis Sidekiq alle Jobs abgearbeitet hat... #5
Warten, bis Sidekiq alle Jobs abgearbeitet hat... #6
Warten, bis Sidekiq alle Jobs abgearbeitet hat... #7
Warten, bis Sidekiq alle Jobs abgearbeitet hat... #8
Warten, bis Sidekiq alle Jobs abgearbeitet hat... #9
Warten, bis Sidekiq alle Jobs abgearbeitet hat... #10
EXCEPTION: Sidekiq hat nicht alle Jobs innerhalb der zulässigen Zeit abgearbeitet!
/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>'
Versuch, einen Rollback durchzuführen...
Ein Rollback war nicht erforderlich.
Aufräumen...
/tmp-Verzeichnis '/var/www/discourse/tmp/restores/default/2020-11-06-084354' entfernen...
Sidekiq wieder aktivieren...
Nur-Lese-Modus deaktivieren...
Wiederherstellung als abgeschlossen markieren...
'system' über das Ende der Wiederherstellung informieren...
Abgeschlossen!
[FAILED]
Wiederherstellung abgeschlossen.

Danach laufen Ruby-Prozesse seit Stunden mit 100 % CPU-Auslastung. Dieser Prozess wird wie folgt beschrieben:

# 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]

Wenn ich den Container stoppe und neu starte, kehrt dieser Sidekiq-Prozess wieder auf 100 % zurück. sidekiq.log ist leer, production.log zeigt mir nicht viel.

Wie kann ich herausfinden, was dieser Sidekiq-Prozess tut? Hat jemand anderes bei der Wiederherstellung von Backups mit dieser Version ähnliche Probleme festgestellt?

2

Ein netter Gentleman hat mich auf die Sidekiq-Konsole aufmerksam gemacht, und es sieht so aus, als wäre Sidekiq mit der Erstellung von Thumbnails beschäftigt:

image
image2408×1277 526 KB

Meine Sicherungen enthalten keine Thumbnails, daher könnte dies erwartet werden. Allerdings habe ich nach der vorherigen Wiederherstellung einer Test-Sicherung bereits rake posts:rebake und danach rake posts:rebake_uncooked_posts ausgeführt. Ich ging davon aus, dass damit alle Thumbnails generiert sein sollten (das rebake dauerte etwa eine Stunde für rund 100.000 Beiträge, während rebake_uncooked nichts bewirkte, da die vollständige Neubearbeitung vermutlich alles erledigt hatte).

Angenommen, diese Arbeitslast ist der Grund, warum die Sicherung fehlschlägt: Sollte bei der Wiederherstellung einer Sicherung nicht zuerst die Warteschlange der Aufgaben geleert werden?

Außerdem: Warum generiert Sidekiq Thumbnails, wenn es anscheinend nichts zu tun gibt? Oder legen die Rebake-Befehle die Arbeiten lediglich in die Warteschlange?

# rake posts:rebake_uncooked_posts
Rebaking uncooked posts on default

0 posts done!
3

Das ist richtig. Die Neubearbeitung (Rebake) stellt eine Reihe von Aufgaben in die Warteschlange, anstatt sie sofort alle auszuführen.

Wahrscheinlich. Es wird jedoch weitgehend davon ausgegangen, dass, wenn Sie wissen, wie man eine Sicherung wiederherstellt, Sie auch wissen, wie man die Sidekiq-Warteschlange vorher bereinigt; normalerweise stellt man auf einer leeren Site wieder her.

Ich glaube, das ist der Fall.

4

Danke, das ergibt jetzt viel mehr Sinn.

Wäre also die richtige Reihenfolge, zuerst den Container zu zerstören, dann (neu) zu erstellen, ihn zu betreten und das Backup wiederherzustellen?

Falls ja, toll – vielleicht könnte Discourse aber einen entsprechenden Hinweis oder eine Warnung anzeigen, wenn eine Wiederherstellung in einen nicht-leeren Container gestartet wird.

5

Das ist die nukleare Option (und man müsste wahrscheinlich nur die Redis-Daten löschen und dann neu aufbauen). Normalerweise laufen nicht zigtausende Jobs gleichzeitig, sodass das kein Problem ist. Da du jedoch offenbar zwei Wiederherstellungen hintereinander durchführst und die erste noch nicht vollständig abgeschlossen ist, wenn du mit der zweiten beginnst, bist du ein Sonderfall.

Eine andere Möglichkeit wäre, zu /sidekiq zu gehen und alle dort wartenden Jobs zu löschen. Das dauert nur wenige Klicks.

6

Dann ein guter Test für die Notfallwiederherstellung :smiley:

Du hast recht, dass es sich wahrscheinlich um einen speziellen Fall handelt. Ich versuche, die Zeit für das Neuberechnen zu verkürzen, indem ich Backups wiederherstelle und die Dauer unter verschiedenen Bedingungen messe (das Wiederherstellen ohne Thumbnails dauert standardmäßig 2 bis 3 Tage, bis das Neuberechnen abgeschlossen ist!). All dies ist die Vorbereitung für eine Website-Migration.

Ich glaube, ich habe jetzt viel mehr verstanden, danke. Aber bei etwas so Wichtigem wie Backups finde ich es vernünftig, dass Discourse sicherstellt, dass es so zuverlässig wie möglich ist (z. B. Sidekiq-Warteschlangen vor dem Start leeren) oder klare Warnungen ausgibt, dass weitere Schritte erforderlich sind, wenn potenzielle Probleme für die Wiederherstellung erkannt werden.

Nur einer weiß, dass man das tun muss.

7

Ich empfehle dir, ein Backup mit Vorschaubildern (include_thumbnails_in_backups-Site-Einstellung) zu erstellen, wenn du auf einen anderen Server migrieren möchtest.

8

Danke! Das ist eine Option, die ich auch ausprobiert habe. Das Backup nimmt zwar nur etwa 6 GB zusätzlich in Anspruch, dauert aber rund eine Stunde länger. Es scheint, als ob der Tar-Schritt die Zeit beansprucht – auf meiner älteren Hardware könnte es sein, dass viele kleine Dateien langsam abgerufen werden. Die Gzip-Ebene ist auf 1 gesetzt, also denke ich, dass es eher durch die E/A als durch die CPU begrenzt ist. Der neue Host kann dasselbe Backup in 30 bis 40 Minuten erstellen.

Möglicherweise bin ich hier nur etwas ungeduldig und sollte akzeptieren, dass das Backup länger dauert. Da die primäre Seite während dieses Vorgangs im Nur-Lese-Modus ist, möchte ich diese Zeit jedoch so weit wie möglich verkürzen.