Fehler beim Upgrade von 2.3.5 auf 2.4.2

Ich versuche, von 2.3.5 auf 2.4.2 zu aktualisieren (in einem Bitnami-Docker-Container auf Google Cloud).

Die Wiederherstellung des 2.3.5-Backup-Archivs in eine neue 2.4.2-Instanz ist komplett fehlgeschlagen.

Ich habe das Archiv entpackt, die pg_dump-Datei erhalten und diese in eine neue Datenbank geladen. Es sah größtenteils gut aus, außer bei zwei Fehlern:

> ERROR:  schema "discourse_functions" does not exist
> ERROR:  schema "discourse_functions" does not exist

Also fehlt etwas…

Ich habe es trotzdem versucht…

> /opt/bitnami/apps/discourse/htdocs$ sudo bin/rake db:migrate RAILS_ENV=production
> rake aborted!
> PG::InsufficientPrivilege: ERROR:  permission denied for table site_settings
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/mini_sql-0.2.4/lib/mini_sql/postgres/connection.rb
> :118:in `exec'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/mini_sql-0.2.4/lib/mini_sql/postgres/connection.rb
> :118:in `run'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/mini_sql-0.2.4/lib/mini_sql/postgres/connection.rb
> :82:in `query'
> /opt/bitnami/apps/discourse/htdocs/lib/site_settings/db_provider.rb:19:in `all'
> /opt/bitnami/apps/discourse/htdocs/lib/site_settings/defaults_provider.rb:29:in `db_all'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:277:in `block in refresh!'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:274:in `synchronize'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:274:in `refresh!'
> /opt/bitnami/apps/discourse/htdocs/lib/site_setting_extension.rb:495:in `block in setup_methods'
> /opt/bitnami/apps/discourse/htdocs/config/initializers/004-message_bus.rb:120:in `<top (required)>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:319:in `load'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:319:in `block in load'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:291:in `load_dependency'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:319:in `load'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:667:in `block i
> n load_config_initializer'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/notificatio
> ns.rb:182:in `instrument'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:666:in `load_co
> nfig_initializer'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:624:in `block (
> 2 levels) in <class:Engine>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:623:in `each'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/engine.rb:623:in `block i
> n <class:Engine>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:32:in `i
> nstance_exec'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:32:in `r
> un'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:61:in `b
> lock in run_initializers'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:50:in `e
> ach'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:50:in `t
> sort_each_child'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/initializable.rb:60:in `r
> un_initializers'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/application.rb:363:in `in
> itialize!'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `public
> _send'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/railtie.rb:190:in `method
> _missing'
> /opt/bitnami/apps/discourse/htdocs/config/environment.rb:7:in `<top (required)>'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.2.2/lib/zeitwerk/kernel.rb:23:in `requi
> re'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/zeitwerk-2.2.2/lib/zeitwerk/kernel.rb:23:in `requi
> re'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:325:in `block in require'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:291:in `load_dependency'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/activesupport-6.0.1/lib/active_support/dependencie
> s.rb:325:in `require'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/application.rb:339:in `re
> quire_environment!'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/railties-6.0.1/lib/rails/application.rb:515:in `bl
> ock in run_tasks_blocks'
> /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/2.6.0/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
> Tasks: TOP => db:migrate => db:load_config => environment
> (See full trace by running task with --trace)

Jede Hilfestellung wäre willkommen.

Es tut uns leid, aber das Bitnami-Paket wird hier nicht unterstützt. Es handelt sich um ein Paket eines Drittanbieters. Wenn Sie es weiterhin nutzen möchten, müssen Sie sich für Unterstützung direkt an den Anbieter wenden.

Unserer Empfehlung nach sollten Sie ein vollständiges Backup erstellen und eine Neuinstallation mit der unterstützten Standard-Installationsmethode durchführen.

Hallo Stephen,

sollte eine Wiederherstellung aus einem 2.3.5-Backup-Archiv auf einer Standard-2.4.2-Installation problemlos funktionieren?

Das sollte es, aber vertraue nicht blind darauf und plane eine Ausweichstrategie. Denk daran, dass du eine nicht unterstützte Installation betreibst. Ich kann dir zwar Vorschläge machen, wie du auf einen besser unterstützten Pfad kommst, aber Bitnami-Installationen sind problematisch – es ist am besten, sich auf das Schlimmste vorzubereiten.

Wenn du auf einem separaten Server baust, kannst du dies testen, bevor du irreversible Änderungen an deiner bestehenden Installation vornimmst.

Ein wenig Hintergrund:

Wir haben Version 2.3.5 auf Amazon ausgeführt.

Wir haben versucht, das Standard-Installationspaket auf Docker auf einer Ubuntu 18.04 LTS-VM sowohl auf Google Cloud als auch lokal auf VirtualBox zu erstellen. Das gleiche Problem tritt auf.

Wir konnten weder discourse Docker v2.3.5 (mit integriertem Postgres/Redis) noch v2.3.10 erstellen. Beide schlagen mit einem Postgres-Berechtigungsproblem fehl, sowohl auf Google Cloud als auch auf der VirtualBox-VM mit Ubuntu 18.04.

Die stabile Version (2.4.2) wird zwar erstellt, aber weder das Docker-Image 2.4.2 auf Google Cloud noch auf VirtualBox lädt. Beide schlagen beim Erstellen von „discourse functions

Ich kann dann posten, wo genau jede Umgebung hängen bleibt. Falls das passiert.

Werden Google Cloud-Instanzen mit Ubuntu 18.04 unterstützt? Und deren SQL?

Ja, aber es ist eine komplexere Umgebung als bei DigitalOcean. Die Installation bei DO dauert höchstens 30 Minuten, und Sie müssen sich keine Sorgen um ACLs und Netzwerkrichtlinien machen.

Schauen Sie sich beispielsweise /var/discourse/templates/web_only.yml an (oder ein ähnliches, das ist aus dem Gedächtnis), um zu sehen, wie eine externe Datenbank verwendet wird.

Sobald Sie eine leere Site eingerichtet haben, können Sie ein Backup mit discourse restore wiederherstellen.

Wir haben versucht, Discourse 2.3.5 in einer Ubuntu 18.0.4-VM zu bauen. Die Version „v2.3.5

Soll ich es bei DigitalOcean versuchen oder mit einer externen Datenbank?

Es sieht so aus, als wäre die Installation der Discourse-Container-Version 2.3.5 auf einer Google All-in-One 18.0.4 LTS-Instanz hier abgestürzt:

> [2020-05-01T18:54:20.903566 #1]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle install --deployment --retry 3 --jobs 4 --verbose --without test development'/usr/local/lib/ruby/site_ruby/2.6.0/rubygems.rb:275:in `find_spec_for_exe': Could not find 'bundler' (1.17.3) required by your /var/www/discourse/Gemfile.lock. (Gem::GemNotFoundException)To update to the latest version installed on your system, run `bundle update --bundler`.To install the missing version, run `gem install bundler:1.17.3`        from /usr/local/lib/ruby/site_ruby/2.6.0/rubygems.rb:294:in `activate_bin_path'        from /usr/local/bin/bundle:23:in `<main>'I, [2020-05-01T18:54:21.234673 #1]  INFO -- : I, [2020-05-01T18:54:21.235321 #1]  INFO -- : Terminating async processesI, [2020-05-01T18:54:21.235582 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/10/bin/postmaster -D /etc/postgresql/10/main pid: 64I, [2020-05-01T18:54:21.235838 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 1812020-05-01 18:54:21.236 UTC [64] LOG:  received fast shutdown request181:signal-handler (1588359261) Received SIGTERM scheduling shutdown...2020-05-01 18:54:21.241 UTC [64] LOG:  aborting any active transactions2020-05-01 18:54:21.248 UTC [64] LOG:  worker process: logical replication launcher (PID 73) exited with exit code 12020-05-01 18:54:21.248 UTC [68] LOG:  shutting down181:M 01 May 2020 18:54:21.268 # User requested shutdown...181:M 01 May 2020 18:54:21.269 * Saving the final RDB snapshot before exiting.181:M 01 May 2020 18:54:21.271 * DB saved on disk181:M 01 May 2020 18:54:21.271 # Redis is now ready to exit, bye bye...2020-05-01 18:54:21.288 UTC [64] LOG:  database system is shut down

Warum nicht stable erstellen und testen, ob die Wiederherstellung darin funktioniert?

Ok, wir versuchen das und melden den Fehler zurück.

Sollten wir einen Befehl über die Kommandozeile oder die Wiederherstellungsfunktion über die Benutzeroberfläche verwenden?

Beides sollte funktionieren. Was immer einfacher ist.

Ok, wir konnten eine 2.4.2-Umgebung erstellen. Das Backup wurde jedoch aus einer Amazon-Bereitstellung mit konfiguriertem S3 erstellt. Die Wiederherstellung in einer nicht-Amazon-Umgebung schlägt bei einigen S3-Skripten fehl.

> Verbindung zur Datenbank wird wiederhergestellt...
> Site-Einstellungen werden neu geladen...
> Ausgehende E-Mails für Nicht-Mitarbeiter werden deaktiviert...
> Nur-Lese-Modus wird deaktiviert...
> Kategorien-Cache wird geleert...
> Emoji-Cache wird geleert...
> Theme-Cache wird geleert
> Hochladungen werden neu zugeordnet...
> Hochladungen werden wiederhergestellt, dies kann eine Weile dauern...
> Hochladungen werden für 'default' zu S3 migriert...
> Dateien werden zu S3 hochgeladen...
>  - Lokale Dateien werden aufgelistet
>  => 3 Dateien
>  - S3-Dateien werden aufgelistet
> . => 3 Dateien
>  - Dateien werden zu S3 synchronisiert
> ...
> URLs in der Datenbank werden aktualisiert...
> Alte optimierte Bilder werden entfernt...
> Alle Beiträge mit Lightboxen werden für eine Neubearbeitung markiert
> 182 Beiträge wurden für eine Neubearbeitung markiert
> AUSNAHME: 215 von 295 Hochladungen wurden nicht zu S3 migriert. Die S3-Migration für die DB 'default' ist fehlgeschlagen.
> /var/www/discourse/lib/file_store/to_s3_migration.rb:131:in `raise_or_log'
> /var/www/discourse/lib/file_store/to_s3_migration.rb:78:in `migration_successful?'
> /var/www/discourse/lib/file_store/to_s3_migration.rb:351:in `migrate_to_s3'
> /var/www/discourse/lib/file_store/to_s3_migration.rb:65:in `migrate'
> /var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
> /var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
> /var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
> /var/www/discourse/lib/backup_restore/restorer.rb:59: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 `invok
> e_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/exe/bundle:34:in `<top (required)>'
> /usr/local/bin/bundle:23:in `load'
> /usr/local/bin/bundle:23:in `<main>'
> Rückgängigmachen wird versucht...
> Rückgängigmachen...
> Aufräumen...
> Funktionen aus dem discourse_functions-Schema werden entfernt...
> tmp-Verzeichnis '/var/www/discourse/tmp/restores/default/2020-05-01-230400' wird entfernt...
> Sidekiq wird wieder freigegeben...
> Wiederherstellung wird als abgeschlossen markiert...
> 'system' wird über das Ende der Wiederherstellung informiert...
> Abgeschlossen!
> [FEHLGESCHLAGEN]
> Wiederherstellung abgeschlossen.

Was nun?

Führen Sie ein reines Datenbank-Backup und eine Wiederherstellung durch und verschieben Sie die lokalen Assets manuell.

Die Websites, bei denen ich dieses Problem habe, haben Assets in zwei verschiedenen S3-Buckets.