L’esecuzione di “./launcher rebuild app” fallisce su db:migrate. Si noti che stiamo utilizzando PostgreSQL v12.
Questo ha distrutto il nostro forum. Il container Docker è tornato online, ma il forum no. Fortunatamente ho eseguito uno snapshot della VM prima dell’aggiornamento, lo sto ripristinando ora.
Log:
Tasks: TOP => db:migrate
(Vedi la traccia completa eseguendo il task con --trace)
I, [2022-04-14T15:20:51.896917 #1] INFO -- : == 20220304162250 EnableUnaccentExtension: migrating =========
-- enable_extension("unaccent")
I, [2022-04-14T15:20:51.897218 #1] INFO -- : Terminating async processes
I, [2022-04-14T15:20:51.897265 #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/12/bin/postmaster -D /etc/postgresql/12/main pid: 1710
I, [2022-04-14T15:20:51.897396 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 1827
2022-04-14 15:20:51.897 UTC [1710] LOG: received fast shutdown request
1827:signal-handler (1649949651) Received SIGTERM scheduling shutdown...
2022-04-14 15:20:51.900 UTC [1710] LOG: aborting any active transactions
2022-04-14 15:20:51.902 UTC [1710] LOG: background worker "logical replication launcher" (PID 1719) exited with exit code 1
2022-04-14 15:20:51.904 UTC [1714] LOG: shutting down
1827:M 14 Apr 2022 15:20:51.913 # User requested shutdown...
1827:M 14 Apr 2022 15:20:51.914 * Saving the final RDB snapshot before exiting.
2022-04-14 15:20:51.965 UTC [1710] LOG: database system is shut down
1827:M 14 Apr 2022 15:20:53.157 * DB saved on disk
1827:M 14 Apr 2022 15:20:53.157 # Redis is now ready to exit, bye bye...
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 2118 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
2dcd9aeca614c9e06ef748f673eb68203db6eae5c445253b416d666663879d6d
==================== END REBUILD LOG ====================
Failed to rebuild app.
Non sono separati e nessun PG esterno. Anche l’aggiornamento PG13 fallisce (in modo non distruttivo, a differenza dell’aggiornamento odierno) e, a dire il vero, non ho ricevuto supporto su come risolverlo qui.
Credo (ovviamente non posso controllare) che avessimo solo un container visibile in docker ps. L’installazione standard ora prevede 2 container?
Questa estensione è diventata disponibile come estensione “trusted” su PostgreSQL 13+, dove può essere abilitata da qualsiasi utente.
Poiché stai eseguendo una versione precedente di PostgreSQL, dovrai trovare una soluzione alternativa, installando e abilitando questa estensione per l’utente Discourse, e potenzialmente cercando di ingannare Discourse facendogli considerare questa estensione come già installata. Oppure passare alla versione attualmente supportata di PostgreSQL.
OK. Quindi, in sintesi, non supportate più PG12. Suggerisco di pubblicare questo nella discussione sull’aggiornamento di PG13, e probabilmente anche negli annunci di 2.9.0b4.
Se sei preoccupato per i tempi di inattività, una soluzione sarebbe replicare il server sul nuovo host. Qualcosa come community/archived/setting-up-postgres-hot-standby.md at master · GoogleCloudPlatform/community · GitHub. (Potresti essere in grado di trovare istruzioni più recenti o alcune che abbiano più senso per te…). Ciò ti consentirebbe di migrare al nuovo database mentre il vecchio continuava a funzionare. Ma è tutt’altro che semplice.
È un’ottima idea, se fosse mysql, ms-sql o oracle lo farei, ma data la mia mancanza di esperienza con postgres probabilmente mi limiterei a subire il downtime.
Il mio ripristino è finalmente terminato, dopo oltre 4 ore. E Discourse stava mostrando errori 502. Questo snapshot è stato eseguito prima dell’aggiornamento, quindi è super bizzarro.
Comunque, guardando i log di nginx ho trovato questo errore
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require': cannot load such file -- /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb (LoadError)
Infatti, questo file era di proprietà di root:root e aveva permessi 0000. Cambiarlo in discourse:root e 644 per farlo corrispondere agli altri file in quella directory ci ha permesso di riavviare. Phew!
Avete idea di come quel file sia stato cancellato/modificato? È anche di 0 byte, super strano.
root@forum-app:/shared/log/rails# ls -la /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb
-rw-r--r-- 1 discourse root 0 Feb 10 17:41 /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb
Ho provato a fare il “Ripristina a un’installazione pulita”, ma non funziona, PG non collabora. Ho provato a eseguire il downgrade della versione di discourse e a tornare a PG12, ma poi diventa un carnevale di luci con tutti i plugin.
Sì, ho modificato il template, come parte della strategia “ok, questo non funziona” in modo da poter tornare a PG12 (anche se questo mi fa chiedere come farò ad aggiornare PG allora ).
Ho provato quelli più recenti ma l’errore enable_extension("unaccent") è ancora presente, il che implica che su quei commit la modifica per dipendere da esso era già stata fatta.
In attesa del risultato di questo tentativo.
Aggiornamento: No, è fallito durante il ripristino nella fase di “unpacking dump” ed ora è di nuovo morto.
Ciao, se hai un backup di discourse, ti suggerirei di provare prima su un server diverso.
Credo che tu abbia riscontrato questo problema durante l’aggiornamento di un’istanza di discourse che eseguiva una versione precedente.
Quindi, prova a installare una copia di discourse modificando manualmente lo yml per utilizzare discourse “stable” e blocca la versione di postgres a 12.
Se la build ha successo, prova a ripristinare il backup. Speriamo che venga ripristinato correttamente.
Se ha successo, cambia il template postgres 12 al template postgres predefinito e commenta il tag stable in modo che discourse venga ricostruito con gli ultimi test superati.
Credo che se il backup è recuperabile, dovrebbe quindi essere in grado di sopravvivere agli aggiornamenti di postgres e discourse.
Sono praticamente in “limbo” in questo momento. Ho provato il tuo suggerimento con PG12 e “Stable”. Non funziona, il ripristino si interrompe. Quindi sto formattando di nuovo la macchina per riprovare da capo perché ora non riesce a ricostruire le app.
Mentre quella macchina sta cercando di “tornare a PG12”, sto cercando di vedere se riesco ad andare avanti con l’altra: se provo ad aggiornare PG con una nuova installazione, si blocca dopo Creating missing functions in the discourse_functions schema... (inizia a restituire 500) e tail -f shared/data/log/var-log/postgres/current mostra che il container dei dati si sta “muovendo”, anche se è pieno di “errori” come questo:
discourse@discourse ERROR: relation "user_auth_tokens" does not exist at character 34
discourse@discourse STATEMENT: SELECT "user_auth_tokens".* FROM "user_auth_tokens" WHERE ((auth_token = 'XXXX=' OR
prev_auth_token = 'XXXX=') AND rotated_at > '2022-03-09 10:21:44.051357') LIMIT 1
discourse@discourse ERROR: relation "application_requests" does not exist at character 41
discourse@discourse STATEMENT: SELECT "application_requests"."id" FROM "application_requests" WHERE "application_requests"."date" = '2022-05-08' AND "application_requests"."req_type" = 0 LIMIT 1
Tuttavia, anche se Discourse è bloccato, la macchina viene utilizzata, quindi… sta funzionando ma richiede ore e ore? Perché l’ho lasciato andare per oltre 1 ora e non è cambiato nulla.
A questo punto sto già pensando se questo non dovrebbe andare qui, lol.
PD: Ho provato 2 backup diversi, dato che ne ho fatti 2 prima dell’avventura.
Non è un buon risultato: quindi non sei riuscito a ripristinare il tuo backup dalla vecchia versione di Discourse con PG12 su una nuova versione con PG13? Puoi pubblicare i messaggi di errore, ecc.? Tutti qui mi hanno ripetutamente assicurato che avrebbe funzionato.
).