Fases e considerações de migração

Concluído

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

Fases de migração

As migrações ocorrem em várias fases. Primeiro, planeje o escopo da 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 recursos apropriados e configurando a conectividade entre os ambientes de origem e de destino. Depois que a abordagem de migração é definida e os recursos estão 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 conclusão bem-sucedida.

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

Migration considerations (Considerações sobre a 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 de 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 fortemente as opções de migração disponíveis.

O melhor tempo de inatividade é aquele que os usuários não percebem. 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 a 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 retirada 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. Desconectando todos os aplicativos do banco de dados de origem.
2. Exportação do conteúdo do banco de dados de origem.
3. Importando os dados de origem para o banco de dados de destino.
4. Reconectando aplicativos ao banco de dados de destino após a conclusão da importação.

Algumas aplicações têm janelas de manutenção programada durante períodos de baixo tráfego. Estes são ótimos momentos para realizar 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 ocorreram adicionadas desde a migração anterior. Quando o tempo necessário para migrar essas novas alterações estiver dentro do tempo de inatividade aceitável, coloque o aplicativo offline para congelar os dados e finalizar a migração. Você pode achar que um único incremento de migração é suficiente para reduzir o tempo de inatividade em uma ordem de magnitude ou mais, especialmente para bancos de dados com anos de história. Para bancos de dados grandes e ocupados, talvez seja necessário migrar vários incrementos para atingir um tempo de inatividade aceitável.

Migrações online

Com uma migração online , você pode reduzir significativamente ou até mesmo eliminar a necessidade de tempo de inatividade replicando as 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 mesmo 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 as operações normais. Quando o destino é totalmente alcançado 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% atualizado com as alterações, desative a replicação no destino.
4. Redirecionar todos os clientes para o banco de dados de destino e retomar 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 Azure DMS minimizam o tempo de inatividade executando uma série de migrações cada vez menores. As migrações offline incrementais também podem ser executadas manualmente se as configurações de rede impedirem a automação.

As migrações on-line coordenam uma operação delicada entre as equipes de banco de dados e aplicativos. Os aplicativos cliente devem ser preparados para reagir normalmente a falhas de gravação para evitar a perda de dados durante a migração. Os clientes também devem oferecer suporte à conexão com 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 criar.

Compatibilidade de versões

A maioria das operações de aplicativos são compatíveis com atualizações do MySQL. No entanto, em alguns casos, os componentes do aplicativo ou o uso do banco de dados podem funcionar apenas 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 as atualizações de versão das migrações que realocam ou reconfiguram um banco de dados. Por exemplo, se migrar 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, em seguida, atualizar do 5.7 para o 8.0 in-loco.

Redes 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 com que rapidez, depende em grande parte da conexão entre as duas redes. Se não conseguir estabelecer uma ligação em tempo real da origem para o destino, terá de transferir ficheiros de dados físicos de outra forma, por exemplo, através de uma estação de trabalho ou servidor intermédio. Nesse caso, certifique-se de ter 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 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 seu acesso após a conclusão.

Quer o banco de dados de origem esteja no 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, mover terabytes de dados por uma conexão regular com a Internet pode ser impraticável. Nesse cenário, considere configurar uma conexão de Rota Expressa do Azure entre sua rede e o Azure.

Mesmo que você use uma Rota Expressa, a conexão em que ela está provavelmente também servirá para outro tráfego, e os dois podem interferir um com o outro. Dependendo da contenção, o impacto no desempenho dos 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 métricas de desempenho, como o uso da CPU, juntamente com previsão de crescimento e SLAs para decidir se você deve alocar um tamanho de computação maior. Por outro lado, você pode achar que sua capacidade está superalocada e que o downsizing economiza custos.

Custo

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

Continuidade do negócio

As migrações de banco de dados são um bom momento para rever as métricas e metas de continuidade de 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 seu tempo de atividade histórico versus SLA e tempo de recuperação de interrupções. As migrações também fornecem exemplos reais de como criar um novo banco de dados a partir de arquivos de dados físicos, que podem informar os planos de recuperação de desastres.