Modernizar bancos de dados do SQL Server.

Visão geral

Se você está iniciando uma jornada para modernizar bancos de dados legados para escalabilidade, performance e otimização de custos, talvez esteja enfrentando desafios com bancos de dados comerciais como o SQL Server. Os bancos de dados comerciais são caros, criam dependência do fornecedor e oferecem termos de licenciamento punitivos. Esta seção fornece uma visão geral de alto nível das opções de migração e modernização do SQL Server para bancos de dados de código aberto e informações sobre como escolher a melhor opção para sua workload.

Você pode refatorar seus bancos de dados do SQL Server em bancos de dados de código aberto, como o Amazon Aurora PostgreSQL, para economizar nos custos de licenciamento do Windows e do SQL Server. Bancos de dados modernos nativos da nuvem, como o Aurora, combinam a flexibilidade e o baixo custo dos bancos de dados de código aberto com os recursos robustos e de nível corporativo dos bancos de dados comerciais. Se você tiver workloads variáveis ou workloads multiocatárias, também poderá migrar para o Aurora Sem Servidor v2. Isso pode reduzir os custos em até 90%, dependendo das características da workload. Além disso, a AWS oferece recursos como o Babelfish para Aurora PostgreSQL, ferramentas como o AWS Schema Conversion Tool (AWS SCT) e serviços como o AWS Database Migration Service (AWS DMS) para simplificar a migração e a modernização dos bancos de dados do SQL Server na AWS.

Ofertas de banco de dados

A migração do SQL Server no Windows para bancos de dados de código aberto como o Amazon Aurora, Amazon RDS para MySQL ou Amazon RDS para PostgreSQL pode oferecer economias de custo significativas sem comprometer a performance ou os recursos. Considere o seguinte:

Para workloads de banco de dados tradicionais, o Amazon RDS para PostgreSQL e o Amazon RDS para MySQL atendem aos requisitos e fornecem uma solução econômica para bancos de dados relacionais. O Aurora adicionou vários recursos de disponibilidade e performance antes limitados a fornecedores comerciais caros. Os recursos de resiliência do Aurora têm um custo adicional. No entanto, em comparação com recursos semelhantes de outros fornecedores comerciais, os custos de resiliência do Aurora ainda são mais baratos do que os cobrados por softwares comerciais pelo mesmo tipo de recursos. A arquitetura do Aurora é otimizada para oferecer melhorias significativas na performance em comparação com as implantações padrão do MySQL e do PostgreSQL.

Como o Aurora é compatível com bancos de dados PostgreSQL e MySQL de código aberto, há o benefício adicional da portabilidade. Se a melhor opção for o Amazon RDS para PostgreSQL, o Amazon RDS para MySQL ou o Aurora, tudo se resume a entender os requisitos dos negócios e mapear os recursos necessários para a melhor opção.

Comparação entre o Amazon RDS e o Aurora

A tabela a seguir resume as principais diferenças entre o Amazon RDS e o Amazon Aurora.

*Transações grandes podem aumentar os tempos de failover

**Disponível no Aurora PostgreSQL

A tabela a seguir mostra o custo mensal estimado dos diferentes serviços de banco de dados abordados nesta seção.

* O preço do armazenamento está incluído no preço da instância. Os custos são baseados na região us-east-1. O throughput e a IOPS são suposições. Os cálculos são para instâncias r6i.2xlarge e r6g.2xlarge.

Recomendações de otimização de custos

As migrações de banco de dados heterogêneas geralmente exigem a conversão do esquema do banco de dados do mecanismo de banco de dados de origem para o de destino e a migração de dados do banco de dados de origem para o de destino. A primeira etapa para a migração é avaliar e converter objetos de código e esquema do SQL Server no mecanismo de banco de dados de destino.

Você pode usar o AWS Schema Conversion Tool (AWS SCT) para avaliar e analisar a compatibilidade do banco de dados com várias opções de banco de dados de código aberto de destino, como o Amazon RDS para MySQL ou o Amazon RDS para PostgreSQL, o Aurora MySQL e o PostgreSQL. Você também pode usar a ferramenta Babelfish Compass para avaliar a compatibilidade com o Babelfish para Aurora PostgreSQL. Isso faz com que o AWS SCT e o Compass sejam ferramentas robustas para entender o trabalho inicial envolvido antes de decidir sobre uma estratégia de migração. Se você decidir continuar, o AWS SCT automatizará as alterações necessárias no esquema. A filosofia central por trás do Babelfish Compass é permitir a migração do banco de dados SQL para o Aurora sem nenhuma ou com pouquíssimas alterações. O Compass avaliará o banco de dados SQL existente para determinar se isso pode ser feito. Dessa forma, o resultado é conhecido antes que qualquer esforço seja feito na migração de dados do SQL Server para o Aurora.

O AWS SCT automatiza a conversão e a migração do esquema e do código do banco de dados para o mecanismo do banco de dados de destino. Você pode usar o Babelfish para Aurora PostgreSQL para migrar seu banco de dados e a aplicação do SQL Server para o Aurora PostgreSQL sem nenhuma ou com o mínimo de alterações no esquema. Isso pode acelerar suas migrações.

Depois que o esquema for migrado, você poderá usar o AWS DMS para migrar os dados. O AWS DMS pode realizar o carregamento total dos dados e replicar as alterações para realizar a migração com o mínimo de tempo de inatividade.

Esta seção explora as seguintes ferramentas com mais detalhes:

AWS Schema Conversion Tool

Você pode usar o AWS SCT para avaliar seus bancos de dados existentes do SQL Server e avaliar a compatibilidade com o Amazon RDS ou o Aurora. Para simplificar o processo de migração, você também pode usar o AWS SCT para converter o esquema de um mecanismo de banco de dados para outro em uma migração de banco de dados heterogênea. Você pode usar o AWS SCT para avaliar sua aplicação e converter o código de aplicação incorporado para aplicações escritas em C#, C++, Java e outras linguagens. Para obter mais informações, consulte Converting application SQL using AWS SCT na documentação do AWS SCT.

O AWS SCT é uma ferramenta gratuita da AWS compatível com várias origens de banco de dados. Para usar o AWS SCT, você o aponta para o banco de dados de origem e, em seguida, executa uma avaliação. Em seguida, o AWS SCT avalia o esquema e gera o relatório de avaliação. Os relatórios de avaliação incluem um resumo executivo, a complexidade e o esforço de migração, mecanismos de banco de dados de destino adequados e recomendações para conversão. Para fazer o download do AWS SCT, consulte Installing, verifying, and updating AWS SCT na documentação do AWS SCT.

A tabela a seguir mostra um exemplo de resumo executivo gerado pelo AWS SCT para mostrar a complexidade envolvida na alteração do banco de dados para diferentes plataformas de destino.

Um relatório do AWS SCT também fornece detalhes sobre os elementos do esquema que não podem ser convertidos automaticamente. Você pode fechar as lacunas de conversão do AWS SCT e otimizar os esquemas de destino consultando os playbooks de migração da AWS. Há muitos playbooks de migração de banco de dados para ajudar em migrações heterogêneas.

Babelfish for Aurora PostgreSQL

O Babelfish para Aurora PostgreSQL estende o Aurora PostgreSQL com a capacidade de aceitar conexões de banco de dados de clientes do SQL Server. O Babelfish permite que as aplicações originalmente criadas para o SQL Server possam funcionar diretamente com o Aurora PostgreSQL, com poucas alterações de código e sem alterar drivers de banco de dados. O Babelfish torna o Aurora PostgreSQL bilíngue para que o Aurora PostgreSQL possa funcionar com as linguagens T-SQL e PL/pgSQL. O Babelfish minimiza os esforços de migração do SQL Server para o Aurora PostgreSQL. Isso acelera as migrações, minimiza os riscos e reduz significativamente os custos de migração. Você pode continuar a usar T-SQL após as migrações, mas também há a opção de usar ferramentas nativas do PostgreSQL para desenvolvimento.

O diagrama a seguir ilustra como uma aplicação usando T-SQL se conecta à porta padrão 1433 no SQL Server e usa o tradutor Babelfish para se comunicar com o banco de dados Aurora PostgreSQL, enquanto uma aplicação usando PL/pgSQL pode se conectar direta e simultaneamente ao banco de dados Aurora PostgreSQL usando a porta padrão 5432 no Aurora PostgreSQL.

O Babelfish não é compatível com determinados recursos T-SQL do SQL Server. Por esse motivo, a Amazon fornece ferramentas de avaliação para fazer uma análise linha por linha de suas instruções SQL e determinar se alguma delas não é compatível com o Babelfish.

Há duas opções para avaliações do Babelfish. O AWS SCT pode avaliar a compatibilidade do seu banco de dados SQL Server com o Babelfish. Outra opção é a ferramenta Babelfish Compass, que é uma solução recomendada porque a ferramenta Compass é atualizada de acordo com as novas versões do Babelfish para Aurora PostgreSQL.

Babelfish Compass

O Babelfish Compass é uma ferramenta gratuita para download que se alinha à versão mais recente do Babelfish para Aurora PostgreSQL. Em contraste, o AWS SCT será compatível com as versões mais recentes do Babelfish depois de algum tempo. O Babelfish Compass é executado no esquema do banco de dados SQL Server. Você também pode extrair o esquema do banco de dados do SQL Server de origem usando ferramentas como o SQL Server Management Studio (SSMS). Em seguida, você pode executar o esquema por meio do Babelfish Compass. Isso gera o relatório detalhando a compatibilidade do esquema do SQL Server com o Babelfish e se alguma alteração é necessária antes da migração. A ferramenta Babelfish Compass também pode automatizar muitas dessas alterações e, finalmente, acelerar suas migrações.

Depois que a avaliação e as alterações forem concluídas, você poderá migrar o esquema para o Aurora PostgreSQL usando ferramentas nativas do SQL Server, como o SSMS ou sqlcmd. Para obter instruções, consulte a publicação Migrate from SQL Server to Amazon Aurora using Babelfish no blog AWS Database.

AWS Database Migration Service

Depois que o esquema for migrado, você poderá usar o AWS Database Migration Service (AWS DMS) para migrar os dados para a AWS com o mínimo de tempo de inatividade. O AWS DMS não apenas carrega os dados por completo, mas também replica as alterações da origem para o destino enquanto o sistema de origem está ativo e em execução. Depois que os bancos de dados de origem e de destino estiverem sincronizados, a atividade de substituição pode ocorrer onde a aplicação é direcionada para o banco de dados de destino, concluindo a migração. O AWS DMSatualmente só executa o carregamento total de dados com o Babelfish para um destino do Aurora PostgreSQL e não replica as alterações. Para obter mais informações, consulte Using Babelfish as a target for AWS Database Migration Service na documentação do AWS DMS.

O AWS DMS pode fazer migrações homogêneas (no mesmo mecanismo de banco de dados) e heterogêneas (em diferentes mecanismos de banco de dados). O AWS DMS é compatível com vários mecanismos de banco de dados de origem e destino. Para obter mais informações, consulte a publicação Migrating your SQL Server database to Amazon RDS for SQL Server using AWS DMS no blog AWS Database.

Recursos adicionais