Como Migrar do AWS Aurora MySQL para OCI HeatWave com Mínimo Downtime

Migrar um banco de dados MySQL em produção é um dos momentos que mais tira o sono de qualquer DBA. O risco de downtime prolongado, perda de dados ou inconsistência durante a transição é real - e uma migração mal planejada pode custar horas de indisponibilidade e prejuízo direto ao negócio.

Neste guia você vai ver, passo a passo, como migrar do Amazon Aurora MySQL 8.0 para o OCI HeatWave MySQL 8.4 com o mínimo de interrupção possível - usando uma combinação de dump consistente com MySQL Shell e replicação contínua via OCI HeatWave Channel.

A estratégia é simples na ideia, robusta na execução: migre os dados em background, mantenha os dois ambientes sincronizados em tempo real, e só redirecione as aplicações quando tudo estiver pronto. O único downtime real é o tempo de apontar os servidores de aplicação para o novo ambiente.

O que você vai precisar antes de começar

Antes de executar qualquer comando, garanta que os seguintes pré-requisitos estão atendidos:

Infraestruturas AWS e OCI provisionadas e operacionais
Cluster Amazon Aurora MySQL em produção (source)
Cluster OCI HeatWave MySQL criado e pronto para receber dados (target)
Conectividade entre os dois ambientes na porta 3306
Servidor intermediário (ponte) com MySQL Shell instalado e acesso bidirecional a ambos os ambientes

Para um guia detalhado de provisionamento das infraestruturas, consulte a documentação oficial da Oracle.

A estratégia em duas etapas

A abordagem que vamos usar divide a migração em duas fases distintas - e é essa divisão que garante o mínimo de downtime:

Etapa 1 - Baseline (dump completo): exportação integral do banco de origem para o destino usando MySQL Shell. Esse processo roda em background, sem impactar a produção.

Etapa 2 - Delta (replicação contínua): enquanto o dump é importado e depois que ele termina, todas as transações novas do Aurora são replicadas automaticamente para o HeatWave via binlogs, usando o recurso OCI HeatWave MySQL Channel.

O resultado: quando você finalmente redirecionar as aplicações, o HeatWave já está com os dados 100% atualizados. O downtime se resume ao tempo de ajustar o apontamento DNS ou connection string nas aplicações.

Etapa 1: Exportação e Importação com MySQL Shell

Configurações obrigatórias no Aurora (source)

Antes de qualquer coisa, verifique se os seguintes parâmetros estão ativos no seu Amazon Aurora MySQL. Sem eles, a replicação baseada em GTID não funciona:

gtid_mode = ON
enforce-gtid-consistency = ON
log_bin = ON
binlog_format = ROW
log_slave_updates = ON

Exportando com `util.dumpSchemas`

Com o MySQL Shell conectado ao Aurora, execute o dump do schema npx para o diretório /DUMP/NPX/:

util.dumpSchemas(
  ["npx"],
  "/DUMP/NPX/",
  {
    threads: 60,
    ocimds: true,
    compatibility: [
      "skip_invalid_accounts",
      "strip_restricted_grants",
      "ignore_wildcard_grants",
      "strip_definers",
      "strip_invalid_grants",
      "create_invisible_pks"
    ],
    consistent: true
  }
);

O que cada parâmetro faz:

Parâmetro	Função
`threads: 60`	Paraleliza o dump em 60 threads simultâneas para máxima velocidade
`ocimds: true`	Garante compatibilidade total com OCI MySQL HeatWave
`skip_invalid_accounts`	Ignora contas de usuários incompatíveis com o destino
`strip_restricted_grants`	Remove permissões não suportadas pelo target
`ignore_wildcard_grants`	Ignora grants com curingas (%) para evitar problemas de segurança
`strip_definers`	Remove DEFINER de views, procedures e triggers
`strip_invalid_grants`	Remove permissões inválidas no destino
`create_invisible_pks`	Cria PKs invisíveis em tabelas sem chave primária - necessário para HA no HeatWave
`consistent: true`	Garante snapshot consistente: todos os dados refletem o mesmo ponto no tempo

Resultado esperado no ambiente de laboratório:

Dump duration: 03:17:25s
Total duration: 03:24:46s
Tables dumped: 276
Uncompressed data size: 1.45 TB
Compressed data size: 413.88 GB
Compression ratio: 3.5
Rows written: 3,597,220,261

Um dump de 1,45 TB comprimido para 413 GB - razão de compressão de 3.5x. Com 60 threads paralelas, o throughput médio ficou em 122 MB/s sem compressão e 34,94 MB/s comprimido.

Importando com `util.loadDump`

Com o dump gerado, conecte o MySQL Shell ao HeatWave e execute a importação:

util.loadDump(
  "/DUMP/NPX",
  {
    threads: 60,
    ignoreVersion: true,
    schema: 'npx'
  }
);

Parâmetro	Função
`threads: 60`	Paraleliza a importação para máxima velocidade
`ignoreVersion: true`	Permite importar mesmo com diferença de versão entre source (8.0.39) e target (8.4.4)
`schema: 'npx'`	Define explicitamente o schema de destino

Atenção: durante a importação com 60 threads paralelas, é normal aparecerem erros MySQL Error 1213 (Deadlock). O MySQL Shell trata isso automaticamente com retry - não interrompa o processo.

Resultado no laboratório:

43.064 chunks (3,6 bilhões de rows, 1,45 TB) carregados em 7 horas 44 min
Throughput médio: 51,91 MB/s - 129.090 rows/s
0 warnings reportados

Etapa 2: Replicação em Tempo Real com OCI HeatWave Channel

Com o baseline importado, o próximo passo é configurar o canal de replicação que vai manter os dois ambientes sincronizados até o momento do cutover.

Criando o usuário de replicação no Aurora (source)

Se ainda não existe, crie o usuário de replicação diretamente no Aurora:

CREATE USER 'repuser'@'%' IDENTIFIED BY 'minha_senha_forte';
GRANT REPLICATION SLAVE ON *.* TO 'repuser'@'%';

O detalhe que quebra a maioria das migrações: o GTID

Quando o util.dumpSchemas é executado, ele gera automaticamente um arquivo @.json no diretório do dump. Esse arquivo contém o GTID exato do momento em que o dump foi tirado - e você vai precisar dele para configurar corretamente a replicação.

cat /DUMP/NPX/@.json | grep -i '"gtidExecuted"'
# "gtidExecuted": "415d143e-3653-30b3-980b-657ad05d72bd:1-44171859"

Com o GTID em mãos, conecte ao HeatWave e execute:

CALL sys.SET_GTID_PURGED("+415d143e-3653-30b3-980b-657ad05d72bd:1-44171859");

Atenção crítica: o sinal + antes do GTID é obrigatório. Ele instrui o MySQL a adicionar o conjunto ao estado atual, não substituí-lo. Esquecer esse + é um dos erros mais comuns em migrações com GTID - e pode causar inconsistência séria na replicação.

O formato correto sempre é:

CALL sys.SET_GTID_PURGED("+<gtidSet>");

Configurando o Canal de Replicação no OCI Console

Com o GTID configurado corretamente no HeatWave, acesse o OCI Console e configure o Inbound Replication Channel apontando para o Aurora como source. O canal vai estabelecer a replicação MASTER (Aurora) → SLAVE (HeatWave) em tempo real via binlogs.

Como monitorar a replicação

Com o canal ativo, você tem quatro formas principais de monitorar o status da replicação:

1. Visão geral rápida: `SHOW REPLICA STATUS\G`

SHOW REPLICA STATUS\G

Campos mais importantes:

Campo	O que indica
`Replica_IO_Running`	Thread de I/O ativa (recebendo binlogs do master)
`Replica_SQL_Running`	Thread SQL ativa (aplicando transações)
`Seconds_Behind_Source`	Atraso em segundos em relação ao master
`Last_IO_Error` / `Last_SQL_Error`	Erros recentes nos threads

2. Detalhamento por worker: `replication_applier_status_by_worker`

Para verificar latência por canal e worker em tempo real:

SELECT
  concat(conn_status.channel_name, ' (', worker_id, ')') AS channel,
  conn_status.service_state AS io_state,
  applier_status.service_state AS sql_state,
  format_pico_time(
    if(GTID_SUBTRACT(LAST_QUEUED_TRANSACTION, LAST_APPLIED_TRANSACTION) = "",
      "0",
      abs(time_to_sec(
        if(time_to_sec(APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP) = 0, 0,
          timediff(APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP, now()))
      ))
    ) * 1000000000000
  ) latency,
  conn_status.LAST_QUEUED_TRANSACTION AS last_queued_transaction,
  applier_status.LAST_APPLIED_TRANSACTION AS last_applied_transaction
FROM performance_schema.replication_connection_status AS conn_status
JOIN performance_schema.replication_applier_status_by_worker AS applier_status
  ON applier_status.channel_name = conn_status.channel_name;

Como interpretar os resultados:

Campo	Sinal saudável	Sinal de alerta
`io_state` + `sql_state`	Ambos `ON`	Qualquer `OFF`
`latency`	Milissegundos	Horas ou dias
`apply_time`	< 10ms	> 1s
Gap entre `last_queued` e `last_applied`	Pequeno	Crescendo continuamente

3. Problemas no IO Thread: `replication_connection_status`

Use quando o Replica_IO_Running estiver OFF:

SELECT * FROM performance_schema.replication_connection_status\G

Verifique LAST_ERROR_NUMBER e LAST_ERROR_MESSAGE para diagnóstico direto.

4. Erros detalhados: `performance_schema.error_log`

Para os erros mais críticos - incluindo problemas de tipo de coluna, plugins ausentes e falhas de transação:

SELECT logged, prio, error_code, data
FROM performance_schema.error_log
WHERE subsystem = 'Repl' AND prio = 'Error'
ORDER BY 1 DESC;

Exemplo real de erro encontrado no laboratório: Plugin 'mysql_native_password' is not loaded - o Aurora tentou replicar um ALTER USER com autenticação nativa, que não existe no MySQL 8.4. Solução: skip da transação problemática e ajuste no usuário no source.

Checklist final antes do cutover

Antes de redirecionar as aplicações para o HeatWave, valide cada item:

1. Pré-requisitos

Infraestruturas AWS e OCI provisionadas e com conectividade na porta 3306
Servidor intermediário com MySQL Shell instalado e acesso bidirecional confirmado

2. Configurações no Aurora (source)

gtid_mode = ON
enforce-gtid-consistency = ON
log_bin = ON
binlog_format = ROW
log_slave_updates = ON

3. Exportação e Importação

Dump executado com util.dumpSchemas e parâmetros de compatibilidade OCI
Arquivo @.json gerado e GTID extraído corretamente
Importação concluída com util.loadDump sem erros críticos

4. Usuário de replicação

Usuário repuser criado no Aurora com GRANT REPLICATION SLAVE

5. Canal de replicação

SET_GTID_PURGED executado no HeatWave com o sinal + - não esqueça o +
Canal OCI HeatWave configurado no Console e ativo
Replica_IO_Running e Replica_SQL_Running ambos ON
Latência de replicação próxima de zero antes do cutover

6. Cutover

Aplicações redirecionadas para o novo endpoint HeatWave
Canal de replicação desativado após confirmação

Conclusão

Migrar 1,45 TB de dados de produção com zero perda e downtime mínimo não é sorte - é método. A combinação de dump consistente com MySQL Shell e replicação contínua via OCI HeatWave Channel é hoje uma das abordagens mais sólidas para esse tipo de migração.

Os dois pontos que mais causam falhas nesse processo:

GTID mal configurado - sempre use o arquivo @.json como referência e nunca esqueça o sinal + no SET_GTID_PURGED
Cutover sem verificar latência - antes de redirecionar as aplicações, confirme que o gap entre last_queued_transaction e last_applied_transaction está zerado ou próximo de zero

Se você ficou com dúvidas sobre alguma etapa ou está enfrentando um cenário específico de migração, fale com a equipe da MasterDatabase - somos Gold Partners MongoDB e especialistas em migrações de banco de dados em ambientes críticos.

Como Migrar do AWS Aurora MySQL para OCI HeatWave com Mínimo Downtime

O que você vai precisar antes de começar

A estratégia em duas etapas

Etapa 1: Exportação e Importação com MySQL Shell

Configurações obrigatórias no Aurora (source)

Exportando com `util.dumpSchemas`

Importando com `util.loadDump`

Etapa 2: Replicação em Tempo Real com OCI HeatWave Channel

Criando o usuário de replicação no Aurora (source)

O detalhe que quebra a maioria das migrações: o GTID

Configurando o Canal de Replicação no OCI Console

Como monitorar a replicação

1. Visão geral rápida: `SHOW REPLICA STATUS\G`

2. Detalhamento por worker: `replication_applier_status_by_worker`

3. Problemas no IO Thread: `replication_connection_status`

4. Erros detalhados: `performance_schema.error_log`

Checklist final antes do cutover

1. Pré-requisitos

2. Configurações no Aurora (source)

3. Exportação e Importação

4. Usuário de replicação

5. Canal de replicação

6. Cutover

Conclusão

Referências

Precisa de ajuda com migração de banco de dados?

Como Migrar do AWS Aurora MySQL para OCI HeatWave com Mínimo Downtime

O que você vai precisar antes de começar

A estratégia em duas etapas

Etapa 1: Exportação e Importação com MySQL Shell

Configurações obrigatórias no Aurora (source)

Exportando com util.dumpSchemas

Importando com util.loadDump

Etapa 2: Replicação em Tempo Real com OCI HeatWave Channel

Criando o usuário de replicação no Aurora (source)

O detalhe que quebra a maioria das migrações: o GTID

Configurando o Canal de Replicação no OCI Console

Como monitorar a replicação

1. Visão geral rápida: SHOW REPLICA STATUS\G

2. Detalhamento por worker: replication_applier_status_by_worker

3. Problemas no IO Thread: replication_connection_status

4. Erros detalhados: performance_schema.error_log

Checklist final antes do cutover

1. Pré-requisitos

2. Configurações no Aurora (source)

3. Exportação e Importação

4. Usuário de replicação

5. Canal de replicação

6. Cutover

Conclusão

Referências

Precisa de ajuda com migração de banco de dados?

Exportando com `util.dumpSchemas`

Importando com `util.loadDump`

1. Visão geral rápida: `SHOW REPLICA STATUS\G`

2. Detalhamento por worker: `replication_applier_status_by_worker`

3. Problemas no IO Thread: `replication_connection_status`

4. Erros detalhados: `performance_schema.error_log`