Hai qualche altro dettaglio? Sto riscontrando lo stesso problema.
1 Mi Piace
Per chi sta riscontrando lo stesso problema, ecco il riepilogo (generato dall’IA) di quello che ho fatto:
Avvia temporaneamente PG15 → Esegui il dump del database → Usa PG18 → Ripristina il dump
1 Mi Piace
Quindi sì, questo aggiornamento è basato su immagini.
Quindi anche se scegli di installare una vecchia versione di Discourse, l’immagineforcerà comunque un aggiornamento alla versione 18?
Capito.
1 Mi Piace
Vedo che l’hai risolto, ma il metodo suggerito da ChatGPT, sebbene abbia corretto l’errore, ha comunque cancellato il mio database, quindi essenzialmente nessun account, nessuna discussione o messaggio.
Fortunatamente si trattava di un forum di sviluppo relativamente nuovo, quindi non è stata persa troppa roba.
2 Mi Piace
Si è prestata grande attenzione per assicurarsi che ciò non accadesse oggi. Dopo ogni passaggio, mi confermava che non sarebbe stato cancellato nulla, e avevo l’impressione che avessimo verificato tre volte che tutti i dati fossero stati migrati prima di concordare la cancellazione delle cose che non ci servivano più.
Ma se fosse andato tutto storto, l’unico dato che mi sarebbe mancato sarebbe stata la configurazione del componente del tema.
1 Mi Piace
Ciao, io ho un forum con database piuttosto grande (circa 80 GB), per il passaggio da 13 a 15, ho cambiato server, fatto nuova installazione e ripristinato.
Consigliate lo stesso passaggio? (ho provato l’upgrade ma ho errori di collation)
Più indietro nella discussione lo staff ha dichiarato:
Quindi, sì, è un’opzione
Hai già detto:
Errori di ordinamento? Che versione è l’attuale Discourse?
Forse pubblica gli errori che hai incontrato / l’output della console
ma non sei rimasto senza spazio (raccomandato 2 x dimensione del database esistente) ?
Ciao, spazio ne ho (250 gb liberi) errore era “collation mismatch” ma mi sa che non ho le stringhe utf nel file app.yml
1 Mi Piace
Cerciamo di fornire impostazioni predefinite ragionevoli nelle immagini discourse_docker, ma non è possibile prevedere ogni possibile caso d’uso. Sentiti libero di personalizzare le tue immagini per mantenere versioni precedenti, se lo preferisci.
In una certa misura, le versioni delle dipendenze riflettono i nostri requisiti di hosting: utilizziamo l’immagine di base internamente. Ciò significa che non dovrebbe diventare troppo obsoleta, ma implica anche che possiamo mantenere solo un numero limitato di combinazioni.
È un metodo perfettamente valido se ti senti più a tuo agio con esso.
Se l’avviso viene generato durante la preparazione del dump del vecchio DB, non c’è motivo di preoccuparsi. Stiamo eseguendo il server solo contro la vecchia directory dei dati allo scopo di eseguire pg_dump. Quando il dump viene ripristinato nel nuovo server, gli indici vengono ricreati.
Il motivo per cui vedi questo è che negli ultimi giorni abbiamo rilasciato una nuova versione dell’immagine di base che aggiorna da Debian Bookworm a Trixie, cambiando la versione di glibc. Le impostazioni locali basate sul provider libc (che probabilmente stavi usando) non sono stabili tra gli aggiornamenti di glibc, quindi quando lo script di aggiornamento avvia un server Postgres per eseguire il dump dei tuoi vecchi dati, visualizza avvisi di disallineamento dell’ordinamento.
Il disallineamento dell’ordinamento è l’unico motivo per cui stiamo eseguendo il dump e il ripristino invece di eseguire pg_upgrade. Una volta che il tuo DB utilizza C.UTF-8 con il provider builtin, gli aggiornamenti a glibc non influenzeranno più gli ordinamenti.
2 Mi Piace
Ho eseguito l’aggiornamento stasera ed è andato secondo i piani. Ho ricevuto gli stessi avvisi sulla collation del database, ma sembra che dovremmo ignorarli. Grazie.
2 Mi Piace
Ho provato a inserire in app.yml
app.yml
templates:
- “templates/postgres.15.template.yml”
- “templates/redis.template.yml”
- “templates/web.template.yml”
- “templates/web.ratelimited.template.yml”
Per posticipare l’upgrade, ma ho questo errore
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
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.
Sembra che il contenitore base sia sbagliato, credo. Hai eseguito un ./launcher rebuild? Dovrebbe fare un git pull, ma potresti provare a eseguire un git pull per vedere se cambia qualcosa.
1 Mi Piace