Hai provato una nuova installazione senza ripristino, ma collegandoti al tuo database backend esistente?
Suppongo che ciò significhi potenzialmente perdere qualsiasi impostazione effettuata nell’interfaccia utente non salvata nel database? Non sono sicuro di cos’altro venga salvato e ripristinato.
Forse dovresti considerare di abbandonare Bitnami per un’installazione standard effettiva. I tuoi problemi non sono causati da “bug nella migrazione del database”, sono specifici di Bitnami.
Esiste già un’installazione standard per Kubernetes?
Kubernetes consente di eseguire un’installazione manuale? Se sì, potresti eseguire un’installazione standard in quel modo. (Non ci ho mai provato, quindi non so come funziona Kubernetes)
Sento forte e chiaro i vantaggi dell’installazione standard e la natura indipendente e non sanzionata del chart Helm di Bitnami. Non intendevo insinuare che la colpa sia di Discourse stesso. La mia scelta di utilizzare Bitnami continua a dipendere da un calcolo che confronta il costo della risoluzione dei problemi con il chart Bitnami e il costo dello sviluppo del mio equivalente chart Helm basato sull’installazione ufficialmente supportata e quindi della risoluzione dei problemi con esso.
L’ho considerato, ma sto cercando di evitare modifiche alle impostazioni predefinite del chart per rimanere “sul percorso principale”. Detto questo, ho tentato di aggiornare solo il server Discourse a v3.2.0 sovrascrivendo il tag dell’immagine di Deployment, mantenendo il database esistente, per vedere se la migrazione avrebbe avuto successo; è comunque fallita.
Ho provato a eliminare e ripristinare manualmente il database tramite kubectl exec al container postgres utilizzando il file di dump SQL generato da Discourse stesso, ma questo fallisce con l’errore relativo alla tabella sidebar_sections. Più recentemente, ho creato una nuova VM e ho seguito il metodo di installazione standard per installare Discourse v3.3.0. Quando ho tentato un ripristino del backup, si è verificato lo stesso errore.
La mia conclusione è che, sebbene l’archivio di backup di produzione sia stato generato da Discourse stesso, la struttura del database della mia istanza di produzione v3.0.6 è in qualche modo diversa da ciò che Discourse si aspetta, causando errori nelle migrazioni. Se questo è il caso, sono pessimista riguardo alle mie opzioni. L’unica idea che ho al momento è iniziare a modificare il file di dump SQL nell’archivio di backup per rimuovere le tabelle che causano gli errori DuplicateTable durante la fase di migrazione del database del processo di ripristino.
Se si desidera utilizzare i grafici Helm di Bitnami, è necessario utilizzare il loro supporto.
Nella speranza che ciò possa salvare qualcuno dal dibattersi per molte ore come ho fatto io in questa situazione, ecco il processo che mi ha finalmente permesso di eseguire l’aggiornamento da Discourse v3.0.6 a v3.2.0 nel contesto dell’utilizzo del chart Helm di Bitnami (da v11 a v12). Sebbene ulteriori avvisi non dovrebbero essere necessari sulla base dei commenti precedenti, questo problema è dovuto a un bug nel chart Helm di Bitnami e nelle loro immagini personalizzate; il problema non influisce sulle release ufficiali di Discourse.
Le istruzioni seguenti mostrano come navigare l’aggiornamento. Il “sito di produzione” è una release del chart Helm del sito Discourse in fase di aggiornamento, e “sito di migrazione” si riferisce a una release temporanea del chart distribuita in parallelo nello namespace discourse-dev.
Installa una nuova istanza del chart Bitnami v12.6.2 (Discourse v3.2.0). Scala il Deployment del server Discourse a zero.
$ kubectl scale -n discourse-dev deployment discourse --replicas 0
deployment.apps/discourse scaled
Crea il file SQL db_init.sql:
cat > /tmp/db_init.sql << EOF
DROP DATABASE bitnami_application;
CREATE DATABASE bitnami_application;
GRANT ALL PRIVILEGES ON DATABASE bitnami_application TO bn_discourse;
CREATE EXTENSION hstore;
CREATE EXTENSION pg_trgm;
ALTER database bitnami_application owner to bn_discourse ;
EOF
Copia nel pod del database ed esegui:
$ kubectl cp -n discourse-dev db_init.sql discourse-dev-postgresql-0:/tmp/
$ kubectl exec -n discourse-dev -it discourse-dev-postgresql-0 -- bash -c \
'PGPASSWORD=$POSTGRES_PASSWORD psql -U postgres \
< /tmp/db_init.sql'
DROP DATABASE
CREATE DATABASE
GRANT
ERROR: extension "hstore" already exists
ERROR: extension "pg_trgm" already exists
ALTER DATABASE
Estrai l’archivio di backup, copia il file di dump SQL nel pod del database e applicalo:
$ ls
discourse-2024-03-04-143102-v20230119094939.tar.gz
$ tar xvf discourse-2024-03-04-143102-v20230119094939.tar.gz
$ gunzip dump.sql.gz
$ kubectl cp -n discourse-dev dump.sql discourse-dev-postgresql-0:/tmp/
$ kubectl exec -n discourse-dev -it discourse-dev-postgresql-0 -- bash -c \
'PGPASSWORD=$POSTGRES_PASSWORD psql -U bn_discourse \
--dbname bitnami_application \
< /tmp/dump.sql'
Avvia il pod di Discourse.
$ kubectl scale -n discourse-dev deployment discourse --replicas 1
deployment.apps/discourse scaled
Monitora i log ed elimina le tabelle che impediscono l’aggiornamento:
$ kubectl logs --prefix -f -n discourse-dev -c discourse -l app.kubernetes.io/name=discourse
$ kubectl logs --prefix -f -n discourse-dev -l app.kubernetes.io/name=postgresql
Osserva mentre le migrazioni del database falliscono ed elimina manualmente le tabelle pertinenti finché le migrazioni non hanno successo:
$ kubectl exec -n discourse-dev -it discourse-dev-postgresql-0 -- bash -c \
'PGPASSWORD=$POSTGRES_PASSWORD psql -U bn_discourse --dbname bitnami_application -c " \
DROP TABLE sidebar_sections; \
DROP TABLE sidebar_urls; \
DROP TABLE chat_threads; \
DROP TABLE form_templates; \
DROP TABLE category_settings; \
DROP TABLE category_form_templates; \
DROP TABLE theme_svg_sprites; \
DROP TABLE user_chat_thread_memberships; \
DROP TABLE summary_sections; \
"'
Ripristina il backup della cartella uploads:
$ PODNAME=$(kubectl get pod -n discourse-dev -l app.kubernetes.io/name=discourse --output=jsonpath={.items..metadata.name} | cut -f1 -d' ')
$ kubectl cp -n discourse-dev -c discourse uploads $PODNAME:/bitnami/discourse/public/
$ kubectl exec -n discourse-dev -c discourse $PODNAME -- bash -c 'chown -R 999:0 /bitnami/discourse/public/uploads/'
Per qualche motivo, i plugin non sono stati scaricati e installati automaticamente. Fallo manualmente e verifica la funzionalità dei plugin.
root@discourse-54c6d6fb7c-z9285:/bitnami/discourse/plugins$ git clone https://github.com/discourse/discourse-oauth2-basic
root@discourse-54c6d6fb7c-z9285:/bitnami/discourse/plugins$ git clone https://github.com/discourse/discourse-math
root@discourse-54c6d6fb7c-z9285:/bitnami/discourse/plugins$ chown -R 999:0 discourse-oauth2-basic discourse-math
Crea un backup del sito appena ripristinato utilizzando il pannello di amministrazione Backup.
https://$BASE_URL/u/admin-login per accedere tramite link email.