Migração de alta complexidade: preparando o Invision Community 5 em ambientes de grande escala

Atualizar uma comunidade de grande porte da versão 4 para a Invision Community v5 é um desafio que separa instaladores de clique de analistas de infraestrutura. Neste caso em DirectAdmin, o plano inicial precisou ser adaptado com manobras técnicas de contingência para manter previsibilidade.

1) O desafio do storage: 350 GB sem duplicação

Em cenários robustos, a distribuição costuma ser:

• Core da aplicação: < 1 GB
• Mídia (uploads/fotos): ~310 GB
• Banco de dados: dezenas de GB

Duplicar mídia para staging é caro e lento. A estratégia aplicada foi:

1. rsync apenas para estrutura de código e arquivos essenciais.
2. symlinks no staging apontando para a mídia original.

Resultado: homologação funcional com consumo mínimo de disco.

2) Isolamento via hosts e falha no -TESTINSTALL

Em teoria, o sufixo de licença -TESTINSTALL resolve homologação. Na prática, neste cenário ele não atendeu.

Contorno aplicado:

1. replicação em servidor distinto.
2. resolução forçada via arquivo hosts local.

Assim foi possível validar o ambiente como produção, sem expor DNS público e sem bloqueio operacional por licença.

3) Integridade do banco via CLI

Para bases grandes, importação web não é confiável. O procedimento foi feito integralmente via terminal:

pv backup_producao.sql | mysql -u user_staging -p banco_staging

O pv trouxe visibilidade real de throughput e progresso.

4) Upgrade “mão na massa”: quando o CLI falha

A documentação recomenda upgrade por CLI, mas neste ambiente o fluxo via cli.php não executou de forma estável.

Contingência aplicada:

1. upgrade via browser com acompanhamento próximo.
2. monitoramento de processlist do MySQL.
3. execução manual de queries críticas quando necessário.

Essa abordagem evitou travamentos em tabelas de grande porte.

5) Permissões, erro 500 e ajustes finos

Erro clássico em staging DirectAdmin: 500 Access Denied.

No IC5, conf_global.php e diretórios críticos precisam estar com owner/group do usuário do pool PHP-FPM (por exemplo site1:site1). Alterações por root fora do fluxo quebraram execução.

Ajustes adicionais:

1. centralização de variáveis no .htaccess com .user.ini/.php.ini sob

controle para evitar conflito.

1. correção de session.save_path inválido.
2. ajuste de memory_limit e max_post_size para suportar processamento pesado.

Checklist operacional de sucesso

• [x] Staging isolado em servidor distinto e acesso via hosts.
• [x] Sync seletivo com rsync + symlinks para mídia.
• [x] Importação de banco via CLI com pv.
• [x] Monitoramento ativo de queries durante upgrade.
• [x] Revisão de ownership/permissões para usuário do PHP-FPM.

Upgrade do Invision Community v4 para v5 em larga escala não é linear. Quando a automação falha, o sucesso vem de isolamento, observabilidade e execução controlada no terminal e no banco, passo a passo.

Este post está licenciado sob CC BY-NC.