Você já tentou uma nova instalação sem restauração, mas conectando-se ao seu banco de dados de backend existente?
Acho que isso significa potencialmente perder quaisquer configurações feitas na interface do usuário que não foram persistidas no banco de dados? Não tenho certeza do que mais é copiado e restaurado.
Talvez você devesse considerar mudar do Bitnami para uma instalação padrão real. Seus problemas não são causados por “bugs na migração do banco de dados”, eles são específicos do Bitnami.
Já existe uma instalação padrão para o Kubernetes?
O Kubernetes permite que você faça uma instalação manual? Se sim, você poderia fazer uma instalação padrão dessa forma. (Eu nunca tentei, então não sei como o Kubernetes funciona)
Eu ouvi você alto e claro sobre as vantagens da instalação padrão e a natureza independente e não sancionada do Helm chart do Bitnami. Eu não tive a intenção de insinuar que a culpa é do próprio Discourse. Minha escolha de usar o Bitnami continua dependendo de um cálculo comparando o custo de solucionar problemas com o Helm chart do Bitnami e o custo de desenvolver meu próprio Helm chart equivalente com base na instalação oficialmente suportada e, em seguida, solucionar problemas com ele.
Eu considerei isso, mas estou tentando evitar modificações nas configurações padrão do Helm chart para permanecer “no caminho principal”. Dito isso, eu tentei atualizar apenas o servidor Discourse para a v3.2.0 substituindo a tag da imagem do Deployment, enquanto mantinha o banco de dados existente, para ver se a migração seria bem-sucedida; ainda falhou.
Eu tentei remover e restaurar manualmente o banco de dados via kubectl exec para o container postgres usando o arquivo de dump SQL gerado pelo próprio Discourse, mas isso falha com o erro sobre a tabela sidebar_sections. Mais recentemente, criei uma nova VM e segui o método de instalação padrão para instalar o Discourse v3.3.0. Quando tentei uma restauração de backup, o mesmo erro ocorreu.
Minha conclusão é que, embora o arquivo de backup de produção tenha sido gerado pelo próprio Discourse, a estrutura do banco de dados da minha instância de produção v3.0.6 é de alguma forma diferente do que o Discourse espera, causando erros nas migrações. Se for esse o caso, sou pessimista sobre minhas opções. A única ideia que tenho no momento é começar a mexer no arquivo de dump SQL no arquivo de backup para remover tabelas que causam os erros de DuplicateTable durante o estágio de migração do banco de dados do processo de restauração.
Se você quiser usar os Helm Charts do Bitnami, precisará usar o suporte deles.
Na esperança de que isso poupe alguém de se debater por tantas horas quanto eu nesta situação, aqui está o processo que finalmente me permitiu atualizar do Discourse v3.0.6 para o v3.2.0 no contexto de usar o Bitnami Helm chart (v11 para v12). Embora mais ressalvas não devam ser necessárias com base nos comentários acima, este problema é devido a um bug no Helm chart da Bitnami e suas imagens personalizadas; o problema não afeta os lançamentos oficiais do Discourse.
As instruções abaixo mostram como navegar pela atualização. O “site de produção” é um lançamento do Helm chart do site do Discourse que está sendo atualizado, e “site de migração” refere-se a um lançamento temporário do chart implantado em paralelo no namespace discourse-dev.
Instale uma nova instância do Bitnami chart v12.6.2 (Discourse v3.2.0). Redimensione o Deployment do servidor Discourse para zero.
$ kubectl scale -n discourse-dev deployment discourse --replicas 0
deployment.apps/discourse scaled
Crie o arquivo 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
Copie para o pod do banco de dados e execute:
$ 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
Extraia o arquivo de backup, copie o arquivo de dump SQL para o pod do banco de dados e aplique:
$ 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'
Inicie o pod do Discourse.
$ kubectl scale -n discourse-dev deployment discourse --replicas 1
deployment.apps/discourse scaled
Observe os logs e exclua as tabelas que estão impedindo a atualização:
$ 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
Observe enquanto as migrações do banco de dados falham e exclua manualmente as tabelas relevantes até que as migrações sejam bem-sucedidas:
$ 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; \
\"'
Restaure o backup da pasta de 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/'
Por algum motivo, os plugins não foram baixados e instalados automaticamente. Faça isso manualmente e verifique a funcionalidade dos 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
Crie um backup do site recém-restaurado usando o painel de administração Backups.
https://$BASE_URL/u/admin-login para fazer login por link de e-mail.