Discourse v3.0.6 から v3.1.1 へのアップグレードエラー - Bookmark:Class の register_bookmarkable が未定義

UIで設定した設定をデータベースに永続化せずに失う可能性があるということでしょうか?他にバックアップおよび復元されるものがあるかどうかはわかりません。

Bitnamiから標準的なインストールに移行することを検討したほうが良いかもしれません。あなたの問題は「データベース移行のバグ」によって引き起こされているのではなく、Bitnami固有の問題です。

「いいね!」 2

Kubernetes の標準インストールはまだありますか?

Kubernetesで手動インストールは可能ですか?もし可能であれば、その方法で標準的なインストールができます。(試したことがないので、Kubernetesの仕組みはわかりません)

標準インストールと、Bitnami Helmチャートの独立した非公式な性質について、おっしゃることはよく理解できます。Discourse 自体に欠陥があることを示唆するつもりはありませんでした。Bitnami を使用するという私の選択は、Bitnami チャートの問題をトラブルシューティングするコストと、公式にサポートされているインストールに基づいて独自の Helm チャートを開発し、その問題に対処するコストを比較した計算に基づいています。

検討しましたが、「メインパス」にとどまるために、デフォルトのチャート設定の変更を避けたいと考えています。とはいえ、既存のデータベースを保持したまま、Discourse サーバーのみを v3.2.0 にアップグレードしようと、Deployment のイメージタグを上書きして試しましたが、移行は失敗しました。

kubectl exec を使用して、Discourse 自体が生成した SQL ダンプファイルを使用して postgres コンテナに手動でデータベースをドロップおよび復元しようとしましたが、sidebar_sections テーブルに関するエラーで失敗します。直近では、新しい VM を作成し、標準インストール方法に従って Discourse v3.3.0 をインストールしました。バックアップの復元を試みたところ、同じエラーが発生しました。

私の結論は、本番環境のバックアップアーカイブは Discourse 自体によって生成されたものですが、私の本番インスタンス v3.0.6 のデータベース構造が、Discourse が期待するものと何らかの形で異なっており、移行がエラーを引き起こしているということです。もしそうであれば、私の選択肢については悲観的です。現時点で思いつく唯一のアイデアは、復元プロセスの db マイグレーション段階で DuplicateTable エラーを引き起こしているテーブルを削除するために、SQL ダンプファイルをハッキングすることです。

BitnamiのHelmチャートを使用したい場合は、Bitnamiのサポートを使用する必要があります。

「いいね!」 1

この問題で私と同じように何時間も立ち往生する人を救うことを願って、Bitnami Helmチャート(v11からv12)を使用している状況で、Discourse v3.0.6からv3.2.0にアップグレードできたプロセスを以下に示します。上記のコメントからさらに免責事項は不要だと思われますが、この問題はBitnamiのHelmチャートとそのカスタムイメージのバグによるものであり、公式Discourseリリースには影響しません。

以下の手順は、アップグレードをナビゲートする方法を示しています。「本番サイト」とは、アップグレード対象のDiscourseサイトのHelmチャートリリースを指し、「移行サイト」とは、discourse-dev名前空間に並行してデプロイされた一時的なチャートリリースを指します。

本番サイト

  1. Backups管理パネル /admin/backups で、本番フォーラムを読み取り専用モードに設定します。
  2. Backups管理パネルを使用してバックアップを作成します。バックアップアーカイブをローカルにダウンロードします。

移行サイト

  1. Bitnamiチャートv12.6.2(Discourse v3.2.0)の新規インスタンスをインストールします。DiscourseサーバーのDeploymentをゼロにスケールします。

    $ kubectl scale -n discourse-dev deployment discourse --replicas 0
    deployment.apps/discourse scaled
    
  2. 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
    
  3. データベースポッドにコピーして実行します。

    $ 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
    
  4. バックアップアーカイブを展開し、SQLダンプファイルをデータベースポッドにコピーして適用します。

    $ 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'
    
  5. Discourseポッドを起動します。

    $ kubectl scale -n discourse-dev deployment discourse --replicas 1
    deployment.apps/discourse scaled
    
  6. ログを監視し、アップグレードを妨げているテーブルを削除します。

    $ 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
    
  7. データベースマイグレーションが失敗するのを監視し、マイグレーションが成功するまで関連するテーブルを手動で削除します。

    $ 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; \
        \"'
    
  8. アップロードフォルダのバックアップを復元します。

    $ 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/'
    
  9. 何らかの理由で、プラグインが自動的にダウンロードおよびインストールされませんでした。これを手動で行い、プラグインの機能を確認してください。

    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
    
  10. Backups管理パネルを使用して、新しく復元されたサイトのバックアップを作成します。

本番サイト

  1. 元のデプロイメントを削除し、PV/PVCをパージします。
  2. Bitnamiチャートv12.6.2(Discourse v3.2.0)の新規インスタンスをインストールします。
  3. https://$BASE_URL/u/admin-login を使用して、メールリンクでログインします。
  4. Backups管理パネルを使用して、バックアップアーカイブをアップロードして復元します。
「いいね!」 1