Fases e considerações de migração

Concluído

Uma migração bem-sucedida equilibra considerações em várias fases.

Fases da migração

As migrações ocorrem em várias fases. Primeiro, planeje o escopo de migração: descoberta e avaliação de recursos de banco de dados, requisitos de negócios como tempo de inatividade e um plano de fallback se a migração falhar. Em seguida, prepare a migração provisionando os recursos apropriados e configurando a conectividade entre os ambientes de origem e de destino. Depois que a abordagem de migração estiver definida e os recursos estiverem prontos, você geralmente deseja executar uma execução seca em um ambiente de preparo para identificar problemas antes da migração de produção. Por fim, execute a migração final e valide seu progresso contínuo e a conclusão bem-sucedida.

Este módulo se concentra nas fases de preparação (2) e migração final (4, 5).

Considerações sobre migração

Você deve avaliar os requisitos de tempo de inatividade do aplicativo, compatibilidade de versão, rede e segurança, desempenho, custo e continuidade dos negócios.

Tempo de inatividade do aplicativo

Uma das primeiras coisas que você deve considerar é quanto tempo de inatividade seu cenário de negócios pode acomodar. A resposta restringe bastante suas opções de migração disponíveis.

O melhor tempo de inatividade é aquele que os usuários não notam. Na prática, as migrações são procedimentos complexos e as decisões sobre as considerações neste módulo ditarão o tempo de inatividade necessário. As compensações incluem disponibilidade versus o custo e o risco da migração. Devido à complexidade envolvida na redução do tempo de inatividade para minutos ou até segundos, é importante testar suposições e determinar quanto tempo de inatividade de migração é aceitável.

Migrações offline

Com uma migração offline, você deve desligar o aplicativo para mover o banco de dados. Isso garante que não haverá alterações nos dados durante a migração. No entanto, essa abordagem requer a derrubada do banco de dados para finalizar a exportação de dados. No mínimo, o tempo de inatividade será o tempo necessário para transferir os dados. Uma migração offline envolve:

1. Desconectar todos os aplicativos do banco de dados de origem.
2. Exportar o conteúdo do banco de dados de origem.
3. Importar os dados de origem para o banco de dados de destino.
4. Reconectar aplicativos ao banco de dados de destino após a conclusão da importação.

Alguns aplicativos têm janelas de manutenção agendadas durante períodos de tráfego baixo. Esses são ótimos momentos para executar migrações offline.

Uma migração offline incremental reduz o tempo de inatividade movendo a maior parte dos dados antes de colocar o aplicativo offline. Primeiro, migre um backup de banco de dados completo. Em seguida, migre as alterações para o banco de dados que ocorreu adicionado desde a migração anterior. Quando o tempo necessário para migrar essas novas alterações se ajustar ao seu tempo de inatividade aceitável, coloque o aplicativo offline para congelar os dados e finalizar a migração. Você pode constatar que um único incremento de migração é suficiente para reduzir o tempo de inatividade em uma ordem de grandeza ou mais, especialmente para bancos de dados com anos de histórico. Para bancos de dados grandes e ocupados, talvez seja necessário migrar vários incrementos para atingir o tempo de inatividade aceitável.

Migrações online

Com uma migração online, você pode reduzir ou até mesmo eliminar a necessidade de tempo de inatividade replicando alterações do servidor de origem para o servidor de destino durante a migração e, em seguida, cortando para o servidor de destino quando a replicação estiver totalmente sincronizada.

Às vezes, o tempo de inatividade é indesejável ou até inaceitável. Nesse caso, é impossível "congelar" o estado do banco de dados desativando o aplicativo. Em vez disso, o banco de dados de origem é replicado no banco de dados de destino durante operações normais. Quando o destino é totalmente apanhado com a origem, o aplicativo corta para o banco de dados de destino.

Uma migração online requer que você:

1. Comece a replicar o banco de dados de origem para o banco de dados de destino.
2. Quando o banco de dados de destino for capturado, congele o banco de dados de origem pausando o aplicativo ou forçando as gravações a falhar habilitando o modo somente leitura.
3. Quando o banco de dados de destino estiver 100% envolvido com as alterações, desative a replicação no destino.
4. Redirecione todos os clientes para o banco de dados de destino e retome as operações.
5. Desligue o banco de dados de origem herdado.

Comparar migrações online e offline

Embora as migrações offline exijam tempo de inatividade, a técnica de migração incremental discutida anteriormente reduz consideravelmente o tempo de inatividade. Vários incrementos podem reduzir a migração final para um dia de dados ou menos. Serviços automatizados como o DMS do Azure minimizam o tempo de inatividade executando uma série de migrações cada vez menores. Migrações offline incrementais também podem ser executadas manualmente se as configurações de rede impedirem a automação.

As migrações online coordenam uma operação delicada entre equipes de banco de dados e aplicativos. Os aplicativos cliente devem ser ferramentados para reagir normalmente a falhas de gravação para evitar perda de dados durante a migração. Os clientes também devem dar suporte à conexão a um novo servidor de banco de dados sem interromper a experiência do usuário. Se essa ferramenta de aplicativo ainda não existir, pode ser muito caro compilar.

Compatibilidade entre versões

A maioria das operações de aplicativo é compatível com atualizações do MySQL. No entanto, em alguns casos, os componentes do aplicativo ou o uso do banco de dados só podem funcionar com determinadas versões do MySQL.

Verifique se todos os componentes do aplicativo são compatíveis com a versão do banco de dados de destino. Considere separar atualizações de versão de migrações que realocam ou reconfiguram um banco de dados. Por exemplo, se estiver migrando do MySQL 5.7 local para um servidor flexível do Banco de Dados do Azure para MySQL executando o MySQL 8.0, considere migrar do local para um servidor flexível do Banco de Dados do Azure para MySQL executando o MySQL 5.7 e atualizar de 5.7 para 8.0 in-loco.

Rede e segurança

As migrações de banco de dados exigem a transferência de dados do banco de dados de origem para o destino. Como isso acontece e quão rápido depende, em grande parte, da conexão entre as duas redes. Se você não conseguir estabelecer uma conexão dinâmica da origem para o destino, precisará transferir arquivos de dados físicos de outra maneira, por exemplo, por meio de uma estação de trabalho ou servidor intermediário. Nesse caso, verifique se você tem espaço em disco suficiente para armazenar os instantâneos em cada sistema ao longo do caminho.

Também é vital considerar os requisitos de segurança durante a migração. Você precisará de autenticação e permissões apropriadas para bancos de dados de origem e de destino. Você também pode querer criar contas de serviço para executar algumas ou todas as etapas de migração e, em seguida, você pode remover o acesso deles após a conclusão.

Se o banco de dados de origem está local ou localizado em outro provedor de nuvem, as configurações de rede normalmente não permitem conexões externas. Você precisará configurar a rede para permitir conexões com o Azure.

Se o banco de dados de origem for local e o volume de dados for grande, a movimentação de terabytes de dados em uma conexão de Internet regular poderá ser impraticável. Nesse cenário, considere configurar uma conexão do Azure ExpressRoute entre sua rede e o Azure.

Mesmo que você use um ExpressRoute, a conexão em que ele está provavelmente também atenderá a outro tráfego, e os dois podem interferir uns com os outros. Dependendo da contenção, o desempenho atingido para aplicativos existentes e o processo de migração podem ser significativos.

Desempenho

As migrações de banco de dados são uma excelente oportunidade para aumentar a capacidade redimensionando a infraestrutura. O uso do banco de dados pode se beneficiar do aumento dos recursos de CPU, RAM ou E/S.

Antes de provisionar o servidor de destino, considere o uso atual do banco de dados. Monitore as métricas de desempenho, como o uso da CPU, juntamente com a previsão de crescimento e SLAs para decidir se você deve alocar um tamanho de computação maior. Por outro lado, você pode descobrir que sua capacidade está excessivamente alocada e esse redução economiza custos.

Custo

Ao migrar para o Azure, você pode aproveitar preços transparentes. Usando o SKU selecionado e outros parâmetros, como redundância e alta disponibilidade, a calculadora de preços do Azure permite estimar os custos pós-migração durante o planejamento. Você também pode usar a calculadora para informar as compensações, como disponibilidade versus custo.

Continuidade de negócios

As migrações de banco de dados são um bom momento para examinar as metas e as métricas de continuidade dos negócios. Pode ser apropriado alterar as políticas de retenção de backup ou mudar para backups com redundância geográfica ou alta disponibilidade. Considere o tempo de atividade histórico em comparação ao SLA e ao tempo de recuperação de interrupção. As migrações também fornecem exemplos reais de como levantar um novo banco de dados de arquivos de dados físicos, que podem informar planos de recuperação de desastre.