No fórum que transferi, o xengallery foi instalado uma vez, por isso tive que mudar o seguinte, pois a tabela xfgallery já não existia.
def get_xf_sql(type, id)
case type
when :gallery
return "SELECT NULL WHERE 1=0;"
when :attachment
<<-SQL
SELECT a.attachment_id, a.data_id, d.filename, d.file_hash, d.user_id
FROM #{TABLE_PREFIX}attachment AS a
INNER JOIN #{TABLE_PREFIX}attachment_data d ON a.data_id = d.data_id
WHERE attachment_id = #{id}
AND content_type = 'post'
SQL
end
end
Executar o acima me dá o seguinte erro. Verifiquei o Gemfile e ele contém apenas esta linha - gem ‘mysql2’
Este Gemfile não inclui uma fonte global explícita.
Não usar uma fonte global explícita pode resultar em um lockfile diferente sendo gerado dependendo das gems que você instalou localmente antes do bundler ser executado.
Em vez disso, defina uma fonte global em seu Gemfile assim: source "https://rubygems.org".
Não foi possível encontrar a gem 'mysql2' nas gems instaladas localmente.
root@ip-172-566-459-13-app:/#
Ok, então consegui passar para a próxima etapa. Alguém acima postou que precisamos estar na pasta /var/www/discourse no contêiner e então adicionar a gem.
Estou recebendo este erro. O que posso estar fazendo de errado?
`/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql_adapter.rb:63:in “rescue in new_client”: Não conseguimos encontrar seu banco de dados: discourse.
As configurações de banco de dados disponíveis podem ser encontradas em config/database.yml. (ActiveRecord::NoDatabaseError)Para resolver este erro:
Você não criou o banco de dados ou o excluiu? Para criar o banco de dados, execute:
bin/rails db:create
O nome do banco de dados mudou? Verifique se config/database.yml contém o nome correto do banco de dados.`
Resolvido: Eu estava executando como usuário root, tive que mudar para o usuário ‘discourse’. A importação começou.
Então, peguei um servidor razoavelmente bom com 4 CPUs e 16 GB de RAM. Na taxa em que as postagens estão sendo migradas, levará 9 dias apenas para as postagens serem migradas. Os usuários levaram 2,5 horas para serem migrados. É seguro dizer que isso não vai dar certo para mim como está, mas pelo menos posso passar alguns meses me familiarizando até descobrir uma solução para essa migração em massa.
PS:
No script de migração, vejo que e-mails duplicados não são importados. Quais são as diferentes maneiras pelas quais a duplicidade é determinada? Notei que xyz@gmail.com é tratado da mesma forma que xyz+1@gmail.com e xy.z@gmail.com
Eu tentei fazer migrações em VPS com especificações semelhantes ao meu computador pessoal, mas por algum motivo sempre foi muito, muito mais lento do que usar meu computador.
Hoje em dia, sempre faço minhas migrações localmente. Quantas postagens você tem?
A velocidade de uma única CPU é o fator importante.
Nas minhas máquinas, uma taxa de 800-1000 usuários ou posts/minuto é bastante típica.
Observe que, quando você fizer a importação final, ela importará apenas os usuários e posts que ainda não foram importados, portanto, não levará muito tempo.
Desative a configuração do site Normalize emails (desativado era o padrão até recentemente). Provavelmente, ela deve ser desativada nesta função aqui:
Você pode colocá-la em sua versão personalizada do script xenforo com SiteSetting.normalize_emails=false. Não tenho certeza do que aconteceu com esses usuários de e-mail duplicados; há duas coisas óbvias a fazer: dar a eles um endereço de e-mail inválido ou pular a importação deles. Parece que eles recebem e-mails inválidos? (E há uma chance muito boa de que eles sejam, de fato, usuários inválidos de qualquer maneira). Se ele os pulou, executar o script novamente os importará.
Sim no meu laptop, está processando as coisas muito mais rápido a 1000 itens por minuto. Isso é cerca de 2 vezes mais rápido do que no servidor. Ainda assim, são cerca de 3 dias.
Passei pelos e-mails pulados e parece que ele está fazendo um bom trabalho ignorando essas contas. Eu simplesmente as mesclarei antes da importação final. Pouco mais de 20 casos assim.
Note que quando você fizer a importação final, ele importará apenas os usuários e postagens que ainda não foram importados, então não levará muito tempo.
Obrigado por apontar isso. Observei isso por mim mesmo e parece que é isso que vai salvar o dia quando eu fizer a importação final. Então eu faço um backup e restauração no D-3 e depois outro backup e restauração com o novo arquivo de backup do banco de dados no Dia 0. Está correto?
Esses backups e restaurações são no site Xenforo, ou você tem algum site Discourse ativo para o qual vai importar os dados do Xenforo?
Desde que você não faça alterações no script que exijam reimportar dados, e o que você tem no seu laptop agora é o que você quer no seu servidor Discourse, então você pode continuar obtendo novos dumps do banco de dados Xenforo e importando-os (para testar, ver quanto tempo leva, e assim por diante) e então no dia da migração, você congela o site Xenforo, obtém esse banco de dados, executa o script mais uma vez e faz o upload para o seu servidor Discourse.
Se você já tem dados no seu site Discourse que deseja manter, as coisas ficam muito mais complicadas, pois você precisará congelar esse site, depois obter os dados do Xenforo e, em seguida, proceder como descrito acima.
Será uma instalação limpa do Discourse, o que facilitará as coisas.
Tenho bastante tempo à disposição, pois quero testar as migrações várias vezes, me familiarizar completamente com o Discourse, configurar todos os add-ons da maneira que eu quiser e talvez até me aprofundar na personalização de alguns add-ons.
O que você explicou tira um grande peso do meu peito, pois eu achava que teria que descobrir também as importações em massa.
Voltei com uma dúvida, o script de importação gera algum log? Minha importação de teste está presa em 98,2% há algumas horas.
Outra coisa que percebi, se eu reiniciar a migração, leva cerca de 30 segundos para pular um lote de 1000 posts. Então, efetivamente, a velocidade agora é de 2000 itens por minuto. Não é uma melhoria significativa em relação aos 1000 posts por minuto da primeira importação, pois mesmo na última importação no dia do corte, levará cerca de um dia. 23 horas das quais serão apenas para pular itens já importados.
Você provavelmente deveria pará-la e iniciá-la novamente.
Sim, ele pulará todos os dados que já foram importados. E faz isso muito mais rápido do que 2000 posts/minuto. Suspeito que você verá quando reiniciá-la agora.
Consegui importar os avatares e anexos. Copiei estas pastas.
/internal_data/attachments
/data/avatars
Para responder à minha pergunta, os avatares e anexos são finalizados assim que importados. Se um usuário alterar seu avatar após seu ID ser importado, ele não será importado/atualizado porque essa postagem ou usuário será ignorado na segunda execução.
Agora só preciso descobrir a importação de conversas (também pode ser ignorada, mas é bom ter) e os redirecionamentos permanentes.
@Fajfi - Obrigado pela sua contribuição para o script de importação. Funcionou perfeitamente para avatares e anexos. Ainda está em execução e ainda não cheguei à parte de curtidas.
Corrigida a importação de conversas. Consegui importar mais de meio milhão de mensagens do XF2.3 para o Discourse. Levantei um PR caso alguém esteja interessado.
----EDIT----
Levantei outro PR com uma correção para a importação de curtidas. É surpreendente que ninguém tenha migrado do XF2.1+ para o Discourse até agora. Curtidas foram renomeadas para reações em 2019, quando o XF2.1 foi lançado.