Solo per informazione: non provate questo aggiornamento durante le ore di punta.
L’aggiornamento alla versione 2.6.0b2 è in esecuzione sul nostro server da oltre 40 minuti, mentre normalmente richiede solo pochi minuti e di solito è già completato prima di tornare a controllarlo. Ero preoccupato che si fosse bloccato, ma accedendo a PostgreSQL vedo che è in corso un aggiornamento massiccio: sembra stia modificando i dati di ricerca dei post per i messaggi privati.
Speriamo che non sia rotto. Vedremo. Davvero non voglio interromperlo o riavviare il container a metà aggiornamento.
Query in esecuzione:
postgres=# SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
pid | age | usename | query
-------+-----------------+-----------+---------------------------------------------------------------------------
-------------------
698 | | |
701 | | postgres |
699 | | |
697 | | |
696 | | |
14572 | 00:10:31.484201 | discourse | UPDATE post_search_data
+
| | | SET private_message = X.private_message
+
| | | FROM
+
| | | (
+
| | | SELECT post_id,
+
| | | CASE WHEN t.archetype = 'private_message' THEN TRUE ELSE FALSE END pri
vate_message +
| | | FROM posts p
+
| | | JOIN post_search_data pd ON pd.post_id = p.id
+
| | | JOIN topics t ON t.id = p.topic_id
+
| | | WHERE pd.private_message IS NULL OR
+
| | | pd.private_message <> CASE WHEN t.archetype = 'private_message' THEN T
RUE ELSE FALSE END+
| | | LIMIT 3000000
+
| | | ) X
+
| | | WHERE X.post_id = post_search_data.post_id
+
| | |
14573 | 00:47:02.814489 | discourse | SELECT pg_try_advisory_lock(2859260972035668690)
(7 rows)
Anche per me l’aggiornamento è stato piuttosto lento su hardware veloce in colocation. Non sono sicuro del motivo, ma è sicuramente qualcosa da tenere a mente.
Sì, ti consiglio di aggiungere una nota nel changelog per avvisare gli utenti che questo aggiornamento richiederà probabilmente molto più tempo rispetto alla maggior parte degli altri, e di non interromperlo o compiere azioni drastiche, poiché è previsto.
Il mio sito locale non aveva molti post ed era comunque piuttosto lento. Non lento di 40 minuti, ma notevolmente più lento rispetto ai precedenti aggiornamenti, forse di 3-4 volte?
Grazie @Wingtip, pensavo stesse succedendo solo a noi!
In realtà, ho dovuto annullare la ricostruzione e riavviare l’app perché pensavo si fosse bloccata su quella query che hai menzionato. Abbiamo 6 milioni di post e dopo circa 45 minuti non era ancora completata, quindi immagino dovrò prepararmi a una ricostruzione di almeno un’ora e avvisare i nostri utenti prima.
Ho appena preso il cronometro e testato una ricostruzione (sito con circa 1 milione di post) dalla versione 2.6.0b1 alla b2; dall’inizio alla fine, ci sono voluti 170 secondi.
Questa è la mia seconda ricostruzione di oggi, passando da b1 a b2, e sembra tutto molto fluido, senza differenze notevoli nella velocità di costruzione.
Nota: Aggiorniamo sempre da riga di comando e non utilizziamo l’interfaccia utente.
Anche io non uso il gestore Docker e preferisco ricostruire da riga di comando. È meglio così per vedere i log nel caso qualcosa vada storto. Penso anche che sia più veloce.
Ho (scioccamente) aggiornato tramite la console web, quindi non ho avuto un log aggiornato per tutto il tempo. L’ultima volta che commetto questo errore.
Avevo un sito di grandi dimensioni che falliva ripetutamente durante l’avvio. Si tratta di un’installazione a due container, quindi il container vecchio continuava a funzionare mentre avveniva la migrazione durante il bootstrap. Alla fine ho risolto il problema attivando SKIP_POST_DEPLOYMENT_MIGRATIONS=1 per il bootstrap e poi eseguendo le migrazioni dopo che il nuovo container era stato avviato. Con SKIP_POST_DEPLOYMENT_MIGRATIONS=1 nella sezione ENV, la migrazione è stata molto rapida; il sito ha quindi potuto funzionare normalmente (sebbene forse più lentamente) mentre le migrazioni venivano eseguite, il che ha richiesto, credo, oltre 20 minuti.
Penso, anche se non l’ho ancora testato, che utilizzare lo stesso trucco possa funzionare per minimizzare i tempi di inattività anche durante un’installazione a singolo container. Se ho ragione, quello che dovresti fare è:
aggiungere SKIP_POST_DEPLOYMENT_MIGRATIONS=1 al tuo app.yml
./launcher rebuild app
./launcher enter app
SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate
annullare la modifica in app.yml, a meno che tu non intenda ricordare di eseguire le migrazioni dopo ogni aggiornamento
forse eseguire di nuovo il rebuild per assicurarti di non avere problemi mentre ricordi ancora cosa potrebbe aver rotto il tuo sito; tra 4 mesi, quando riproverai, non avrai idea di cosa sia successo e sarà difficile per chiunque indovinare qual era il problema
Se esistesse un modo per far sì che ./launcher passi SKIP_POST_DEPLOYMENT_MIGRATIONS=1 senza richiedere una modifica al file app.yml, renderebbe tutto meno macchinoso per chi ha difficoltà con l’editing.
Se riesco a portare a termine il lavoro su questo argomento, come penso farò, creerò un nuovo topic per riportare ciò che ho scoperto. Anche se il fumo mi ha costretto a rinchiudermi in una stanza dove non ho il mio grande monitor. (Non bastava la pandemia?! Dobbiamo avere anche il fumo? E non sono nemmeno particolarmente vicino al dannato incendio.)
Che notizia fantastica! (Oggi due altri progetti hanno preso il sopravvento e, in qualche modo, la mia istanza multisito non funziona più e non collabora bene con S3. :gatto_che_piange:) Grazie mille.
C’è una ragione tecnica per cui le modifiche al database dopo l’aggiornamento devono essere bloccanti per impostazione predefinita? Esiste un modo per modificare questo comportamento in modo che, nei futuri aggiornamenti, il sito venga ripristinato rapidamente e le operazioni successive all’aggiornamento vengano eseguite in background?
A mio avviso, tutto ciò che è essenziale per il funzionamento dell’applicazione aggiornata, come le istruzioni DDL, dovrebbe far parte dell’aggiornamento stesso e non degli script post-aggiornamento.
Modifica: nel frattempo ho ucciso il processo per riportare il sito online per i nostri utenti. Ma deve esserci un modo migliore per eseguire questo aggiornamento.
