Substitua

A estratégia de substituição do banco de dados geralmente está profundamente associada aos requisitos de tempo de inatividade do aplicativo. As estratégias que você pode usar para a substituição do banco de dados incluem migração offline, migração instantânea (flash-cut), configuração ativa/ativa do banco de dados e migração incremental. Elas são discutidas nas seções a seguir.

Migração offline

Se você puder deixar seu aplicativo offline por um longo período durante as operações de gravação, poderá usar as configurações de tarefas de carga total da AWS DMS ou uma das opções de migração offline para a sua migração de dados. O tráfego de leitura pode continuar enquanto essa migração estiver em andamento, mas o tráfego de gravação deve ser interrompido. Como todos os dados precisam ser copiados do banco de dados de origem, os recursos do banco de dados de origem, como E/S e CPU, serão utilizados.

Em um nível mais alto, a migração offline consiste das seguintes etapas:

1. Concluir a conversão do esquema.

2. Iniciar o tempo de inatividade para o tráfego de gravação.

3. Migrar os dados usando uma das opções de migração offline.

4. Verificar seus dados.

5. Apontar seu aplicativo para o novo banco de dados.

6. Encerrar o tempo de inatividade do aplicativo.

Migração instantânea

Na migração instantânea, o objetivo principal é reduzir ao mínimo o tempo de inatividade. Essa estratégia depende da replicação contínua de dados (CDC) do banco de dados de origem para o banco de dados de destino. Todo o tráfego de leitura/gravação continuará no banco de dados atual enquanto os dados estiverem sendo migrados. Como todos os dados precisam ser copiados do banco de dados de origem, os recursos do servidor-fonte, como I/O e CPU, serão utilizados. Você deve fazer testes para garantir que essa atividade de migração de dados não afete os SLAs de desempenho do seu aplicativo.

Em um nível mais alto, a migração instantânea consiste das seguintes etapas:

1. Concluir a conversão do esquema.

2. Configurar o AWS DMS no modo de replicação contínua de dados.

3. Verificar os dados quando os bancos de dados de origem e de destino estiverem sincronizados.

4. Iniciar o tempo de inatividade do aplicativo.

5. Implementar o novo versionamento do aplicativo, que aponta para o novo banco de dados.

6. Encerrar o tempo de inatividade do aplicativo.

Configuração ativa/ativa do banco de dados

A configuração ativa/ativa do banco de dados envolve a configuração de um mecanismo para manter os bancos de dados de origem e destino sincronizados enquanto os dois bancos de dados estão sendo usados para tráfego de gravação. Essa estratégia envolve mais trabalho do que a migração offline ou instantânea, mas também oferece mais flexibilidade durante a migração. Por exemplo, além de oferecer um tempo de inatividade mínimo durante a migração, você pode mover seu tráfego de produção para o novo banco de dados em lotes pequenos e controlados, em vez de realizar a substituição de uma vez só. Você pode realizar operações de gravação dupla para que as alterações sejam feitas nos dois bancos de dados ou usar uma ferramenta de replicação bidirecional, como o HVR, para manter os bancos de dados sincronizados. Essa estratégia tem uma complexidade maior em termos de configuração e manutenção e, portanto, requer mais testes para evitar problemas de consistência de dados.

Em um alto nível, a configuração ativa/ativa do banco de dados envolve estas etapas:

1. Concluir a conversão do esquema.

2. Copiar os dados existentes do banco de dados de origem para o banco de dados de destino e, em seguida, manter os dois bancos de dados sincronizados usando uma ferramenta de replicação bidirecional ou gravações duplas do aplicativo.

3. Verificar os dados quando os bancos de dados de origem e de destino estiverem sincronizados.

4. Começar a mover um subconjunto do seu tráfego para o novo banco de dados.

5. Continuar movendo o tráfego até que todo o tráfego do seu banco de dados tenha sido movido para o novo banco de dados.

Migração incremental

Na migração incremental, você migra seu aplicativo em partes menores, em vez de realizar uma substituição única e total. Essa estratégia de substituição pode ter muitas variações, com base na sua arquitetura atual do aplicativo ou na refatoração que você está disposto a fazer no aplicativo.

Você pode usar um padrão de design para adicionar novos microsserviços independentes para substituir partes de um aplicativo legado e monolítico existente. Esses microsserviços independentes têm suas próprias tabelas que não são compartilhadas e nem acessadas por nenhuma outra parte do aplicativo. Você migra esses microsserviços para o novo banco de dados um por um, usando qualquer uma das outras estratégias de substituição. Os microsserviços migrados começam a usar o novo banco de dados para o tráfego de leitura/gravação, enquanto todas as outras partes do aplicativo continuam usando o banco de dados antigo. Quando todos os microsserviços tiverem sido migrados, você descomissionará o seu aplicativo legado. Essa estratégia divide a migração em partes menores e gerenciáveis e, portanto, pode reduzir os riscos associados a uma grande migração.