Então, estou tentando migrar um site restaurando um backup de um deploy existente. A restauração falha devido à incompatibilidade de esquema (origem é mais nova que o destino).
Agora, estou revisando os endpoints admin/plugins de ambos os deploys, eles correspondem aos listados, seu status e sua versão, então estou um pouco confuso. Também tentei reinstalar todos os Temas e Componentes, caso fosse isso, e não houve mudança. Ambos os sites estão na versão 3.1.3 do aplicativo, então isso não parece ser a causa raiz neste caso.
Imagino que um plugin foi instalado no site, depois a instância foi redesplegada e o banco de dados foi preservado sem este plugin instalado, mas isso é apenas um palpite. Existe uma maneira determinística, dado uma instância ou banco de dados, de descobrir o que contribuiu para a divergência do esquema? E existe uma maneira de “reverter” ou a única maneira é fazer com que o site de destino corresponda ou seja um superconjunto?
Poderia ser que o antigo estivesse em beta ou testes passaram e não estável, então o mais recente estável é, na verdade, mais antigo?
Eu verificaria se os números de commit correspondem (se possível).
O backup é do banco de dados, então duvido que a população de plugins importe, ele simplesmente adicionará os dados do plugin, mas não os usará de fato…
Não acredito, mas é um ambiente de desenvolvimento, então tudo é possível, eu acho.
Existe algo que você conheça na tabela schema_migrations (ou no código clonado do container) que eu possa verificar manualmente e correlacionar a versão do schema com alguma alteração?
A renomeação do arquivo pode fazer com que as coisas sejam carregadas pela interface do usuário, mas eu estava usando o merger que bloqueia com base no max(schema_migrations) e estou realmente tentando evitar mexer muito nas coisas.
Parte disso está se adiantando a qualquer tarefa operacional onde incompatibilidades de versão de migração possam aparecer. É melhor entender como rastrear a versão da migração até as alterações para que, quando isso acontecer novamente, eu possa, esperançosamente, descobrir um runbook para reconciliar.
Sim, consigo ver a schema_migration máxima (mesmo apenas olhando o nome de um arquivo de backup), mas verifiquei a tabela e é apenas o valor da data. Nenhuma indicação de onde veio.
Por exemplo, o “bom” é 20230823100627 e o site é 20231022224833. Eu nem consigo encontrar arquivos para “20231022” na pasta post_migrate (ou em outro lugar no repositório).
Tenho certeza de que está bem na minha cara. E sim, estou pesquisando alterações passadas e e-mails para tentar descobrir se consigo corresponder a alguma ação após agosto, onde uma versão incorreta pode ter entrado sorrateiramente.
Neste caso, é a instância Dev para uma instância “Merge” recém-provisionada, que usarei para importar outra instância Dev como teste de um esforço de consolidação de instâncias que estamos realizando. A versão de migração de esquema em sincronia é um pré-requisito (não surpreso). Neste caso, o ambiente de destino está em 1022 e a origem é 0823. Em todos os 3.1.3 que tenho, somos 0823, então tem sido um quebra-cabeça de onde veio 1022 e é isso que estou tentando descobrir, mas não consigo encontrar um rastro.
Idealmente, você não deveria precisar manter nenhum dado em dev e deveria ser capaz de simplesmente descartar o banco de dados e executar as migrações novamente.
Para mesclar duas instâncias de dev divergentes, você normalmente mesclaria os branches de código, incluindo as migrações, e então criaria uma nova instância do zero?
Isso é em parte o motivo pelo qual existe uma boa tarefa rake para pré-popular alguns fixtures para que haja algo com o que trabalhar: rake dev:populate
Temos um banco de dados com todos os IDs de migração para mais de 400 plugins, então podemos mapeá-los facilmente para um plugin. Este vem do discourse-automation.
Heh sim, todos os animais da fazenda escaparam do celeiro há um tempo, então estou tentando colocar todo mundo de volta no curral. Ou pelo menos descobrir se é viável.
As pessoas estavam olhando o automate, mas nos outros ambientes eles nunca o haviam ativado, então ele estava disponível na lista de Plugins e nenhuma alteração de esquema havia sido feita. Então, longe do ideal, mas a dica para mim neste trabalho é verificar os repositórios de todos os plugins instalados, mesmo que estejam desativados, pois talvez eles tenham sido ativados em algum momento.
Estamos fazendo uma nova implantação removendo alguns desses plugins de P&D, além de manter um olhar muito mais atento nas entradas de plugins/db e fazer um melhor registro lá.
Sim, nós finalmente descobrimos também, olhando para o tempo de execução da instância em si, mas longe do ideal. Lição aprendida para um runbook operacional, se precisarmos. Eu apenas não verifiquei o repositório de automação na organização, pois parecia estar desabilitado e sem registro de ninguém o utilizando. Má suposição da minha parte.
@RGJ há alguma chance de esse banco de dados ser acessível publicamente em algum lugar? Usar o sistema de arquivos da instância “funciona”, mas fica mais complicado do que eu gostaria.
Sim, eu estava pesquisando no próprio repositório do discourse em vez de varrer o mundo, pois não tinha certeza se apareceria. Pesquisar sem um escopo é muito caro, mas não fui até a Organização para ver se havia resultados para os esforços oficiais do Discourse.
Temos 3 ou 4 instâncias do Discourse que equipes independentes iniciaram para resolver um problema de negócios compartilhado e estamos vendo se podemos trazer todos para uma única instância, sem perder o trabalho anterior deles.
Não consigo acreditar que seja uma boa prática depender da retenção de dados em desenvolvimento.
Se os dados são importantes, esse trabalho deve provavelmente existir em Produção sob circunstâncias mais controladas.
Não sei a natureza completa do que você está tentando fazer, mas sendo opinativo, as soluções deveriam quase certamente ser plugins que podem ser implantados em qualquer lugar e nem sequer precisam depender totalmente de uma versão específica do Discourse, nem se importar se dados específicos são pré-preenchidos fora da semeadura de seus próprios fixtures.
Neste caso, estamos fazendo a viabilidade dessas operações de mesclagem para as instâncias de Produção usando algumas instâncias de Desenvolvimento. Se conseguirmos solidificar o runbook, todos os dados e instâncias serão de nível de produção, mas foram mantidos por equipes independentes até agora. Portanto, saber quais são os bloqueadores para uma mesclagem bem-sucedida é o que estou trabalhando agora. E a versão do esquema é claramente uma chave, e tanto o aplicativo quanto os plugins podem e afetarão a “mesclabilidade”. Felizmente, as instâncias de produção mostraram 0823, então esse problema específico não aconteceria em uma execução de produção, mas saber como analisar uma deriva de esquema era necessário e realmente ajudará nossos opdocs.
Descobri outra nuance de esquemas. Então removemos o plugin de automação da implantação e reimplantamos. Então notei que schema_migration parecia reverter para 0823 como o mais recente. Então pensei que estava tudo bem sem instalar o plugin de automação na instância que estou mesclando. Bem, quando fiz outra execução de importação, recebi um erro PG::UndefinedTable: ERROR: relation "discourse_automation_automations" does not exist, então, mesmo que a versão das migrações tenha voltado, as alterações de esquema associadas a ela no banco de dados real ainda pareciam estar por perto.
(que você pode obter com 
