As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Fase 3: Migrar
Depois de concluir o planejamento da migração e identificar uma estratégia de migração, a migração real acontece. Nessa fase, o banco de dados de destino é projetado, os dados de origem são migrados para o destino e os dados são validados.
![\[Iterative migration process\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/strategy-database-migration/images/iterative-migration-process.png)
Este é um processo iterativo que inclui vários ciclos de conversão, migração e teste. Depois que o teste funcional e de desempenho estiver concluído, você poderá passar para o novo banco de dados.
A fase de migração consiste nas seguintes etapas principais, que são abordadas nas seções a seguir:
+ [Converter o esquema](convert-schema.md)
+ [Migrar os dados](migrate-data.md)
+ [Atualizar o aplicativo](update-app.md)
+ [Testar a migração dos dados](test-migration.md)
+ [Passando para o novo banco de dados](cut-over.md)
# Converta o esquema
Uma das principais tarefas durante a migração do banco de dados é migrar o seu esquema do mecanismo do banco de dados de origem para o mecanismo do banco de dados de destino. Se você redefinir a hospedagem ou redefinir a plataforma, seu mecanismo de banco de dados não mudará. Isso é chamado de *migração homogênea de banco de dados* e você pode usar suas ferramentas de banco de dados nativas para migrar o esquema.
No entanto, se você estiver redefinido a arquitetura do seu aplicativo, a conversão do esquema pode exigir mais esforço. Nesse caso, você fará uma *migração heterogênea de banco de dados*, na qual os mecanismos de banco de dados de origem e de destino serão diferentes. Seu esquema de banco de dados atual pode estar usando pacotes e atributos que não podem ser convertidos diretamente para o mecanismo do banco de dados de destino. Alguns atributos podem estar disponíveis com um nome diferente. Portanto, a conversão do esquema exige um bom entendimento dos mecanismos dos bancos de dados de origem e destino. Essa tarefa pode ser desafiadora, dependendo da complexidade do seu esquema atual.
O AWS fornece dois recursos para ajudar você na conversão de esquemas: AWS Schema Conversion Tool (AWS SCT) e manuais de migração.
## AWS SCT
O AWS SCT é uma ferramenta gratuita que pode ajudar você a converter seu banco de dados existente de um mecanismo para outro. O AWS SCT suporta vários bancos de dados de origem, incluindo Oracle, Microsoft SQL Server, MySQL, Sybase e IBM Db2 LUW. Você pode escolher entre bancos de dados de origem, como o Aurora MySQL e o Aurora PostgreSQL.
O AWS SCT fornece uma interface gráfica de usuário que se conecta diretamente aos bancos de dados de origem e de destino para buscar os objetos do esquema atual. Quando conectados, você pode gerar um relatório para avaliar a migração do banco de dados e obter um resumo de alto nível do esforço de conversão e dos itens de ação. A ilustração na tela a seguir mostra um exemplo de relatório para avaliar a migração do banco de dados.
![\[Sample database migration assessment report from AWS SCT\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/strategy-database-migration/images/sct-assessment-report.png)
Com o AWS SCT você pode converter o esquema e implantá-lo diretamente no banco de dados de destino, ou você pode obter arquivos SQL para o esquema convertido. Para obter mais informações, consulte [Uso da interface de usuário do AWS Schema Conversion Tool](https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_UserInterface.html) na documentação do AWS.
## Manuais de migração
Embora o AWS SCT converta muitos de seus objetos de origem, alguns aspectos da conversão exigem intervenção e ajustes manuais. Para ajudar nessa tarefa, o AWS fornece manuais de migração que detalham incompatibilidades e semelhanças entre dois bancos de dados. Para obter mais informações sobre esses manuais, consulte [recursos AWS Database Migration Service](https://aws.amazon.com/dms/resources/) no AWS site.
# Migrar os dados
Quando a migração do esquema estiver concluída, você poderá mover os dados do banco de dados de origem para o banco de dados de destino. Dependendo dos requisitos de disponibilidade do seu aplicativo, você pode executar um trabalho de extração simples que executa uma cópia única dos dados de origem no novo banco de dados. Ou você pode usar uma ferramenta que copia os dados atuais e continua a replicar todas as alterações até que você esteja pronto para migrar para o novo banco de dados. Para migrações de redefinição de hospedagem e de plataforma, recomendamos que você use ferramentas nativas específicas do banco de dados para migrar seus dados.
As ferramentas que podem ajudar você na transferência de dados incluem o AWS Database Migration Service (AWS DMS) e ferramentas de migração offline. Elas estão descritas nas seções a seguir.
## AWS DMS
Depois de usar o AWS SCT para converter seus objetos do esquema do mecanismo de banco de dados de origem para o mecanismo de destino, você pode usar o AWS DMS para migrar os dados. Com o AWS DMS você pode manter o banco de dados de origem ativo e funcionando enquanto os dados estão sendo replicados. Você pode realizar uma cópia única dos seus dados ou copiar com replicação contínua. Quando os bancos de dados de origem e destino estiverem sincronizados, você pode deixar o seu banco de dados offline e mover suas operações para o banco de dados de destino. O AWS DMS pode ser usado para migrações de banco de dados homogêneas (por exemplo, de um banco de dados Oracle on-premises para um banco de dados Amazon RDS para Oracle), bem como migrações heterogêneas (por exemplo, de um banco de dados Oracle on-premises para um banco de dados Amazon RDS para PostgreSQL). Para obter mais informações sobre como trabalhar com o AWS DMS, consulte a [documentação do AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html).
## Opções de migração offline
Você pode usar outras opções além do AWS DMS para extrair os dados do banco de dados de origem e carregá-los no banco de dados de destino. Essas opções são adequadas principalmente quando o tempo de inatividade do aplicativo é permitido durante a atividade de migração de dados. Exemplos desses métodos incluem:
+ Uma extração de valores separados por vírgula (CSV) do banco de dados de origem carregado no banco de dados de destino
+ Para bancos de dados de origem Oracle, o utilitário **ora2pg** para copiar os dados para o PostgreSQL
+ Tarefas personalizadas de extração, transformação e carregamento (ETL) para copiar os dados da origem para o destino
# Atualizar o aplicativo
Uma migração de banco de dados raramente é uma migração somente do banco de dados. Você precisa examinar o aplicativo que está usando o banco de dados para garantir que ele funcione corretamente com o novo banco de dados. As alterações são mínimas se você simplesmente redefinir a hospedagem ou redefinir a plataforma do mesmo mecanismo de banco de dados, mas podem ser mais significativas se você decidir migrar para um novo mecanismo de banco de dados.
Se o seu aplicativo depende de um mapeamento objeto-relacional (ORM) para interagir com o banco de dados, ele não precisará de tantas alterações ao migrar para um novo mecanismo de banco de dados. Porém, se o seu aplicativo tiver interações de banco de dados personalizadas ou consultas SQL criadas dinamicamente, as alterações poderão ser consideráveis. Pode haver diferenças nos formatos de consulta que precisem ser corrigidas para garantir que o aplicativo funcione conforme o esperado.
Por exemplo, no Oracle, concatenar uma string com `NULL` retorna a string original. Porém, no PostgreSQL, concatenar uma string com `NULL` retorna `NULL`. Outro exemplo é como as cadeias `NULL` e vazias são tratadas. No PostgreSQL, strings `NULL` e strings vazias são duas coisas diferentes, enquanto bancos de dados como o Oracle as tratam da mesma maneira. No Oracle, se você inserir uma linha com o valor da coluna definido como `NULL` ou uma string vazia, você pode buscar os dois tipos de valores usando a cláusula `where`: `where is NULL`. No PostgreSQL, essa cláusula `where` retornará somente uma linha em que o valor da coluna seja realmente NULL; ela não retornará a linha que tem um valor de string vazio. Para obter mais informações sobre essas diferenças, consulte os manuais de migração listados na página web de [recursos AWS Database Migration Service](https://aws.amazon.com/dms/resources/).
# Testar a migração
Os testes funcionais e de desempenho são uma parte essencial das migrações de bancos de dados. Testes funcionais detalhados garantirão que seu aplicativo esteja funcionando com o novo banco de dados sem problemas. Você deve dedicar tempo ao desenvolvimento de testes de unidades para testar os fluxos de trabalho do aplicativo.
O teste de desempenho garante que os tempos de resposta do seu banco de dados estejam dentro de um intervalo de tempo aceitável. Você pode identificar gargalos, otimizar e repetir o teste de desempenho. Você repete o ciclo conforme necessário para obter os resultados de desempenho desejados.
O teste pode ser manual ou automatizado. Recomendamos que você use uma estrutura automatizada para o teste. Durante a migração, você precisará executar o teste várias vezes, portanto, ter uma estrutura de teste automatizada ajuda a acelerar os ciclos de correção e otimização de bugs.
Esse teste pode revelar problemas que não foram percebidos durante as fases de desenvolvimento. Por exemplo, qualquer consulta convertida incorretamente irá falhar ou retornar resultados incorretos, fazendo com que o teste funcional falhe. O teste de desempenho pode revelar problemas, como índices ausentes, causando lentidão no tempo de resposta da consulta. Eles também podem revelar problemas de desempenho que exigem o ajuste do mecanismo de banco de dados, dependendo da workload, ou a modificação da consulta.
# 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.
1. Iniciar o tempo de inatividade para o tráfego de gravação.
1. Migrar os dados usando uma das opções de migração offline.
1. Verificar seus dados.
1. Apontar seu aplicativo para o novo banco de dados.
1. 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.
1. Configurar o AWS DMS no modo de replicação contínua de dados.
1. Verificar os dados quando os bancos de dados de origem e de destino estiverem sincronizados.
1. Iniciar o tempo de inatividade do aplicativo.
1. Implementar o novo versionamento do aplicativo, que aponta para o novo banco de dados.
1. 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](https://www.hvr-software.com/product/), 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.
1. 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.
1. Verificar os dados quando os bancos de dados de origem e de destino estiverem sincronizados.
1. Começar a mover um subconjunto do seu tráfego para o novo banco de dados.
1. 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](https://samirbehara.com/2018/09/10/monolith-to-microservices-using-strangler-pattern/) 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.
# Siga as práticas recomendadas em AWS
Além das atividades de migração discutidas nas seções anteriores, você deve investir tempo para garantir que está seguindo as melhores práticas para hospedar seu banco de dados na nuvem AWS. Consulte a [documentação da AWS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.html) para obter as melhores práticas para trabalhar com bancos de dados relacionais na AWS.