Haben Sie eine Neuinstallation ohne Wiederherstellung versucht, aber die Verbindung zu Ihrer vorhandenen Backend-Datenbank hergestellt?
Ich schätze, das bedeutet potenziell den Verlust aller in der Benutzeroberfläche vorgenommenen Einstellungen, die nicht in der Datenbank gespeichert wurden? Ich bin mir nicht sicher, was sonst noch gesichert und wiederhergestellt wird.
Vielleicht sollten Sie in Erwägung ziehen, von Bitnami zu einer tatsächlichen Standardinstallation zu wechseln. Ihre Probleme werden nicht durch „Fehler bei der Datenbankmigration“ verursacht, sondern sind Bitnami-spezifisch.
Gibt es eine Standardinstallation für Kubernetes?
Ermöglicht Kubernetes eine manuelle Installation? Wenn ja, könnten Sie auf diese Weise eine Standardinstallation durchführen. (Ich habe es nie versucht, daher weiß ich nicht, wie Kubernetes funktioniert)
Ich höre Sie laut und deutlich bezüglich der Vorteile der Standardinstallation und der unabhängigen und nicht genehmigten Natur des Bitnami Helm Charts. Ich hatte nicht vor anzudeuten, dass die Schuld bei Discourse selbst liegt. Meine Entscheidung, Bitnami zu verwenden, hängt weiterhin von einer Kostenkalkulation ab, die die Kosten für die Fehlerbehebung bei Problemen mit dem Bitnami Chart mit den Kosten für die Entwicklung meines eigenen äquivalenten Helm Charts auf Basis der offiziell unterstützten Installation und anschließender Fehlerbehebung vergleicht.
Ich habe es in Erwägung gezogen, aber ich versuche, Änderungen an den Standard-Chart-Einstellungen zu vermeiden, um auf dem „Hauptweg“ zu bleiben. Dennoch habe ich versucht, nur den Discourse-Server auf v3.2.0 zu aktualisieren, indem ich das Deployment-Image-Tag überschrieben habe, während die vorhandene Datenbank beibehalten wurde, um zu sehen, ob die Migration erfolgreich wäre; sie schlug immer noch fehl.
Ich habe versucht, die Datenbank manuell über kubectl exec in den Postgres-Container zu löschen und wiederherzustellen, indem ich die von Discourse selbst generierte SQL-Dumpdatei verwendet habe, aber dies schlägt mit dem Fehler bezüglich der Tabelle sidebar_sections fehl. Zuletzt habe ich eine neue VM erstellt und die Standardinstallationsmethode befolgt, um Discourse v3.3.0 zu installieren. Als ich versuchte, ein Backup wiederherzustellen, trat derselbe Fehler auf.
Meine Schlussfolgerung ist, dass, obwohl das Produktions-Backup-Archiv von Discourse selbst generiert wurde, die Datenbankstruktur meiner Produktionsinstanz v3.0.6 irgendwie von dem abweicht, was Discourse erwartet, was zu Fehlern bei den Migrationen führt. Wenn dies der Fall ist, bin ich pessimistisch bezüglich meiner Optionen. Die einzige Idee, die ich im Moment habe, ist, mit der SQL-Dumpdatei im Backup-Archiv zu hacken, um Tabellen zu entfernen, die die DuplicateTable-Fehler verursachen, die die Datenbankmigrationsphase des Wiederherstellungsprozesses betreffen.
Wenn Sie die Helm-Charts von Bitnami verwenden möchten, müssen Sie deren Support nutzen.
In der Hoffnung, dass dies jemandem Stunden erspart, die er mit diesem Problem verbracht hat, hier ist der Prozess, der es mir endlich ermöglicht hat, von Discourse v3.0.6 auf v3.2.0 im Kontext der Verwendung des Bitnami Helm-Charts (v11 auf v12) zu aktualisieren. Obwohl weitere Haftungsausschlüsse angesichts der obigen Kommentare nicht notwendig sein sollten, ist dieses Problem auf einen Fehler im Bitnami Helm-Chart und deren benutzerdefinierten Images zurückzuführen; das Problem beeinträchtigt keine offiziellen Discourse-Releases.
Die folgenden Anweisungen zeigen, wie die Aktualisierung durchgeführt wird. Die „Produktionsseite“ ist eine Helm-Chart-Veröffentlichung der zu aktualisierenden Discourse-Seite, und die „Migrationsseite“ bezieht sich auf eine temporäre Chart-Veröffentlichung, die parallel im Namespace discourse-dev bereitgestellt wird.
/admin/backups in den schreibgeschützten Modus.Installieren Sie eine frische Instanz des Bitnami-Charts v12.6.2 (Discourse v3.2.0). Skalieren Sie die Discourse-Server-Bereitstellung auf null.
$ kubectl scale -n discourse-dev deployment discourse --replicas 0
deployment.apps/discourse scaled
Erstellen Sie die SQL-Datei 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
Kopieren Sie die Datei in den Datenbank-Pod und führen Sie sie aus:
$ 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
Entpacken Sie das Backup-Archiv, kopieren Sie die SQL-Dump-Datei in den Datenbank-Pod und wenden Sie sie an:
$ 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'
Starten Sie den Discourse-Pod.
$ kubectl scale -n discourse-dev deployment discourse --replicas 1
deployment.apps/discourse scaled
Beobachten Sie die Protokolle und löschen Sie die Tabellen, die das Upgrade verhindern:
$ 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
Beobachten Sie, während die Datenbankmigrationen fehlschlagen, und löschen Sie manuell die entsprechenden Tabellen, bis die Migrationen erfolgreich sind:
$ 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; \
"'
Stellen Sie das Uploads-Ordner-Backup wieder her:
$ 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/'
Aus irgendeinem Grund wurden die Plugins nicht automatisch heruntergeladen und installiert. Tun Sie dies manuell und überprüfen Sie die Funktionalität der 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
Erstellen Sie ein Backup der neu wiederhergestellten Seite über das Admin-Panel für Backups.
https://$BASE_URL/u/admin-login, um sich über den E-Mail-Link anzumelden.