Avez-vous essayé une nouvelle installation sans restauration, mais en vous connectant à votre base de données backend existante ?
Je suppose que cela signifie potentiellement perdre tous les paramètres effectués dans l’interface utilisateur qui ne sont pas sauvegardés dans la base de données ? Je ne suis pas sûr de ce qui d’autre est sauvegardé et restauré.
Peut-être devriez-vous envisager de passer de Bitnami à une installation standard réelle. Vos problèmes ne sont pas causés par des « bogues dans la migration de la base de données », ils sont spécifiques à Bitnami.
Existe-t-il une installation standard pour Kubernetes ?
Kubernetes permet-il une installation manuelle ? Si oui, vous pourriez faire une installation standard de cette façon. (Je n’ai jamais essayé, donc je ne sais pas comment fonctionne Kubernetes)
J’entends parfaitement les avantages de l’installation standard et la nature indépendante et non sanctionnée du chart Helm de Bitnami. Je n’avais pas l’intention de laisser entendre que la faute incombait à Discourse lui-même. Mon choix d’utiliser Bitnami continue de dépendre d’un calcul comparant le coût de dépannage des problèmes avec le chart Bitnami et le coût de développement de mon propre chart Helm équivalent basé sur l’installation officiellement prise en charge, puis de dépannage des problèmes avec celui-ci.
Je l’ai envisagé, mais j’essaie d’éviter les modifications des paramètres par défaut du chart pour rester « sur le chemin principal ». Cela dit, j’ai tenté de mettre à niveau uniquement le serveur Discourse vers la version 3.2.0 en remplaçant la balise d’image du déploiement, tout en conservant la base de données existante, pour voir si la migration réussirait ; cela a toujours échoué.
J’ai essayé de supprimer et de restaurer manuellement la base de données via kubectl exec dans le conteneur postgres en utilisant le fichier de vidage SQL généré par Discourse lui-même, mais cela échoue avec l’erreur concernant la table sidebar_sections. Plus récemment, j’ai créé une nouvelle VM et suivi la méthode d’installation standard pour installer Discourse v3.3.0. Lorsque j’ai tenté une restauration de sauvegarde, la même erreur s’est produite.
Ma conclusion est que, bien que l’archive de sauvegarde de production ait été générée par Discourse lui-même, la structure de la base de données de mon instance de production v3.0.6 est d’une manière ou d’une autre différente de ce que Discourse attend, provoquant des erreurs de migration. Si tel est le cas, je suis pessimiste quant à mes options. La seule idée que j’ai pour le moment est de commencer à modifier le fichier de vidage SQL dans l’archive de sauvegarde pour supprimer les tables qui causent les erreurs DuplicateTable lors de l’étape de migration de la base de données du processus de restauration.
Si vous souhaitez utiliser les Helm Charts de Bitnami, vous devez utiliser leur support.
Dans l’espoir que cela épargne à quelqu’un des heures de tâtonnement comme moi dans cette situation, voici le processus qui m’a finalement permis de passer de Discourse v3.0.6 à v3.2.0 dans le contexte de l’utilisation du chart Helm Bitnami (v11 à v12). Bien que d’autres mises en garde ne devraient pas être nécessaires compte tenu des commentaires ci-dessus, ce problème est dû à un bug dans le chart Helm de Bitnami et leurs images personnalisées ; le problème n’affecte pas les versions officielles de Discourse.
Les instructions ci-dessous montrent comment naviguer dans la mise à niveau. Le « site de production » est une version du site Discourse à mettre à niveau déployée via le chart Helm, et le « site de migration » fait référence à une version temporaire du chart déployée en parallèle dans l’espace de noms discourse-dev.
Installez une nouvelle instance du chart Bitnami v12.6.2 (Discourse v3.2.0). Réduisez le déploiement du serveur Discourse à zéro.
$ kubectl scale -n discourse-dev deployment discourse --replicas 0
deployment.apps/discourse scaled
Créez le fichier 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
Copiez le fichier dans le pod de base de données et exécutez-le :
$ 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
Extrayez l’archive de sauvegarde, copiez le fichier de vidage SQL dans le pod de base de données et appliquez-le :
$ 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'
Lancez le pod Discourse.
$ kubectl scale -n discourse-dev deployment discourse --replicas 1
deployment.apps/discourse scaled
Surveillez les logs et supprimez les tables qui empêchent la mise à niveau :
$ 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
Regardez pendant que les migrations de base de données échouent et supprimez manuellement les tables concernées jusqu’à ce que les migrations réussissent :
$ 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; \
"'
Restaurez la sauvegarde du dossier 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/'
Pour une raison quelconque, les plugins ne se sont pas téléchargés et installés automatiquement. Faites-le manuellement et vérifiez la fonctionnalité des plugins.
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
Créez une sauvegarde du site nouvellement restauré à l’aide du panneau d’administration des sauvegardes.
https://$BASE_URL/u/admin-login pour vous connecter via le lien par e-mail.