Estratégias de migração de banco de dados do SQL Server
Em um alto nível, há duas opções para migrar um banco de dados do SQL Server de on-premises para a AWS nuvem: permanecer no SQL Server (migração homogênea) ou sair do SQL Server (migração heterogênea). Em uma migração homogênea, você não altera o mecanismo do banco de dados. Ou seja, seu banco de dados de destino também é um banco de dados do SQL Server. Em uma migração heterogênea, você muda seus bancos de dados do SQL Server para um mecanismo de banco de dados de código aberto, como MySQL, PostgreSQL ou MariaDB, ou para um banco de dados nativo de nuvem AWS, como Amazon Aurora, Amazon DynamoDB ou Amazon Redshift.
Há três estratégias comuns para migrar seu banco de dados SQL Server para AWS: redefinir a hospedagem, redefinir a plataforma e redefinir a arquitetura (refatorar). Elas fazem parte dos 7 Rs das estratégias de migração de aplicativos e estão descritas na tabela a seguir.
| Strategy | Tipo | Quando escolher | Exemplo |
|---|---|---|---|
Redefinir a hospedagem |
Homogêneo |
Você deseja migrar seu banco de dados SQL Server como está, com ou sem alterar o sistema operacional, o software do banco de dados ou a configuração. |
SQL Server para Amazon EC2 |
Redefinir a plataforma |
Homogêneo |
Você quer reduzir o tempo gasto gerenciando instâncias de banco de dados usando uma oferta de banco de dados totalmente gerenciada. |
SQL Server para Amazon RDS para SQL Server |
Redefinir a arquitetura (refatorar) |
Heterogêneo |
Você quer reestruturar, reescrever e rearquitetar seu banco de dados e seu aplicativo para aproveitar os atributos de banco de dados de código aberto e nativos de nuvem. |
SQL Server para Amazon Aurora PostgreSQL, MySQL ou MariaDB |
Se você está tentando decidir entre redefinir a hospedagem ou redefinir a plataforma de seus bancos de dados do SQL Server, consulte Como escolher entre o Amazon EC2 e o Amazon RDS, mais adiante neste guia, para uma comparação lado a lado dos atributos compatíveis.
Escolhendo a estratégia de migração certa
A escolha da estratégia correta depende das necessidades de seus negócios, das restrições de recursos, do cronograma de migração e das considerações de custo. O diagrama a seguir mostra o esforço e a complexidade envolvidos nas migrações, incluindo todas as sete estratégias.
Refatorar seu banco de dados SQL Server e migrar para um banco de dados de código aberto ou nativo de nuvem AWS, como Amazon Aurora PostgreSQL Compatible Edition ou Aurora MySQL Compatible Edition, pode ajudá-lo a modernizar e otimizar seu banco de dados. Ao migrar para um banco de dados de código aberto, você pode evitar licenças caras (o que resulta em custos mais baixos), períodos de dependência de fornecedores e auditorias. No entanto, dependendo da complexidade de sua workload, refatorar seu banco de dados do SQL Server pode ser um esforço complicado, demorado e que consome muitos recursos.
Para reduzir a complexidade, em vez de migrar seu banco de dados em uma única etapa, você pode considerar uma abordagem em fases. Na primeira fase, você pode se concentrar na funcionalidade principal do banco de dados. Na próxima fase, você pode integrar AWS serviços adicionais em seu ambiente de nuvem para reduzir custos e otimizar o desempenho, a produtividade e a conformidade. Por exemplo, se sua meta é substituir seu banco de dados SQL Server on-premises por um compatível com o Aurora MySQL, considere redefinir a hospedagem de seu banco de dados no Amazon EC2 ou redefinir a plataforma de seu banco de dados no Amazon RDS para SQL Server na primeira fase e, em seguida, refatorar para o Aurora MySQL em uma fase subsequente. Essa abordagem ajuda a reduzir custos, recursos e riscos durante a fase de migração e se concentra na otimização e modernização na segunda fase.
Migração online e offline
Você pode usar dois métodos para migrar seu banco de dados do SQL Server de um ambiente on-premises ou de outro ambiente em nuvem para a nuvem AWS, com base no cronograma de migração e no tempo de inatividade que você pode permitir: migração offline ou migração online.
-
Migração off-line: esse método é usado quando seu aplicativo pode arcar com um tempo de inatividade planejado. Na migração off-line, o banco de dados de origem fica off-line durante o período de migração. Enquanto o banco de dados de origem está off-line, ele é migrado para o banco de dados de destino ativadoAWS. Após a conclusão da migração, as verificações de validação e verificação são realizadas para garantir a consistência de dados com o banco de dados de origem. Quando o banco de dados passa por todas as verificações de validação, você executa uma substituição para AWS conectando seu aplicativo ao banco de dados de destino em AWS.
-
Migração on-line: esse método é usado quando seu aplicativo exige um tempo de inatividade próximo a zero ou mínimo. Na migração on-line, o banco de dados de origem é migrado em várias etapas para AWS. Nas etapas iniciais, os dados no banco de dados de origem são copiados para o banco de dados de destino enquanto o banco de dados de origem ainda está em execução. Nas etapas subsequentes, todas as alterações do banco de dados de origem são propagadas para o banco de dados de destino. Quando os bancos de dados de origem e destino estão sincronizados, eles estão prontos para a substituição. Durante a substituição, o aplicativo ativa suas conexões com o banco de dados de destino em AWS, sem deixar conexões com o banco de dados de origem. Você pode usar AWS Database Migration Service (AWS DMS) ou ferramentas disponíveis em AWS Marketplace
(como Attunity) para sincronizar os bancos de dados de origem e destino.
