Problema nella ricostruzione a causa del lento arresto del database

Questo aggiornamento consigliato è fallito e non ha ripristinato il mio forum dopo averlo bloccato. Sto eseguendo discourse-doctor ora per cercare di risolverlo e, se anche questo fallisce, ho eseguito uno snapshot della VM.

Output:

2023-04-19 18:28:31.298 UTC [42] LOG:  received fast shutdown request
2023-04-19 18:28:33.651 UTC [65] LOG:  shutting down
2023-04-19 18:28:33.974 UTC [42] LOG:  database system is shut down


FAILED
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 59 exit 2>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params "su postgres -c 'psql $db_name -c \\\"alter schema public owner to $db_user;\\\"'"
bootstrap failed with exit code 2
** 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.
c13e1ba313de8fc84f6e2fb0f88197a908803c39791283effb8c82f55b56b6dc
Command exited with non-zero status 1
1.85user 1.84system 3:21.56elapsed 1%CPU (0avgtext+0avgdata 36996maxresident)k
197608inputs+368outputs (1133major+96509minor)pagefaults 0swaps

Sei sul ramo beta?

Puoi provare a riavviare il tuo container con

 ./launcher start app

ma è quello che dovrebbe fare discourse-doctor.

Dovrai fornire altro output poiché l’errore si trova sopra ciò che hai incluso.

2 Mi Piace

Sì, siamo sul ramo beta. Eseguo sempre all’interno di nohup, quindi ho il log completo.

Discourse-doctor sta ancora elaborando, ma non è ancora fallito quindi ho speranza.

https://pastebin.mozilla.org/iw2zc5zd

Modifica: Discourse-doctor ci ha rimesso in funzione.

Praticamente ho chiesto questo, aggiornando un’ora dopo quella notifica ed essendo il primo a farlo. Nessun vero stress con quel snapshot prima, quindi ho fatto un sacrificio per il team qui, ragazzi.

1 Mi Piace
  • 2023-04-19 18:28:26.755 UTC [45] LOG: il sistema del database non è stato arrestato correttamente; ripristino automatico in corso

Se il tuo database non può arrestarsi in modo sicuro in 60 secondi, cosa che accadrà con database di grandi dimensioni su dischi più lenti, entrerà in questo stato e fallirà una ricostruzione se non riesce a ripristinarsi in 5 secondi (cosa rara dato che è grande/lento).

Questo non ha nulla a che fare con le modifiche elencate qui, ed è un problema in Discourse almeno dal 2016.

6 Mi Piace

Ahh, grazie. Forse dovrebbe aspettare più a lungo per forum più grandi come il nostro. Se si interrompe semplicemente il processo del database, sarà necessario eseguire il rollback delle transazioni dopo il riavvio e ciò può richiedere molto tempo.

La terminologia relativa a beta è alquanto confusa. La dashboard di amministrazione dice che stiamo eseguendo la beta, c’è qualcos’altro che avremmo dovuto controllare? La mia comprensione è che la beta sia raccomandata per discourse in base agli annunci di rilascio che sconsigliano l’uso del ramo stabile.

1 Mi Piace

L’impostazione predefinita è in realtà tests_passed, che è considerato pronto per la produzione.

1 Mi Piace

Quanto è grande il tuo database? È su SSD? Quanta RAM hai?

Avere un contenitore dati separato richiederebbe meno riavvii del database.

Quando è stato deciso di attendere 60 secondi per uno spegnimento sicuro? Quante installazioni sono ora molto più grandi di quanto fosse normale allora?

Idealmente, questa attesa di 60 secondi dovrebbe essere più un’attesa a ciclo chiuso, con un limite. Sembra che il limite dovrebbe essere più alto, se ora ci sono molte istanze là fuori che sono ora vulnerabili.

2 Mi Piace

È 105 GB, su SSD, VM da 16 GB e ho dato a postgres un buffer pool da 8 GB.

Penso di aver visto che risale almeno al 2016. Ma le cose sono cambiate. MODIFICA: Ecco un nuovo commit.

Non credo che molte su un’installazione standard, dato che è così da quasi l’inizio.

Uh, sì. Quello è un grande database. Sospetto che poche persone abbiano un database così grande che non sia su RDS o almeno in un container separato. Dovresti probabilmente considerare di passare a un’installazione a 2 container.

1 Mi Piace

Lo prenderemo in considerazione, il metodo di commutazione è documentato? E ci sono altri vantaggi che l’aumento del timer di 60 secondi non fornirebbe?

L’ho aumentato a 10 minuti ieri

4 Mi Piace

Ottimo, pensavo stesse pubblicando il commit originale nel 2016. Quindi ci sono vantaggi per noi?

Puoi consultare Move from standalone container to separate web and data containers

Puoi creare un nuovo container mentre quello vecchio continua a funzionare. Non è necessario arrestare il database per creare un nuovo container.

Ora c’è una finestra di 10 minuti per arrestare postgres, il che dovrebbe risolvere il tuo attuale problema. Una volta che farai un’altra ricostruzione, avrai 10 minuti invece di uno.

Quel tizio ha appena creato una nuova istanza di due container e ha ripristinato dal backup. Noi non lo faremo sicuramente senza un buon motivo, ho dovuto farlo solo per evitare i requisiti di spazio su disco per l’aggiornamento PG13 circa 2 mesi fa.

Se non sei su PG13, dovresti risolvere il problema.

Creerei un nuovo server e mi trasferirei lì.

Ora siamo, quello era in definitiva inevitabile! Oltre al DB, dovevamo anche passare dalla 18.04LTS non supportata.

1 Mi Piace

Con un database di queste dimensioni dovresti spostarlo in un container dedicato.

Accelera enormemente le ricostruzioni e semplifica tutto per te.

1 Mi Piace

Se ci sono documentazione su come farlo senza una ricostruzione completa da zero, allora ripristinare i backup lo prenderemo sicuramente in considerazione.

Quindi vuoi migrare rapidamente a container web e dati separati

1 Mi Piace