Skip to main content

Migrar do MySQL 8.0 para o MySQL 8.4

Regiões

Este recurso está disponível nas seguintes regiões:
br-se1
br-ne1

O MySQL 8.0 atinge seu End of Life (EOL) em 21 de abril de 2026, conforme o anúncio oficial da Oracle. A partir dessa data, a Oracle não disponibiliza mais patches de segurança, correções de bugs ou qualquer tipo de suporte oficial para essa versão da engine.

Sua instância em MySQL 8.0 continuará disponível e funcionando normalmente na Magalu Cloud durante o período de suporte estendido descrito na Política de Versões, porém recomendamos fortemente a migração para o MySQL 8.4, versão LTS (Long-Term Support) atual, que continua recebendo patches de segurança e suporte oficial.

Informação

Consulte a Política de Versões para ver as datas de início e final de suporte de cada versão do MySQL na Magalu Cloud.

Esta página descreve o processo recomendado de migração, dividido em três etapas:

  1. Verificação de compatibilidade
  2. Criação da nova instância MySQL 8.4
  3. Migração dos dados com mydumper/myloader
Aviso

Se a sua instância de origem ou de destino for um cluster Multi-AZ, leia com atenção a seção Migrar para um cluster Multi-AZ antes de iniciar a carga dos dados. Executar o mydumper/myloader da mesma forma que em uma instância single-instance pode deixar as réplicas stand-by do cluster fora de sincronia.

Verificar a compatibilidade​

Antes de iniciar a migração, é necessário verificar se o seu banco de dados possui itens incompatíveis com a versão 8.4. Algumas mudanças relevantes entre as versões incluem:

  • Remoção da terminologia antiga de replicação (MASTER/SLAVE).
  • Substituição do plugin de autenticação mysql_native_password pelo caching_sha2_password como padrão.
  • Alterações em privilégios de usuário e variáveis de sistema removidas ou renomeadas.

Para identificar automaticamente os pontos do seu banco que precisam de ajuste, utilize a Upgrade Checker Utility do MySQL Shell (util.checkForServerUpgrade()), executada a partir de uma Máquina Virtual ou outro host com acesso à sua instância. O usuário utilizado precisa ter os privilégios RELOAD, PROCESS e SELECT:

mysqlsh usuario@ip_privado_da_instancia_80:3306 -- util check-for-server-upgrade --target-version=8.4.0
  • Substitua usuario pelo usuário administrador da instância de origem.
  • Substitua ip_privado_da_instancia_80 pelo IP privado da instância MySQL 8.0.

A saída lista os itens verificados em três categorias:

  • Errors: precisam ser corrigidos obrigatoriamente antes do upgrade.
  • Warnings: podem impactar o funcionamento da aplicação após o upgrade e devem ser avaliados.
  • Notices: pontos informativos que exigem checagem manual (não são detectados automaticamente).

Corrija todos os itens reportados como Error — e avalie os Warnings — antes de seguir para a etapa de migração.

tip

Sempre que possível, execute a verificação de compatibilidade e um teste de migração completo em um ambiente de homologação antes de aplicar o processo na sua instância de produção.

Criar a nova instância MySQL 8.4​

Crie uma nova instância MySQL na versão 8.4 na Magalu Cloud. Essa instância receberá os dados migrados da sua instância atual em 8.0.

Você pode criar a instância pelo Console ou pela CLI:

mgc dbaas instances create \
  --availability-zone="br-se1-a" \
  --instance-type-id="b9f1e3a0-3081-4c62-87b9-0ea56aec65dd" \
  --name="dbaas-name-84" \
  --password="dbaas-password" \
  --user="dbaas-user" \
  --volume.size=20 \
  --volume.type="CLOUD_NVME15K" \
  --engine-id="e1db7c95-83bf-40c4-aaee-9e1d35659a0a"

Substitua:

  • o valor de name pelo nome que deseja dar à nova instância.
  • os valores de user e password pelas credenciais do usuário administrador da nova instância.
  • o valor de instance-type-id pelo ID do tipo de instância desejado.
  • o valor de engine-id pelo ID da engine MySQL 8.4 (veja como encontrá-lo logo abaixo).

Para mais detalhes sobre os parâmetros disponíveis, consulte Criar uma instância MySQL. Você pode encontrar o engine-id correspondente à versão 8.4 com o comando:

mgc dbaas engines list --status=ACTIVE
Nota

Se a sua instância 8.0 utiliza um grupo de parâmetros customizado, crie e associe um grupo equivalente à nova instância 8.4 antes de iniciar a carga dos dados, já que alguns parâmetros podem ter nomes ou comportamentos diferentes entre as versões.

Se a sua instância de origem é um cluster Multi-AZ (ou se você deseja alta disponibilidade na nova versão), crie o destino também como um cluster, usando mgc dbaas clusters create no lugar de mgc dbaas instances create:

mgc dbaas clusters create \
  --instance-type-id="9595d737-78be-4eaf-af96-7bed88f7edc2" \
  --name="dbaas-cluster-name-84" \
  --password="dbaas-password" \
  --user="dbaas-user" \
  --volume.size=20 \
  --volume.type="CLOUD_NVME15K" \
  --engine-id="e1db7c95-83bf-40c4-aaee-9e1d35659a0a"

Substitua os mesmos valores indicados acima. Para mais detalhes, consulte a seção Cluster (multi-zonas) da página de criação de instâncias. Se este for o seu caso, siga também as orientações da seção Migrar para um cluster Multi-AZ mais adiante nesta página.

Migrar os dados com mydumper/myloader​

Recomendamos o uso do mydumper/myloader, ferramenta open-source de backup lógico multi-thread para MySQL, que costuma ser significativamente mais rápida que o mysqldump tradicional em bases de maior volume.

Pré-requisitos​

Instale o mydumper (o pacote já inclui o myloader) em uma Máquina Virtual ou outro host com acesso de rede às duas instâncias — a de origem (8.0) e a de destino (8.4).

wget -qO- 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x1D357EA7D10C9320371BDD0279EA15C0E82E34BA&exact=on' | sudo tee /etc/apt/keyrings/mydumper.asc

echo "deb [signed-by=/etc/apt/keyrings/mydumper.asc] https://mydumper.github.io/mydumper/repo/apt/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mydumper.list

sudo apt update && sudo apt install -y mydumper
wget -O GPG-KEY-MyDumper "https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x79EA15C0E82E34BA"
sudo rpm --import GPG-KEY-MyDumper

sudo tee /etc/yum.repos.d/mydumper.repo <<'EOF'
[mydumper]
name=MyDumper
baseurl=https://mydumper.github.io/mydumper/repo/yum/$releasever
enabled=1
gpgcheck=1
EOF

sudo yum install -y mydumper

Para outras distribuições, containers ou compilação a partir do código-fonte, consulte a documentação oficial de instalação.

Exportar os dados da instância 8.0​

Execute o mydumper apontando para a instância de origem. Inclua as flags --triggers, --events e --routines para garantir que triggers, events e stored procedures/functions também sejam exportados:

mydumper \
  --host=ip_privado_da_instancia_80 \
  --user=usuario \
  --ask-password \
  --outputdir=./backup-mysql80 \
  --threads=4 \
  --triggers \
  --events \
  --routines \
  --compress

Substitua:

  • ip_privado_da_instancia_80 pelo IP privado da instância de origem.
  • usuario pelo usuário administrador da instância de origem.

Ajuste --threads de acordo com a quantidade de vCPUs disponíveis na máquina cliente e na instância de origem. Para bases grandes, prefira executar a exportação em um horário de baixo tráfego, já que a leitura de grandes volumes de dados consome I/O e rede da instância de origem.

Para mais opções (filtragem por banco/tabela, chunking de tabelas grandes, compressão, etc.), consulte a documentação oficial de uso do mydumper.

Restaurar os dados na instância 8.4​

Com o backup gerado, utilize o myloader apontando para a nova instância 8.4:

myloader \
  --host=ip_privado_da_instancia_84 \
  --user=usuario \
  --ask-password \
  --directory=./backup-mysql80 \
  --threads=4

Substitua:

  • ip_privado_da_instancia_84 pelo IP privado da nova instância de destino.
  • usuario pelo usuário administrador da nova instância.

Para mais opções — como lidar com tabelas já existentes na instância de destino (-o/--drop-table) ou restaurar em um banco com nome diferente (-B/--database) — consulte a documentação oficial de uso do myloader.

Acelerar a carga desabilitando o redo log​

O myloader oferece a flag --disable-redo-log, que desabilita o redo log do InnoDB (via ALTER INSTANCE DISABLE INNODB REDO_LOG) durante a restauração. Como o myloader deixa de escrever no redo log e no doublewrite buffer, é comum observar uma carga de 3 a 4 vezes mais rápida.

myloader \
  --host=ip_privado_da_instancia_84 \
  --user=usuario \
  --ask-password \
  --directory=./backup-mysql80 \
  --disable-redo-log
Perigo

Só desabilite o redo log para a carga inicial de um banco vazio — nunca em uma instância que já contenha dados que você precisa manter, ou que esteja em produção. Segundo a documentação oficial do MySQL, com o redo log desabilitado qualquer interrupção inesperada do servidor (queda de energia, crash do processo, etc.) pode causar perda de dados e corrupção da instância. Em uma carga inicial isso é apenas um contratempo — se acontecer, basta recriar a instância e refazer a carga —, mas em um banco com dados relevantes o mesmo incidente destrói a base.

Como a instância 8.4 desta migração acabou de ser criada e ainda está vazia, usar essa flag é seguro neste contexto específico. Depois de concluída a restauração, o myloader reabilita o redo log automaticamente ao final do processo.

O número de threads recomendado depende de o redo log estar ativo ou não:

  • Redo log desabilitado: o gargalo deixa de ser a escrita no redo log e passa a ser a vazão do disco, então não é necessário um número alto de threads.
  • Redo log habilitado (caso da instância já conter dados, ou de qualquer restauração em produção): utilize --threads igual à quantidade de vCPUs da máquina que está executando o myloader.

Usar um arquivo de configuração (.cnf)​

Em vez de repetir as opções em cada execução, você pode consolidá-las em um arquivo de configuração e reutilizá-lo com --defaults-file. Isso também é a forma recomendada de definir variáveis de sessão do mydumper/myloader — como manter o log binário ativo durante a carga, o que é obrigatório ao migrar para um cluster (veja a seção Migrar para um cluster Multi-AZ logo abaixo).

Crie um arquivo mydumper.cnf:

[mydumper]
host=ip_privado_da_instancia_80
user=usuario
threads=4

[myloader]
host=ip_privado_da_instancia_84
user=usuario
threads=4

[myloader_session_variables]
SQL_LOG_BIN=1

Substitua os valores de host e user de cada seção pelos dados da respectiva instância (origem em [mydumper], destino em [myloader]). E utilize o arquivo nos dois comandos:

mydumper --defaults-file=./mydumper.cnf --ask-password --outputdir=./backup-mysql80 --triggers --events --routines --compress

myloader --defaults-file=./mydumper.cnf --ask-password --directory=./backup-mysql80

Para a lista completa de seções e variáveis disponíveis, consulte a documentação oficial de configuração do mydumper.

Validar a migração​

Após a restauração, valide a consistência dos dados entre a instância de origem (8.0) e a de destino (8.4):

  • Compare a lista de bancos e tabelas em ambas as instâncias (SHOW DATABASES; / SHOW TABLES;).
  • Compare a contagem de linhas por tabela (SELECT COUNT(*) FROM nome_da_tabela;).
  • Compare o checksum das tabelas com o comando nativo do MySQL CHECKSUM TABLE, executado em ambas as instâncias:
CHECKSUM TABLE nome_do_banco.nome_da_tabela;

Se os valores retornados forem iguais em ambas as instâncias, os dados foram migrados corretamente.

Migrar para um cluster Multi-AZ​

Um cluster Multi-AZ do DBaaS Magalu Cloud é composto por 1 instância primária (leitura e escrita, porta 3306) e 2 réplicas stand-by (somente leitura, porta 3307), mantidas em sincronia via replicação em grupo (Group Replication), com failover automático.

Aviso

Rodar o mydumper/myloader em um cluster exatamente como em uma instância single-instance pode deixar as réplicas stand-by inconsistentes ou fora de sincronia com a primária, comprometendo a alta disponibilidade do cluster. Siga os cuidados abaixo antes de migrar dados para um cluster.

O Group Replication propaga as transações entre os membros do grupo através do log binário e de GTIDs — por isso, a documentação oficial do MySQL sobre os requisitos do Group Replication exige que todos os membros operem com log_bin habilitado, gtid_mode=ON, enforce_gtid_consistency=ON e binlog_format=ROW. Isso já é garantido pelo DBaaS Magalu Cloud nas instâncias que compõem um cluster — o risco está em desabilitar o log binário durante a carga, uma otimização comum de performance em restaurações single-instance (por exemplo, definindo SQL_LOG_BIN=0 na sessão do myloader). Em um cluster, isso impede que as linhas inseridas pelo myloader na primária sejam certificadas e propagadas para as réplicas stand-by, deixando-as sem os dados restaurados.

Checklist para migrar para um cluster​

  1. Aponte sempre para a instância primária. Execute o myloader contra a porta 3306 (leitura e escrita) do cluster de destino — nunca contra a porta 3307 (réplicas, somente leitura).
  2. Mantenha o log binário ativo durante toda a carga. Se estiver usando um arquivo de configuração, garanta que a seção [myloader_session_variables] não desabilite o log binário: 
    [myloader_session_variables]
    SQL_LOG_BIN=1
    Evite qualquer tutorial ou otimização de terceiros que sugira SET SESSION SQL_LOG_BIN=0 para acelerar a restauração — em uma instância single-instance isso é apenas um ganho de performance, mas em um cluster quebra a replicação para as réplicas stand-by.
  3. Coloque o cluster em modo de importação antes da carga, usando o comando oficial da CLI Magalu Cloud: 
    mgc dbaas clusters start-import-mode --cluster-id="id_do_cluster_84"
    Substitua id_do_cluster_84 pelo ID do cluster de destino.
  4. Execute o myloader normalmente, conforme descrito nas seções anteriores.
  5. Retorne o cluster ao modo normal de operação ao final da carga: 
    mgc dbaas clusters stop-import-mode --cluster-id="id_do_cluster_84"
  6. Valide também as réplicas, não só a primária. Conecte-se em cada réplica stand-by (porta 3307) e repita as checagens de contagem de linhas e CHECKSUM TABLE descritas na seção anterior, além de confirmar que não há atraso de replicação (lag) pendente antes de considerar a migração concluída.

Etapas pós-migração​

  1. Atualize a connection string das suas aplicações para apontar para a nova instância MySQL 8.4;
  2. Monitore o desempenho e os logs de acesso da nova instância após a virada;
  3. Somente após validar que a aplicação está estável na nova instância, considere excluir a instância antiga em 8.0 — essa ação é irreversível.

Em caso de dúvidas​

Se tiver qualquer dúvida durante o processo de avaliação ou migração, abra um Ticket de suporte e nossa equipe irá te auxiliar.