Stiamo eseguendo Postgres v12 poiché l’aggiornamento a v13 richiede troppo spazio su disco. Sembra che la compatibilità con v12 sia stata compromessa? È intenzionale? In tal caso, significa che non potremo mai più aggiornare Discourse.
L’esecuzione di ./launcher start app ci ha riportato online, quindi al momento non si tratta di un problema in produzione, ma l’impossibilità di effettuare aggiornamenti, anche per motivi di sicurezza, sarebbe molto negativo per noi.
Dal file app.yml:
- "templates/postgres.12.template.yml"
Esecuzione di ./launcher rebuild app:
FAILED
--------------------
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/13/main/pg_hba.conf
Posizione dell'errore: /pups/lib/pups/replace_command.rb:8:in `read'
Sostituzione fallita con i parametri {"filename"=>"/etc/postgresql/13/main/pg_hba.conf", "from"=>"/^host.*all.*all.*::1\\/128.*$/", "to"=>"host all all ::/0 md5"}
0ba8112e6efa1ac2dd75af8a1da8eea0937e7aefbca2df28b22d27e9608d1479
** FALLIMENTO DEL BOOTSTRAP ** scorri verso l'alto e cerca i messaggi di errore precedenti, potrebbero essercene più di uno.
./discourse-doctor potrebbe aiutare a diagnosticare il problema.
Versione attualmente in esecuzione: 2.8.0.beta4 75b0d6df93.
Perché non esegui un backup, crei una nuova istanza di Discourse completamente fresca (che dovrebbe avere Postgres 13 come predefinito), ripristini il backup e rimappi il server nel DNS?
È meno spaventoso rispetto al lavoro fastidioso che vorrei evitare, combinato con l’annuncio al mio forum che perderanno un giorno o due di post. Idealmente, mi piacerebbe che i ragazzi di Discourse dicessero: ‘Certo che continuiamo a lavorare su PG12, è solo un bug, lo sistemeremo’.
Detto questo, non eseguiamo più PG12, quindi potremmo introdurre in qualsiasi momento nel core una sintassi SQL esclusiva per PG13+, quindi sarebbe una buona idea programmare l’aggiornamento un giorno.
Lo controllerò subito dopo aver creato un altro snapshot della mia VM.
È davvero fastidioso come PG richieda un sacco di spazio su disco per l’aggiornamento. Non ho questo problema con Oracle o MySQL, che si aggiornano direttamente sul posto.
pg_upgrade fornisce un singolo flag --link per consentire aggiornamenti in-place.
Abbiamo scelto di non utilizzarlo nel nostro script di aggiornamento del launcher “amichevole per i principianti”, poiché il 99% delle installazioni avviene su macchine virtuali cloud che possono facilmente ed economicamente espandere le dimensioni del disco.
Tuttavia, è disponibile come opzione per chi preferisce eseguire l’aggiornamento manualmente per risparmiare spazio su disco durante il processo.
Sono state fornite due soluzioni; per quanto ricordo, una richiedeva essenzialmente il triplo della dimensione dell’intero database, mentre l’altra richiedeva circa il doppio. Se è possibile farlo in-place, documentarlo sarebbe molto utile.
