Migração de bancos de dados para o Amazon Aurorad0.awsstatic.com/whitepapers/RDS/Migrating_Databases_to_Amazon... · Migração de esquema usando a ferramenta de conversão de esquema

Migração de bancos de dados para o Amazon Aurora

Junho de 2016

Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016

Página 2 de 46

© 2016, Amazon Web Services, Inc. ou suas afiliadas. Todos os direitos reservados.

Avisos Este documento é fornecido apenas para fins informativos. Ele relaciona as atuais

ofertas de produtos e práticas da AWS a contar da data de emissão deste

documento, que estão sujeitas a alterações sem aviso prévio. Os clientes são

responsáveis por fazer sua própria avaliação independente das informações neste

documento e de qualquer uso dos produtos ou serviços da AWS, cada um dos

quais é fornecido “no estado em que se encontra”, sem garantia de qualquer tipo,

expressa ou implícita. Este documento não cria quaisquer garantias,

representações, compromissos contratuais, condições ou seguros da AWS, suas

afiliadas, fornecedores ou licenciadores. As responsabilidades e obrigações da

AWS em relação aos seus clientes são controladas por acordos da AWS, e este

documento não integra nem modifica nenhum acordo entre a AWS e seus clientes.


Página 3 de 46

Índice

Índice 3

Resumo 4

Introdução ao Amazon Aurora 4

Considerações sobre a migração de bancos de dados 6

Fases da migração 6

Considerações sobre aplicativos 6

Considerações sobre fragmentação e réplicas de leitura 8

Considerações sobre confiabilidade 8

Considerações sobre custo e licenciamento 9

Outras considerações sobre migração 9

Planejamento do processo de migração do banco de dados 10

Migração homogênea 10

Migração heterogênea 13

Migração de grandes bancos de dados para o Amazon Aurora 14

Consolidação de partições e fragmentos no Amazon Aurora 15

Visão geral das opções de migração 16

Migração de snapshot do RDS 17

Migração do esquema de banco de dados 22

Migração de esquema homogênea 22

Migração de esquema heterogênea 24

Migração de esquema usando a ferramenta de conversão de esquema da AWS

25

Migração de dados 33

Introdução e abordagem geral ao AWS DMS 33

Métodos de migração 34

Procedimento de migração 35


Página 4 de 46

Testes e transição 42

Testes de migração 42

Transição 43

Conclusão 44

Colaboradores 45

Leitura complementar 45

Observações 45

Resumo O Amazon Aurora é um mecanismo de banco de dados relacional de nível

empresarial compatível com MySQL. O Amazon Aurora é um banco de dados

nativo da nuvem que supera muitas limitações dos mecanismos de banco de

dados relacional tradicionais. O objetivo deste whitepaper é destacar as melhores

práticas da migração dos bancos de dados existentes para o Amazon Aurora. Ele

apresenta considerações sobre a migração e o processo passo a passo da migração

de bancos de dados comerciais e de código aberto para o Amazon Aurora com

interrupção mínima para os aplicativos.

Introdução ao Amazon Aurora Há décadas, os bancos de dados relacionais tradicionais têm sido a principal

opção para armazenamento físico de dados e persistência. Esses sistemas de

banco de dados continuam dependendo de arquiteturas monolíticas e não foram

desenvolvidos para aproveitar a infraestrutura de nuvem. Essas arquiteturas

monolíticas apresentam muitos desafios, principalmente em áreas como custo,

flexibilidade e disponibilidade. Para enfrentar esses desafios, a AWS reformulou

o banco de dados relacional para a infraestrutura de nuvem e lançou

o Amazon Aurora.

O Amazon Aurora é um mecanismo de banco de dados relacional compatível com

MySQL que combina a velocidade, a disponibilidade e a segurança dos bancos de

dados comerciais de tecnologia de ponta com a simplicidade e a relação

custo/benefício dos bancos de dados de código aberto. O Aurora proporciona um

desempenho até cinco vezes melhor do que o MySQL e um desempenho


Página 5 de 46

comparável ao dos bancos de dados comerciais de tecnologia de ponta. O preço

do Amazon Aurora é um décimo do custo dos mecanismos comerciais.

O Amazon Aurora é disponibilizado pela plataforma Amazon Relational Database

Service (Amazon RDS). Assim como outros bancos de dados Amazon RDS,

o Aurora é um banco de dados gerenciado. Com a plataforma Amazon RDS,

a maioria das tarefas de gerenciamento de banco de dados, como

provisionamento de hardware, patch de software, instalação, configuração,

monitoramento e backup, é totalmente automatizada.

O Amazon Aurora foi desenvolvido para cargas de trabalho de missão crítica

e é altamente disponível por padrão. Um cluster de bancos de dados do Aurora

abrange várias zonas de disponibilidade em uma região, fornecendo durabilidade

imediata e tolerância a falhas para seus dados em datacenters físicos. Uma zona

de disponibilidade é composta por um ou mais datacenters altamente disponíveis

operados pela Amazon. As zonas de disponibilidade são isoladas umas das outras

e conectadas por links de baixa latência. Cada segmento do volume do banco de

dados é replicado seis vezes nessas zonas de disponibilidade.

Os volumes dos clusters do Aurora aumentam automaticamente à medida que

a quantidade de dados no banco de dados aumenta, sem afetar o desempenho ou

a disponibilidade. Sendo assim, não é necessário fazer estimativas e provisionar

grandes quantidades de armazenamento de banco de dados com antecedência.

O volume de um cluster do Aurora pode ter, no máximo, 64 terabytes (TB). Você

é cobrado apenas pelo espaço que utiliza no volume de um cluster do Aurora.

O recurso de backup automático do Aurora oferece suporte para recuperação

point-in-time dos dados, permitindo que você restaure o banco de dados para

qualquer segundo durante o período de retenção, até os últimos cinco minutos.

Os backups automáticos são armazenados no Amazon Simple Storage Service

(Amazon S3), que foi desenvolvido para ter 99,999999999% de durabilidade.

Os backups do Amazon Aurora são automáticos, incrementais, contínuos e não

afetam o desempenho do banco de dados.

Para os aplicativos que precisam de réplicas somente leitura, é possível criar até

15 réplicas por banco de dados do Aurora com um atraso de réplica muito baixo.

Essas réplicas compartilham o mesmo armazenamento subjacente que

a instância de origem, diminuindo os custos e evitando a necessidade de realizar

gravações nos nós de réplica.


Página 6 de 46

O Amazon Aurora é extremamente seguro e permite criptografar bancos de dados

usando chaves que são criadas e controladas pelo AWS Key Management Service

(AWS KMS). Em uma instância de banco de dados em execução com criptografia

do Amazon Aurora, os dados armazenados em repouso no armazenamento

subjacente são criptografados, assim como os backups automáticos, os snapshots

e as réplicas no mesmo cluster. O Amazon Aurora usa SSL (AES-256) para

proteger dados em trânsito.

Para obter uma lista completa dos recursos do Aurora, consulte a página do

produto Amazon Aurora.1 Devido ao conjunto de recursos avançados e à relação

custo/benefício do Amazon Aurora, ele é cada vez mais escolhido como o banco

de dados para aplicativos de missão crítica.

Considerações sobre a migração de bancos

de dados Um banco de dados representa um componente crítico na arquitetura da maioria

dos aplicativos. A migração do banco de dados para uma nova plataforma é um

evento significativo no ciclo de vida de um aplicativo e pode afetar a

funcionalidade, o desempenho e a confiabilidade do aplicativo. Você deve fazer

algumas considerações importantes antes de embarcar no seu primeiro projeto

de migração para o Amazon Aurora.

Fases da migração Como as migrações de bancos de dados costumam ser complexas, recomendamos

adotar uma abordagem iterativa em fases.

Figura 1: Fases da migração

Considerações sobre aplicativos Avaliar os recursos do Aurora

Embora a maioria dos aplicativos possa ser arquitetada para funcionar com

muitos mecanismos de banco de dados relacional, você deve verificar se seu

aplicativo funciona com o Amazon Aurora. O Amazon Aurora foi desenvolvido

para ser compatível com o MySQL 5.6 por rede. Portanto, a maioria dos códigos,

aplicativos, drivers e ferramentas usados hoje em dia com bancos de dados

MySQL pode ser usada com o Aurora com pouca ou nenhuma alteração.

https://aws.amazon.com/rds/aurora/



Página 7 de 46

No entanto, alguns recursos do MySQL, como o mecanismo de armazenamento

MyISAM, não estão disponíveis para o Amazon Aurora. Além disso, devido

à natureza gerenciada do serviço do Aurora, o acesso SSH aos nós do banco de

dados é restrito, o que pode afetar a capacidade de instalar plug-ins ou

ferramentas de terceiros no host do banco de dados.

Considerações sobre desempenho

O desempenho do banco de dados é uma consideração importante a ser feita ao

migrar um banco de dados para uma nova plataforma. Portanto, muitos projetos

de migração de banco de dados bem-sucedidos começam com avaliações de

desempenho da nova plataforma do banco de dados. Embora a execução de

Sysbench e TPC-C de referência transmita uma boa ideia do desempenho geral do

banco de dados, essas referências não simulam os padrões de acesso aos dados

dos seus aplicativos. Para obter resultados mais úteis, teste o desempenho do

banco de dados para cargas de trabalho temporais executando suas consultas

(ou o subconjunto das consultas) diretamente na nova plataforma.

Considere estas estratégias:

Se seu banco de dados atual for MySQL, migre para o Amazon Aurora com

tempo de inatividade e desempenho, teste seu banco de dados com uma

versão de teste ou provisória do seu aplicativo ou reproduzindo a carga de

trabalho de produção.

Se você tiver um mecanismo que não é compatível com MySQL, copie de

modo seletivo as tabelas mais ocupadas para o Amazon Aurora e teste as

consultas para essas tabelas. Esse procedimento é um bom ponto de partida.

Obviamente, o teste depois da migração completa dos dados fornecerá um

quadro global do desempenho real do seu aplicativo na nova plataforma.

O Amazon Aurora apresenta um desempenho comparável ao dos mecanismos

comerciais e uma melhoria significativa em relação ao desempenho do MySQL.

Isso é possível graças à integração do mecanismo de banco de dados com uma

camada de armazenamento virtualizada com base em SSD desenvolvida para

cargas de trabalho de banco de dados. Isso reduz as gravações no sistema de

armazenamento, minimiza a contenção de bloqueios e elimina os atrasos criados

pelos threads de processo de banco de dados. Nossos testes com SysBench em

instâncias do r3.8xlarge mostram que o Amazon Aurora processa mais de 585 mil

leituras por segundo e 107 mil gravações por segundo, cinco vezes mais do que

o MySQL executando a mesma referência no mesmo hardware.

https://d0.awsstatic.com/product-marketing/Aurora/RDS_Aurora_Performance_Assessment_Benchmarking_v1-2.pdf

https://d0.awsstatic.com/product-marketing/Aurora/RDS_Aurora_Performance_Assessment_Benchmarking_v1-2.pdf


Página 8 de 46

O Amazon Aurora apresenta melhorias significativas em relação ao MySQL

tradicional em cargas de trabalho altamente simultâneas. Para maximizar

o resultado da carga de trabalho no Amazon Aurora, recomendamos arquitetar

os aplicativos com o objetivo de impulsionar um grande número de

consultas simultâneas.

Considerações sobre fragmentação e réplicas de

leitura Se seu banco de dados atual estiver fragmentado em vários nós, você tem

a oportunidade de combinar esses fragmentos em um único banco de dados

Aurora durante a migração. Uma única instância do Amazon Aurora pode ser

expandida para até 64 TB, oferece suporte para milhares de tabelas e um número

significativamente maior de leituras e gravações do que um banco de dados

MySQL padrão.

Se seu aplicativo processa muitas leituras/gravações, considere a possibilidade

de usar as réplicas de leitura do Aurora para descarregar a carga de trabalho

somente leitura do nó do banco de dados principal. Fazer isso pode melhorar

a simultaneidade do seu banco de dados primário para gravações, além de

melhorar o desempenho global de leitura e gravação. Usar réplicas de leitura

também pode diminuir os custos em uma configuração de várias zonas de

disponibilidade, pois é possível usar instâncias menores para a instância primária

e, ao mesmo tempo, adicionar recursos de failover ao cluster do banco de dados.

As réplicas de leitura do Aurora oferecem praticamente nenhum atraso de

replicação, e você pode criar até 15 réplicas de leitura.

Considerações sobre confiabilidade Uma consideração importante a ser feita em relação aos bancos de dados envolve

alta disponibilidade e recuperação de desastres. Determine os requisitos de RTO

(objetivo de tempo de recuperação) e RPO (objetivo de ponto de recuperação) do

seu aplicativo. Com o Amazon Aurora, você pode melhorar significativamente

esses dois fatores.

O Amazon aurora reduz os tempos de reinicialização de banco de dados para

menos de 60 segundos na maioria dos cenários de falha de banco de dados.

O Aurora também elimina o cache do buffer do processo do banco de dados

e o disponibiliza imediatamente no momento da reinicialização. Em cenários

raros de falhas de hardware e zona de disponibilidade, a recuperação

é manipulada automaticamente pela plataforma do banco de dados.


Página 9 de 46

O Aurora foi desenvolvido para fornecer recuperação de RPO zero em uma região

da AWS, o que é um grande aprimoramento em relação aos sistemas de banco de

dados no local. O Aurora mantém seis cópias dos dados em três zonas de

disponibilidade e tenta recuperar automaticamente seu banco de dados em uma

zona de disponibilidade íntegra sem perda de dados. Caso seus dados estejam

indisponíveis no armazenamento do Amazon Aurora, o que é improvável, você

pode restaurar de um snapshot do banco de dados ou realizar uma operação de

restauração point-in-time para uma nova instância.

Considerações sobre custo e licenciamento A propriedade e a execução de banco de dados têm custos associados. Antes de

planejar uma migração de banco de dados, é fundamental fazer uma análise do

custo total de propriedade (TCO) da nova plataforma de banco de dados. O ideal

é que a migração para uma nova plataforma de banco de dados diminua o custo

total de propriedade e, ao mesmo tempo, forneça recursos semelhantes ou

melhores para seus aplicativos. Se você estiver executando um mecanismo de

banco de dados de código aberto (MySQL, Postgres), seus custos estarão

associados principalmente a hardware, gerenciamento de servidor e atividades de

gerenciamento de banco de dados. No entanto, se você estiver executando um

mecanismo de banco de dados comercial (Oracle, SQL Server, DB2 etc.), uma

parcela significativa do custo estará relacionada ao licenciamento do banco

de dados.

Como o Aurora está disponível por um décimo do custo dos mecanismos

comerciais, muitos aplicativos que estão migrando para o Aurora podem reduzir

o TCO de maneira significativa. Mesmo se estiver executando um mecanismo de

código aberto como MySQL ou Postgres, com o alto desempenho e as réplicas de

leitura de finalidade dupla do Aurora, você poderá economizar muito com

a migração para o Amazon Aurora. Consulte a página de preços do Amazon RDS

for Aurora para obter mais informações.2

Outras considerações sobre migração Depois de considerar os fatores de adequação do aplicativo, desempenho,

TCO e confiabilidade, você deve pensar no que está envolvido na migração para

a nova plataforma.

http://aws.amazon.com/rds/aurora/pricing/



Página 10 de 46

Estimar alteração de código

É importante estimar a quantidade de alterações de código e esquema

necessárias durante a migração do banco de dados para o Amazon Aurora.

Ao migrar de bancos de dados compatíveis com MySQL, alterações de código

negligenciáveis são necessárias. No entanto, ao migrar de mecanismos não

MySQL, você talvez precise fazer alterações de esquema e código. A ferramenta

de conversão de esquema da AWS, descrita posteriormente neste documento,

pode ajudar a fazer essa estimativa.

Disponibilidade do aplicativo durante a migração

Você pode realizar a migração para o Amazon Aurora adotando uma abordagem

de tempo de inatividade previsível para seu aplicativo ou uma abordagem de

tempo de inatividade praticamente zero. A abordagem escolhida depende do

tamanho do banco de dados e dos requisitos de disponibilidade dos aplicativos.

De qualquer maneira, é recomendado considerar o impacto do processo de

migração no aplicativo e na sua empresa antes de iniciar qualquer migração de

banco de dados. As próximas seções explicam as duas abordagens em detalhes.

Planejamento do processo de migração do

banco de dados A seção anterior discutiu algumas considerações importantes a serem feitas ao

migrar bancos de dados para o Amazon Aurora. Depois de determinar que

o Aurora é a opção ideal para seu aplicativo, a próxima etapa é decidir qual

abordagem de migração preliminar usar e criar um plano de migração de banco

de dados.

Migração homogênea Se seu banco de dados de origem for compatível com MySQL 5.6 (MySQL,

MariaDB, Percona etc.), a migração para o Aurora será bem simples.

Migração homogênea com tempo de inatividade

Se seu aplicativo suporta uma duração previsível de tempo de inatividade fora do

horário de pico, a migração com tempo de inatividade é a opção mais simples,

além de ser uma abordagem muito recomendada. A maioria dos projetos de

migração de banco de dados se enquadra nessa categoria, pois a maioria dos

aplicativos já tem uma janela de manutenção bem definida. Você tem as

seguintes opções para migrar seu banco de dados com tempo de inatividade.


Página 11 de 46

Migração de snapshot do RDS. Se seu banco de dados de origem for

executado no Amazon RDS MySQL 5.6, você poderá simplesmente migrar

um snapshot desse banco de dados para o Amazon Aurora. Para migrações

com tempo de inatividade, você deve interromper seu aplicativo ou

interromper a gravação no banco de dados enquanto o snapshot

e a migração estiverem em andamento. O tempo de migração depende

principalmente do tamanho do banco de dados e pode ser determinado

antes da migração de produção com a execução de uma migração de teste.

A opção de migração de snapshot é explicada na seção Migração de

snapshot do RDS. Você também pode realizar uma migração com tempo de

inatividade praticamente zero usando a migração de snapshot

e a replicação de binlog, que são descritas na próxima seção.

Migração usando ferramentas MySQL nativas. É possível usar

ferramentas MySQL nativas para migrar dados e esquemas para o Aurora.

Essa opção é ideal quando precisa de mais controle sobre o processo de

migração de banco de dados, está mais familiarizado com o uso de

ferramentas MySQL nativas e outros métodos de migração não têm um

desempenho tão bom para seu caso de uso. Para consultar as práticas

recomendadas ao usar essa opção, baixe o whitepaper Amazon RDS for

Aurora Export/Import Performance Best Practices (Práticas recomendadas

de desempenho de exportação/importação do Amazon RDS for Aurora).3

Migração usando o Serviço de Migração de Banco de Dados da AWS

(AWS DMS). A migração única usando o AWS DMS é outra ferramenta

para mover seu banco de dados de origem para o Amazon Aurora. Antes de

usar o AWS DMS para mover os dados, você precisa copiar o esquema do

banco de dados da origem para o destino usando ferramentas MySQL

nativas. Para ver o processo passo a passo, consulte a seção Migração de

dados. O uso do AWS DMS é uma opção excelente quando você não tem

experiência com as ferramentas MySQL nativas.

Migração homogênea com tempo de inatividade praticamente zero

Em alguns cenários, convém migrar o banco de dados para o Aurora com tempo

de inatividade mínimo. Veja dois exemplos a seguir:

Quando seu banco de dados é relativamente grande e o tempo de migração

usando opções de tempo de inatividade é maior do que a janela de

manutenção do seu aplicativo

https://d0.awsstatic.com/product-marketing/Aurora/Aurora_Export_Import_Best_Practices_v1-3.pdf




Página 12 de 46

Quando você deseja executar os bancos de dados de origem e destino em

paralelo para fins de teste

Nesses casos, é possível replicar as alterações do banco de dados MySQL de

origem para o Aurora em tempo real usando a replicação. Você tem algumas

opções disponíveis:

Migração com tempo de inatividade praticamente zero usando a

replicação de binlog MySQL. O Amazon Aurora é compatível com a

tradicional replicação de binlog MySQL. Se você executa um banco de

dados MySQL, provavelmente já está familiarizado com a clássica

configuração de replicação de binlog. Nesse caso, e se você quiser ter mais

controle sobre o processo de migração, o carregamento único do banco de

dados usando ferramentas nativas associadas à replicação de binlog oferece

um caminho de migração familiar para o Aurora.

Migração com tempo de inatividade praticamente zero usando o

Serviço de Migração de Banco de Dados da AWS (AWS DMS). Além de

ser compatível com a migração única, o AWS DMS também é compatível

com a replicação de dados em tempo real usando a captura de dados de

alteração (CDC) da origem para o destino. O AWS DMS cuida das

complexidades relacionadas à cópia de dados inicial, configurando

instâncias de replicação e monitorando a replicação. Quando a migração

inicial do banco de dados é concluída, o banco de dados de destino

permanece sincronizado com a origem pelo tempo que você especificar.

Se você não estiver familiarizado com a replicação de binlog, o AWS DMS

é a segunda melhor opção para migrações homogêneas com tempo de

inatividade praticamente zero para o Amazon Aurora. Consulte a seção

Introdução e abordagem geral ao AWS DMS.

Migração com tempo de inatividade praticamente zero usando

a migração de snapshot do RDS e a replicação de binlog MySQL. Se

seu banco de dados de origem for executado no Amazon RDS MySQL 5.6,

você poderá migrar um snapshot desse banco de dados para o Amazon

Aurora e iniciar a replicação de binlog entre origem e destino depois da

migração de snapshot. Para obter detalhes sobre essa opção de migração,

consulte Replicação com Amazon Aurora no Guia do usuário do

Amazon RDS.4

http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Aurora.Replication.html#Aurora.Overview.Replication.MySQLReplication


Página 13 de 46

Migração heterogênea Se você estiver pretendendo migrar um banco de dados não compatível com

MySQL (Oracle, SQL Server, PostgresSQL etc.) para o Amazon Aurora, várias

opções podem ajudar a realizar essa migração com rapidez e facilidade.

Migração de esquema

A migração de esquema de um banco de dados não compatível com MySQL para

o Amazon Aurora pode ser realizada com a ferramenta de conversão de esquema

da AWS. Essa ferramenta é um aplicativo de área de trabalho que ajuda

a converter o esquema de um banco de dados Oracle, Microsoft SQL Server ou

PostgreSQL em uma instância de banco de dados MySQL do Amazon RDS ou um

cluster de banco de dados do Amazon Aurora. Quando não é possível converter

o esquema do banco de dados de origem de maneira automática e completa,

a ferramenta de conversão de esquema da AWS fornece orientação sobre como

criar o esquema equivalente no banco de dados do Amazon RDS de destino.

Para obter detalhes, consulte a seção Migração do esquema de banco de dados.

Migração de dados

Ao oferecer suporte para migrações homogêneas com tempo de inatividade

praticamente zero, o AWS Database Migration Service (AWS DMS) também

oferece suporte para a replicação contínua em bancos de dados heterogêneos,

além de ser a opção ideal para mover o banco de dados de origem para o banco de

dados de destino, tanto para migrações com tempo de inatividade quanto para

migrações com tempo de inatividade praticamente zero. Assim que a migração

é iniciada, o AWS DMS gerencia todas as complexidades do processo de

migração, como transformação de tipo de dados, compactação e transferência

paralela (para agilizar as transferências de dados), e, ao mesmo tempo, garante

que as alterações de dados no banco de dados de origem que ocorrem durante

o processo de migração sejam replicadas automaticamente para o destino.

Além de usar o AWS DMS, você pode usar várias ferramentas de terceiros como

Attunity Replicate, Tungsten Replicator, Oracle Golden Gate etc. para migrar os

dados para o Amazon Aurora. Independentemente da ferramenta escolhida, leve

o desempenho e os custos de licenciamento em consideração antes de decidir

qual conjunto de ferramentas usará para a migração.


Página 14 de 46

Migração de grandes bancos de dados para

o Amazon Aurora A migração de grandes conjuntos de dados cria desafios únicos em todos os

projetos de migração de bancos de dados. Muitos projetos bem-sucedidos de

migração de grandes bancos de dados usam uma combinação das seguintes

estratégias:

Migração com replicação contínua. Os bancos de dados grandes

normalmente têm requisitos de tempo de inatividade estendido durante

a migração de dados da origem para o destino. Para diminuir o tempo de

inatividade, você pode primeiro carregar os dados básicos da origem para

o destino e, depois, ativar a replicação (usando ferramentas MySQL

nativas, AWS DMS ou ferramentas de terceiros) para que as alterações

sejam aplicadas.

Copie as tabelas estáticas primeiro. Se seu banco de dados depende de

grandes tabelas estáticas com dados de referência, você pode migrar essas

grandes tabelas para o banco de dados de destino antes de migrar seu

conjunto de dados ativo. Você pode aproveitar o AWS DMS para copiar as

tabelas de modo seletivo ou exportar e importar essas tabelas

manualmente.

Migração em várias fases. A migração de um banco de dados grande com

milhares de tabelas pode ser dividida em várias fases. Por exemplo, você

pode mover um conjunto de tabelas sem consultas de referência cruzada

todos os finais de semana até que o banco de dados de origem seja

totalmente migrado para o banco de dados de destino. Para fazer isso,

é necessário fazer alterações no seu aplicativo para se conectar aos dois

bancos de dados simultaneamente enquanto o conjunto de dados está em

dois nós distintos. Embora não seja um padrão de migração comum,

é uma opção.

Limpeza do banco de dados. Muitos bancos de dados grandes contêm

dados e tabelas que não são usados. Em muitos casos, desenvolvedores

e administrados de bancos de dados mantêm cópias de backup das tabelas

no mesmo banco de dados ou simplesmente se esquecem de descartar as

tabelas não utilizadas. Independentemente do motivo, um projeto de

migração de banco de dados proporciona uma oportunidade para limpar

o banco de dados existente antes da migração. Se algumas tabelas não

estiverem sendo usadas, convém descartá-las ou arquivá-las em outro

banco de dados. Você também pode excluir dados antigos de tabelas

grandes ou arquivar esses dados em arquivos sem formatação.


Página 15 de 46

Consolidação de partições e fragmentos no Amazon

Aurora Se você estiver executando vários fragmentos ou partições funcionais do banco de

dados para atingir um alto desempenho, terá a oportunidade de consolidar essas

partições ou fragmentos em um único banco de dados do Aurora. Uma única

instância do Amazon Aurora pode ser expandida para até 64 TB, oferece suporte

para milhares de tabelas e um número significativamente maior de leituras

e gravações do que um banco de dados MySQL padrão. A consolidação dessas

partições em uma única instância do Aurora não só reduz o custo total de

propriedade e simplifica o gerenciamento do banco de dados, mas também

melhora significativamente o desempenho de consultas em partições diferentes.

Partições funcionais. Particionamento funcional significa dedicar nós

diferentes para tarefas diferentes. Por exemplo, em um aplicativo de

comércio eletrônico, você pode ter um nó do banco de dados veiculando

dados do catálogo de produtos e outro nó captando e processando pedidos.

Como resultado, essas partições costumam ter esquemas distintos que não

se sobrepõem.

Estratégia de consolidação. Migre cada partição funcional como um

esquema distinto para a instância de destino do Aurora. Se o banco de

dados de origem for compatível com MySQL, use ferramentas MySQL

nativas para migrar o esquema e, depois, use o AWS DMS para migrar os

dados, de uma só vez ou continuamente por meio da replicação. Se o banco

de dados de origem não for compatível com MySQL, use a ferramenta de

conversão de esquema da AWS para migrar os esquemas para o Aurora

e use o AWS DMS para carregamento único ou replicação contínua.

Fragmentos de dados. Se você tem o mesmo esquema com conjuntos de

dados diferentes em vários nós, está aproveitando a fragmentação do banco

de dados. Por exemplo, um serviço de blog com grande volume de tráfego

pode fragmentar a atividade e os dados do usuários em vários fragmentos

do banco de dados, mantendo o mesmo esquema de tabela.


Página 16 de 46

Estratégia de consolidação. Como todos os fragmentos compartilham

o mesmo esquema de banco de dados, você só precisa criar o esquema de

destino uma vez. Se seu banco de dados for compatível com MySQL, use

ferramentas nativas para migrar o esquema de banco de dados para

o Aurora. Se seu banco de dados não for MySQL, use a ferramenta de

conversão de esquema da AWS para migrar o esquema de banco de dados

para o Aurora. Depois que o esquema de banco de dados for migrado, é

melhor interromper as gravações nos fragmentos de banco de dados e usar

ferramentas nativas ou um carregamento único de dados do AWS DMS

para migrar um fragmento individual para o Aurora. Se não for possível

interromper as gravações no aplicativo por um período prolongado, você

ainda poderá usar o AWS DMS com replicação, mas somente depois de

fazer o planejamento e os testes apropriados.

Visão geral das opções de migração

Tipo de banco de

dados de origem

Migração com tempo de

inatividade

Migração com tempo de inatividade

praticamente zero

Amazon RDS MySQL Opção 1: migração de snapshot do

RDS

Opção 2: migração manual usando

ferramentas nativas*

Opção 3: migração de esquema

usando ferramentas nativas

e carregamento de dados usando

o AWS DMS

Opção 1: migração usando

ferramentas nativas + replicação de

binlog

Opção 2: migração de snapshot do

RDS + replicação de binlog


usando ferramentas nativas + AWS

DMS para movimentação de dados

MySQL Amazon EC2

ou no local


ferramentas nativas


com ferramentas nativas + AWS

DMS para carregamento de dados


ferramentas nativas + replicação de

binlog


usando ferramentas nativas + AWS

DMS para movimentação de dados

Oracle/SQL Server Opção 1: ferramenta de conversão

de esquema da AWS + AWS DMS

(recomendado)

Opção 2: ferramenta manual ou de

terceiros para conversão de

esquema + carregamento de dados

manual ou de terceiros no destino

Opção 1: ferramenta de conversão de

esquema da AWS + AWS DMS

(recomendado)

Opção 2: ferramenta manual ou de

terceiros para conversão de esquema

+ carregamento de dados manual ou

de terceiros no destino + ferramenta

de terceiros para replicação


Página 17 de 46

Tipo de banco de

dados de origem

Migração com tempo de

inatividade

Migração com tempo de inatividade

praticamente zero

Outros bancos de

dados não MySQL

Opção: ferramenta manual ou de

terceiros para conversão de

esquema + carregamento de dados

manual ou de terceiros no destino

Opção: ferramenta manual ou de

terceiros para conversão de esquema

+ carregamento de dados manual ou

de terceiros no destino + ferramenta

de terceiros para replicação

(GoldenGate etc.)

*Ferramentas Mysql nativas: mysqldump, SELECT INTO OUTFILE, ferramentas de terceiros, como

mydumper/myloader

Migração de snapshot do RDS Para usar a migração de snapshot do RDS para a migração de dados para

o Aurora, seu banco de dados MySQL deve ser executado no Amazon RDS

MySQL 5.6, e você deve fazer um snapshot do RDS do banco de dados. Esse método

de migração não funciona com bancos de dados locais ou bancos de dados em

execução no Amazon Elastic Compute Cloud (Amazon EC2). Além disso, se estiver

executando o banco de dados Amazon RDS MySQL em uma versão anterior à 5.6,

você precisará atualizá-lo para a versão 5.6 como pré-requisito.

A maior vantagem desse método de migração é o fato de ser a opção mais simples

e ter o menor número de etapas. Especificamente, ele migra todos os objetos de

esquema, índices secundários e procedimentos armazenados com todos os dados

do banco de dados.

Durante a migração de snapshot sem replicação de binlog, o banco de dados de

origem deve ficar off-line ou em um modo somente leitura (para que nenhuma

alteração seja feita no banco de dados de origem durante a migração). Para

estimar o tempo de inatividade, você pode simplesmente usar o snapshot

existente do seu banco de dados para fazer uma migração de teste. Se o tempo de

migração estiver dentro dos seus requisitos de tempo de inatividade, esse talvez

seja o melhor método para você. Em alguns casos, a migração com AWS DMS ou

ferramentas de migração nativas pode ser mais rápida do que a migração de snapshot.

Se não for possível prolongar o tempo de inatividade, você ainda poderá realizar

a migração com tempo de inatividade praticamente zero. Para isso, primeiro migre

um snapshot do banco de dados do RDS para o Amazon Aurora, permitindo que

o banco de dados de origem continue sendo atualizado. Depois, você pode

atualizá-lo usando a replicação de binlog MySQL de MySQL para o Aurora.


Página 18 de 46

É possível migrar um snapshot de banco de dados manual ou automático.

As etapas gerais são as seguintes:

1. Determine a quantidade de espaço necessária para migrar a instância do

Amazon RDS MySQL 5.6 para um cluster de banco de dados do Aurora.

Para obter mais informações, consulte a próxima seção.

2. Use o console do Amazon RDS para criar o snapshot na região em que se

encontra a instância do Amazon RDS MySQL 5.6.

3. Use o recurso Migrate Database (Migrar banco de dados) no console

para criar um cluster de banco de dados do Amazon Aurora que será

preenchido com o snapshot da instância de banco de dados original do

MySQL 5.6.

Observação: algumas tabelas MyISAM talvez não sejam convertidas sem erros

e podem exigir alterações manuais. Por exemplo, o mecanismo InnoDB não

permite que um campo de incremento automático faça parte de uma chave

composta. Além disso, índices espaciais não são permitidos no momento.

Estimativa de requisitos de espaço para a migração de snapshot

Quando você migra um snapshot de uma instância de banco de dados MySQL

para um cluster de banco de dados do Aurora, o Aurora usa um volume do

Amazon Elastic Block Store (Amazon EBS) para formatar os dados no snapshot

antes de migrá-lo. Em alguns casos, um espaço adicional é necessário para

formatar os dados para migração. Os dois recursos que podem causar problemas

de espaço durante a migração são as tabelas MyISAM e o uso da opção

ROW_FORMAT=COMPRESSED. Se você não estiver usando nenhum desses recursos no

banco de dados de origem, pule esta seção porque não deverão ocorrer problemas

de espaço. Durante a migração, as tabelas MyISAM são convertidas em InnoDB

e as tabelas compactadas são descompactadas. Consequentemente, deve haver

espaço adequado para as cópias adicionais dessas tabelas.


Página 19 de 46

O tamanho do volume de migração se baseia no tamanho alocado do banco de

dados MySQL de origem do qual o snapshot foi feito. Portanto, se você tiver

tabelas MyISAM ou compactadas que formam uma pequena porcentagem do

tamanho global do banco de dados e se houver espaço disponível no banco de

dados original, a migração deverá ser bem-sucedida sem encontrar problemas de

espaço. No entanto, se o banco de dados original não tiver espaço suficiente para

armazenar uma cópia das tabelas MyISAM convertidas e outra cópias (não

compactada) das tabelas compactadas, o volume de migração não será grande

o suficiente. Nessa situação, você precisa modificar o banco de dados Amazon

RDS MySQL de origem para aumentar a alocação de tamanho do banco de dados

e deixar espaço para as cópias adicionais dessas tabelas, criar um novo snapshot

do banco de dados e migrar o novo snapshot.

Ao migrar os dados do cluster de banco de dados, observe as seguintes diretrizes

e limitações:

Embora o Amazon Aurora suporte até 64 TB de armazenamento,

o processo de migração de um snapshot para um cluster de banco de dados

do Aurora é limitado pelo tamanho do volume do snapshot do Amazon EBS

e, portanto, está limitado a um tamanho máximo de 6 TB.

As tabelas não MyISAM no banco de dados de origem podem ter até 6 TB.

No entanto, devido a outros requisito de espaço durante a conversão,

garanta que nenhuma tabela MyISAM e compactada migrada da instância

de banco de dados MySQL tenha mais de 3 TB.

Convém modificar o esquema de banco de dados (converter as tabelas MyISAM

em InnoDB e remover ROW_FORMAT=COMPRESSED) antes de migrá-lo para o Amazon

Aurora. Isso pode ser útil nos seguintes casos:

Você deseja agilizar o processo de migração.

Você não sabe quanto espaço deve ser provisionado.

Você tentou migrar os dados e a migração falhou devido à falta de espaço

provisionado.

Verifique se você não está fazendo essas alterações no banco de dados Amazon

RDS MySQL de produção, mas sim em uma instância do banco de dados que foi

restaurada do snapshot de produção. Para obter mais detalhes sobre como fazer

isso, consulte Redução do espaço necessário para migrar dados para o Amazon

Aurora no Guia do usuário do Amazon RDS.5

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Migrate.html#USER_ImportAurora.PreImport

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Migrate.html#USER_ImportAurora.PreImport


Página 20 de 46

Migração de um snapshot de banco de dados usando o console

Você pode migrar um snapshot de banco de dados de uma instância do Amazon

RDS MySQL para criar um cluster de banco de dados do Aurora. O novo cluster

de banco de dados é preenchido com os dados da instância de banco de dados

Amazon RDS MySQL original. O snapshot de banco de dados deve ter sido feito

de uma instância de banco de dados do RDS que executa MySQL 5.6 e não deve

ser criptografado. Para obter informações sobre como criar um snapshot de

banco de dados, consulte Criação de um snapshot de banco de dados no Guia do

usuário do Amazon RDS.6

Se o snapshot de banco de dados não estiver na região em que você deseja colocar

o cluster de banco de dados do Aurora, use o console do Amazon RDS para copiar

o snapshot de banco de dados para essa região. Para obter informações sobre

como copiar um snapshot de banco de dados, consulte Cópia de um snapshot de

banco de dados no Guia do usuário do Amazon RDS.7

Para migrar um snapshot de banco de dados MySQL 5.6 usando o console, faça

o seguinte:

1. Faça login no AWS Management Console e abra o console do Amazon RDS

em https://console.aws.amazon.com/rds/.

2. Escolha Snapshots.

3. Na página Snapshots, escolha o snapshot do Amazon RDS MySQL 5.6

que você deseja migrar para o cluster de banco de dados do Aurora.

4. Escolha Migrate Database (Migrar banco de dados).

5. Na página Migrate Database (Migrar banco de dados), especifique os

valores que correspondem ao seu ambiente e aos seus requisitos de

processamento conforme mostrado na próxima ilustração. Para ver

a descrição dessas opções, consulte Migração de um snapshot de banco de

dados usando o console no Guia do usuário do Amazon RDS.8

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html


https://console.aws.amazon.com/rds/

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Migrate.html#USER_ImportAuroraCluster.Console

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Migrate.html#USER_ImportAuroraCluster.Console


Página 21 de 46

Figura 2: Migração de snapshot

6. Clique em Migrate (Migrar) para migrar o snapshot de banco de dados.

Na lista de instâncias, clique no ícone de seta apropriado para mostrar os detalhes do cluster de banco de dados e monitorar o andamento da migração. Esse painel de detalhes exibe o endpoint do cluster usado para conectar-se à instância primária do cluster de banco de dados. Para obter mais informações sobre como conectar-se a um cluster de banco de dados do Amazon Aurora, consulte Conexão a um cluster de banco de dados do Amazon Aurora no Guia do usuário do Amazon RDS.9

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Connect.html


Página 22 de 46

Migração do esquema de banco de dados A migração de snapshot de banco de dados do RDS migra o esquema completo

e os dados para a nova instância do Aurora. No entanto, se os requisitos de tempo

de atividade do aplicativo e local do banco de dados de origem não permitirem

o uso da migração de snapshot do RDS, primeiro migre o esquema do banco de

dados de origem para o banco de dados de destino antes de mover os dados reais.

Um esquema de banco de dados é uma estrutura básica que representa

a visualização lógica do banco de dados inteiro e normalmente inclui o seguinte:

Objetos de armazenamento do banco de dados: tabelas, colunas, restrições,

índices, sequências, tipos definidos pelo usuário e tipos de dados

Objetos de código do banco de dados: funções, procedimentos, pacotes,

acionadores, visualizações, visualizações materializadas, eventos, funções

SQL escalares, funções SQL em linha, funções SQL de tabela, atributos,

variáveis, constantes, tipos de tabela, tipos públicos, tipos privados,

cursores, exceções, parâmetros e outros objetos

Na maioria das situações, o esquema de banco de dados continua relativamente

estático e, portanto, você não precisa de tempo de inatividade durante a etapa de

migração de esquema de banco de dados. O esquema do banco de dados de

origem pode ser extraído enquanto esse banco de dados está em execução sem

afetar o desempenho. Se seu aplicativo ou os desenvolvedores fizerem alterações

frequentes no esquema de banco de dados, verifique se essas alterações são

pausadas enquanto a migração está em andamento ou se são consideradas

durante o processo de migração de esquema.

Dependendo do tipo de banco de dados de origem, você pode usar as técnicas

discutidas nas próximas seções para migrar o esquema do banco de dados.

Como pré-requisito da migração de esquema, você deve ter um banco de dados

do Aurora de destino criado e disponível.

Migração de esquema homogênea Se o banco de dados de origem for compatível com MySQL 5.6 e estiver em

execução no Amazon RDS, Amazon EC2 ou fora da AWS, você poderá usar

ferramentas MySQL para exportar e importar o esquema.


Página 23 de 46

Exportação do esquema de banco de dados. Você pode usar o utilitário

cliente mysqldump para exportar o esquema de banco de dados. Para

executar esse utilitário, você precisa se conectar ao banco de dados de

origem e redirecionar a saída do comando mysqldump para um arquivo sem

formatação. A opção –no-data garante que somente o esquema de banco de

dados seja exportado sem nenhum dado de tabela real. Para obter

a referência completa do comando mysqldump, consulte mysqldumpUm

programa de backup de banco de dados.10

mysqldump –u source_db_username –p --no-data --routines --

triggers –databases source_db_name > DBSchema.sql

Importação do esquema de banco de dados para o Aurora. Para

importar o esquema para a instância do Aurora, conecte-se ao banco de

dados Aurora de um cliente de linha de comando MySQL (ou um cliente

Windows correspondente) e direcione o conteúdo do arquivo de exportação

para o MySQL.

mysql –h aurora-cluster-endpoint -u username -p <

DBSchema.sql

Observe o seguinte:

Se o banco de dados de origem contiver procedimentos armazenados,

acionadores e visualizações, você precisará remover a sintaxe DEFINER do

arquivo de despejo. Um simples comando Perl para fazer isso é mostrado

abaixo. Fazer isso cria todos os acionadores, visualizações e procedimentos

armazenados com o usuário conectado atual como DEFINER. Não se esqueça

de avaliar as possíveis implicações de segurança.

$perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < DBSchema.sql >

DBSchemaWithoutDEFINER.sql

https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html




Página 24 de 46

O Amazon Aurora oferece suporte somente para tabelas InnoDB. Se houver

tabelas MyISAM no banco de dados de origem, o Aurora mudará

o mecanismo automaticamente para InnoDB quando o comando CREATE

TABLE for executado.

O Amazon Aurora não é compatível com tabelas compactadas (isto é,

tabelas criadas com ROW_FORMAT=COMPRESSED). Se houver tabelas

compactadas no banco de dados de origem, o Aurora mudará

automaticamente ROW_FORMAT para COMPACT quando o comando CREATE

TABLE for executado.

Depois de importar o esquema de um banco de dados de origem compatível com

MySQL 5.6 para o Amazon Aurora, a próxima etapa é copiar os dados reais da

origem para o destino. Para obter mais informações, consulte a seção Introdução

e abordagem geral ao AWS DMS posteriormente neste documento.

Migração de esquema heterogênea Se o banco de dados de origem não for compatível com MySQL, você deverá

converter seu esquema em um formato compatível com o Amazon Aurora.

A conversão de esquema de um mecanismo de banco de dados em outro não

é uma tarefa trivial e pode envolver a regravação de algumas partes do código do

aplicativo e do banco de dados. Você tem duas opções principais para converter

e migrar seu esquema para o Amazon Aurora:

Ferramenta de conversão de esquema da AWS. A Ferramenta de

conversão de esquema da AWS facilita as migrações heterogêneas de banco

de dados convertendo automaticamente o esquema do banco de dados de

origem e a maioria do código personalizado, incluindo visualizações,

procedimentos armazenados e funções, em um formato compatível com

o banco de dados de destino.11 Qualquer código que não possa ser

convertido automaticamente é marcado com clareza para que possa ser

convertido manualmente. Você pode usar essa ferramenta para converter

bancos de dados de origem em execução em Oracle ou Microsoft SQL

Server em um banco de dados de destino Amazon Aurora, MySQL ou

PostgreSQL no Amazon RDS ou Amazon EC2. Usar a ferramenta de

conversão de esquema da AWS para converter esquemas Oracle, SQL

Server ou PostgreSQL em um formato compatível com o Aurora é o método

preferencial.

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/Welcome.html



Página 25 de 46

Migração manual de esquema e ferramentas de terceiros. Se o banco

de dados de origem não for Oracle, SQL Server ou PostgreSQL, você poderá

migrar manualmente o esquema do banco de dados de origem para

o Aurora ou usar ferramentas de terceiros para migrar o esquema para um

formato que seja compatível com MySQL 5.6. A migração manual de

esquema pode ser um processo justamente envolvido dependendo do

tamanho e da complexidade do esquema de origem. No entanto, na maioria

dos casos, a conversão manual do esquema é válida devido à economia de

custo, aos benefícios de desempenho e a outras melhorias associadas ao

Amazon Aurora.

Migração de esquema usando a ferramenta de

conversão de esquema da AWS A ferramenta de conversão de esquema da AWS tem uma interface de usuário

com base no projeto que permite converter automaticamente o esquema do

banco de dados de origem em um formato que seja compatível com o Amazon

Aurora. É altamente recomendado que você use a ferramenta de conversão de

esquema da AWS para avaliar o projeto de migração de banco de dados e para

fazer uma migração piloto antes da migração de produção real.

A descrição a seguir orienta você pelas etapas passo a passo do uso da ferramenta

de conversão de esquema da AWS. Para obter instruções detalhadas, consulte

a seção Conceitos básicos do Guia do usuário da ferramenta de conversão de

esquema da AWS.12

1. Primeiro, instale a ferramenta. A ferramenta de conversão de esquema da

AWS está disponível para Microsoft Windows, Mac OS X, Ubuntu Linux

e Fedora Linux.

Instruções detalhadas de download e instalação podem ser encontradas na

seção de instalação e atualização do guia do usuário.13 O local de instalação

da ferramenta de conversão de esquema da AWS é importante.

A ferramenta precisa ser conectada diretamente aos bancos de dados de

origem e destino para converter e aplicar o esquema. Verifique se

o computador em que você instalará a ferramenta de conversão de

esquema da AWS tem conectividade de rede com os bancos de dados de

origem e destino.

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.GettingStarted.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.Installing.html


Página 26 de 46

2. Instale os drivers JDBC. A ferramenta de conversão de esquema da AWS

usa drivers JDBC para se conectar aos bancos de dados de origem

e destino. Para usar essa ferramenta, você precisa baixar esses drivers

JDBC no computador local. As instruções para download do driver estão

disponíveis em Drivers de banco de dados obrigatórios no Guia do usuário

da ferramenta de conversão de esquema da AWS.14 Além disso, confira

o fórum da ferramenta de conversão de esquema da AWS para obter

instruções sobre como configurar drivers JDBC para diferentes

mecanismos de banco de dados.15

3. Crie um banco de dados de destino. Crie um banco de dados de destino do

Amazon Aurora. Para obter instruções sobre como criar um banco de dados

do Amazon Aurora, consulte Criação de um cluster de banco de dados do

Amazon Aurora no Guia do usuário do Amazon RDS.16

4. Abra a ferramenta de conversão de esquema da AWS e inicie o New

Project Wizard (Assistente de novo projeto).

Figura 3: Criar um novo projeto da ferramenta de conversão de esquema da AWS

5. Configure o banco de dados de origem e teste a conectividade entre

a ferramenta de conversão de esquema da AWS e o banco de dados de

origem. Para esse procedimento, o banco de dados de origem deve ser

acessado pelo computador. Portanto, verifique se as configurações

apropriadas de rede e firewall estão ativadas.

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.Installing.html#CHAP_SchemaConversionTool.Installing.JDBCDrivers

https://forums.aws.amazon.com/forum.jspa?forumID=208

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateInstance.html



Página 27 de 46

Figura 4: Assistente de criação de novo projeto de migração de banco de dados

6. Na próxima tela, selecione o esquema do banco de dados de origem que

você deseja converter no Amazon Aurora.

Figura 5: Etapa de seleção de esquema do assistente de migração


Página 28 de 46

7. Gere o relatório de avaliação de migração do banco de dados. Esse relatório

fornece informações importantes sobre a conversão do esquema do banco

de dados de origem na instância de destino do Amazon Aurora. Ele resume

todas as tarefas de conversão de esquema e detalha os itens de ação de

partes do esquema que não podem ser convertidas automaticamente no

Aurora. O relatório também inclui estimativas do trabalho necessário para

gravar o código equivalente no banco de dados de destino que não pode ser

convertido automaticamente.

Clique em Next (Avançar) para configurar o banco de dados de destino.

Você pode visualizar esse relatório de migração novamente mais tarde.

Figura 6: Relatório de migração

8. Configure o banco de dados de destino do Amazon Aurora e teste

a conectividade entre a ferramenta de conversão de esquema da AWS

e o banco de dados de origem. Para esse procedimento, o banco de dados

de destino deve ser acessado pelo computador. Portanto, verifique se as

configurações apropriadas de rede e firewall estão ativadas. Clique em

Finish (Encerrar) para acessar a janela do projeto.

9. Quando estiver na janela do projeto, você já terá estabelecido uma conexão

com os bancos de dados de origem e destino e estará pronto para analisar

o relatório de avaliação detalhado e migrar o esquema.


Página 29 de 46

10. No painel esquerdo que exibe o esquema do banco de dados de origem,

escolha um objeto de esquema para o qual criar um relatório de avaliação.

Clique com o botão direito no objeto e escolha Create Report (Criar

relatório).

Figura 7: Criar relatório de migração

A guia Summary (Resumo) exibe as informações de resumo do relatório

de avaliação de migração do banco de dados. Ela mostra os itens que foram

convertidos automaticamente e os itens que não puderam ser convertidos

automaticamente.

Para os itens de esquema que não puderam ser convertidos

automaticamente no mecanismo de banco de dados de destino, o resumo

inclui uma estimativa do trabalho necessário para criar um esquema que

seja equivalente ao banco de dados de origem na instância de banco de

dados de destino. O relatório classifica o tempo estimado de conversão

desses itens de esquema da seguinte maneira:

Simple (Simples) – Ações que podem ser concluídas em menos de

uma hora.

Medium (Média) – Ações mais complexas que podem ser

concluídas em uma a quatro horas.

Significant (Significativo) – Ações que são muito complexas

e levarão mais de quatro horas para serem concluídas.


Página 30 de 46

Figura 8: Relatório de migração

Importante: se você estiver avaliando o trabalho necessário para o projeto

de migração de banco de dados, esse relatório de avaliação é um recurso

importante a ser considerado. Estude o relatório de avaliação em detalhes

para determinar quais alterações de código são necessárias no esquema de

banco de dados e qual impacto as alterações podem ter na funcionalidade

e no design do seu aplicativo.

11. A próxima etapa é converter o esquema. O esquema convertido não

é aplicado imediatamente ao banco de dados de destino. Em vez disso,

ele é armazenado localmente até você aplicar explicitamente o esquema

convertido ao banco de dados de destino. Para converter o esquema do

banco de dados de origem, escolha um objeto de esquema a ser convertido

no painel esquerdo do projeto. Clique com o botão direito no objeto

e escolha Convert schema (Converter esquema), como mostrado na

ilustração a seguir.


Página 31 de 46

Figura 9: Converter esquema

Essa ação adiciona o esquema convertido ao painel direito da janela do

projeto e mostra os objetos que foram convertidos automaticamente pela

ferramenta de conversão de esquema da AWS.

12. Você pode responder aos itens de ação do relatório de avaliação de

maneiras diferentes:

Adicione o esquema equivalente manualmente. Você pode gravar a parte

do esquema que pode ser convertida automaticamente na instância de

banco de dados de destino escolhendo Apply to database (Aplicar ao

banco de dados) no painel direito do projeto. O esquema que é gravado na

instância de banco de dados de destino não terá os itens que não puderam

ser convertidos automaticamente. Esses itens são listados no relatório de

avaliação de migração do banco de dados.

Depois de aplicar o esquema à instância de banco de dados de destino, você

pode criar manualmente o esquema na instância de banco de dados de

destino para os itens que não puderam ser convertidos automaticamente.

Em alguns casos, talvez não seja possível criar um esquema equivalente na

instância de banco de dados de destino. Convém reprojetar uma parte do

aplicativo e do banco de dados para usar a funcionalidade que está

disponível no mecanismo de banco de dados para a instância de banco de

dados de destino. Em outros casos, você pode simplesmente ignorar

o esquema que não pode ser convertido automaticamente.


Página 32 de 46

Cuidado: se você criar manualmente o esquema na instância de banco de

dados de destino, não escolha Apply to database (Aplicar ao banco de

dados) enquanto não salvar uma cópia das tarefas manuais realizadas.

A aplicação do esquema do projeto à instância de banco de dados de destino

substitui o esquema com o mesmo nome na instância de banco de dados de

destino, e você perde as atualizações que foram adicionadas manualmente.

Modifique o esquema do banco de dados de origem e atualize o esquema no

projeto. Para alguns itens, é melhor modificar o esquema do banco de

dados de origem para um esquema que seja compatível com a arquitetura

do seu aplicativo e que também possa ser convertido automaticamente no

mecanismo da instância de banco de dados de destino. Depois de atualizar

o esquema do banco de dados de origem e verificar se as atualizações são

compatíveis com seu aplicativo, escolha Refresh from Database

(Atualizar do banco de dados) no painel esquerdo do projeto para atualizar

o esquema do banco de dados de origem. É possível converter o esquema

atualizado e gerar o relatório de avaliação de migração de banco de dados

novamente. O item de ação para o esquema atualizado não aparece mais.

13. Quando você estiver pronto para aplicar o esquema convertido à instância

de destino do Aurora, escolha o elemento de esquema no painel direito do

projeto. Clique com o botão direito no elemento de esquema e escolha

Apply to database (Aplicar ao banco de dados), como mostrado na figura

a seguir.

Figura 10: Aplicar esquema ao banco de dados


Página 33 de 46

Observação: na primeira vez em que você aplica o esquema convertido

à instância de banco de dados de destino, a ferramenta de conversão de

esquema da AWS adiciona outro esquema (AWS_ORACLE_EXT ou

AWS_SQLSERVER_EXT) à instância de banco de dados de destino. Esse

esquema implementa as funções de sistema do banco de dados de origem

que são necessárias ao gravar o esquema convertido à instância de banco

de dados de destino. Não modifique esse esquema, ou você poderá obter

resultados inesperados no esquema convertido que é gravado na instância

de banco de dados de destino. Quando o esquema é totalmente migrado

para a instância de banco de dados de destino e você não precisa mais da

ferramenta de conversão de esquema da AWS, é possível excluir

o esquema AWS_ORACLE_EXT ou AWS_SQLSERVER_EXT.

A ferramenta de conversão de esquema da AWS é um complemento fácil de usar

do kit de ferramentas de migração. Para obter práticas recomendadas adicionais

relacionadas à ferramenta de conversão de esquema da AWS, consulte o tópico

Práticas recomendadas no Guia do usuário da ferramenta de conversão de

esquema da AWS.17

Migração de dados Depois que o esquema do banco de dados é copiado do banco de dados de origem

para o banco de dados de destino do Aurora, a próxima etapa é migrar os dados

reais da origem para o destino. Embora a migração de dados possa ser realizada

com ferramentas diferentes, recomendamos migrar os dados usando o AWS

Database Migration Service (AWS DMS), pois ele fornece a simplicidade e os

recursos necessários para a tarefa em questão.

Introdução e abordagem geral ao AWS DMS O AWS Database Migration Service (AWS DMS) facilita o trabalho dos clientes

para migrar bancos de dados de produção para a AWS com tempo de inatividade

mínimo. Você pode manter seus aplicativos em execução durante a migração do

banco de dados. Além disso, o AWS Database Migration Service garante que as

alterações no banco de dados de origem que ocorrem durante e depois da

migração sejam continuamente replicadas no destino. As tarefas de migração

podem ser configuradas em minutos no Console de Gerenciamento da AWS.

O AWS Database Migration Service pode migrar seus dados para e de

plataformas de banco de dados muito usadas, como Oracle, SQL Server, MySQL,

PostgreSQL, Amazon Aurora, MariaDB e Amazon Redshift.

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.BestPractices.html


Página 34 de 46

O serviço é compatível com migrações homogêneas como Oracle para Oracle,

bem como com migrações heterogêneas entre plataformas de banco de dados

diferentes, como Oracle para Amazon Aurora ou SQL Server para MySQL. Você

pode realizar migrações únicas ou pode manter a replicação contínua entre os

bancos de dados sem que o cliente precise instalar ou configurar algum software

complexo.

O AWS DMS funciona com bancos de dados que estão no local ou em execução

no Amazon EC2 ou Amazon RDS. No entanto, o AWS DMS não funciona quando

os bancos de dados de origem e destino estão no local; um endpoint deve estar

na AWS.

O AWS DMS é compatível com versões específicas de Oracle, SQL Server,

Amazon Aurora, MySQL e PostgreSQL. Para verificar as versões atualmente

compatíveis, consulte o Guia do usuário do AWS Database Migration Service.18

No entanto, este whitepaper aborda somente o Amazon Aurora como destino

de migração.

Métodos de migração O AWS DMS fornece três métodos para migrar dados:

Migração dos dados existentes. Esse método cria as tabelas no banco de dados

de destino, define automaticamente os metadados que são necessários no destino

e preenche as tabelas com dados do banco de dados de origem (o que também

é chamado de "carregamento completo"). Os dados das tabelas são carregados em

paralelo para melhorar a eficiência. As tabelas são criadas somente nas migrações

homogêneas, e os índices secundários não são criados automaticamente pelo

AWS DMS. Leia estas informações para maiores detalhes.

Migração dos dados existentes e replicação de alterações contínuas. Esse

método faz um carregamento completo, conforme descrito acima, e também

capta as alterações contínuas que são feitas no banco de dados de origem durante

o carregamento completo e as armazena na instância de replicação. Assim que

o carregamento completo é concluído, as alterações armazenadas são aplicadas

ao banco de dados de destino até que ele fique atualizado. Além disso, as

alterações contínuas feitas no banco de dados de origem continuam sendo

replicadas para o banco de dados de destino para mantê-los sincronizados. Esse

método de migração é muito útil quando você deseja realizar uma migração de

banco de dados com pouco tempo de inatividade.

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.html


Página 35 de 46

Replicação somente de alterações de dados. Esse método simplesmente lê as

alterações no arquivo de registro de recuperação do banco de dados de origem

e aplica essas alterações ao banco de dados de destino regularmente. Se o banco

de dados de destino estiver indisponível, essas alterações serão armazenadas em

buffer na instância de replicação até o destino ficar disponível.

Quando o AWS DMS está realizando uma migração de carregamento completo,

o processamento coloca um carregamento nas tabelas do banco de dados de

origem, o que pode afetar o desempenho dos aplicativos que estão acessando esse

banco de dados ao mesmo tempo. Se isso for um problema e você não conseguir

encerrar os aplicativos durante a migração, considere as seguintes abordagens:

Execução da migração no momento em que o carregamento do aplicativo

no banco de dados está no ponto mais baixo.

Criação de uma réplica de leitura do banco de dados de origem e realização

da migração do AWS DMS na réplica de leitura.

Procedimento de migração O esquema geral para usar o AWS DMS é o seguinte:

1. Crie um banco de dados de destino.

2. Copie o esquema.

3. Crie uma instância de replicação do AWS DMS.

4. Defina os endpoints de origem e destino do banco de dados.

5. Crie e execute uma tarefa de migração.

Criar um banco de dados de destino

Crie seu cluster de banco de dados de destino do Amazon Aurora usando

o procedimento descrito em Criação de um cluster de banco de dados do Amazon

Aurora no Guia do usuário do Amazon RDS.19 Você deve criar o banco de dados de

destino na região e com um tipo de instância que satisfaça seus requisitos de

negócios. Além disso, para melhorar o desempenho da migração, verifique se

o banco de dados de destino não tem a implantação de várias zonas de

disponibilidade ativada. É possível ativar esse recurso assim que o carregamento

acabar.




Página 36 de 46

Copiar esquema

Além disso, você deve criar o esquema nesse banco de dados de destino.

O AWS DMS oferece suporte para migração básica de esquema, incluindo

a criação de tabelas e chaves primárias. No entanto, o AWS DMS não cria

automaticamente índices secundários, chaves externas, procedimentos

armazenados e contas de usuário, entre outras coisas, no banco de dados de

destino. Para obter todos os detalhes da migração de esquema, consulte a seção

Migração do esquema do banco de dados.

Criar uma instância de replicação do AWS DMS

Para usar o serviço AWS DMS, você deve criar uma instância de replicação do

AWS DMS, que é executada no VPC. Essa instância lê os dados do banco de

dados de origem, realiza os mapeamentos de tabela especificados e grava os

dados no banco de dados de destino. Em geral, o uso de uma instância de

replicação maior agiliza a migração do banco de dados (embora a migração

também possa ser afetada por outros fatores como capacidade dos bancos de

dados de origem e destino, latência da conexão etc.). Além disso, a instância de

replicação pode ser interrompida assim que a migração do banco de dados

é concluída.

Figura 11: Serviço de Migração de Banco de Dados da AWS

Atualmente, o AWS DMS é compatível com as classes de instância T2 e C4 para

instâncias de replicação. As classes T2 são instâncias padrão de baixo custo

desenvolvidas para fornecer um nível básico de desempenho da CPU com

a possibilidade de aumentá-lo além da linha basal. Elas são adequadas para

desenvolver, configurar e testar o processo de migração de banco de dados, bem

como para tarefas periódicas de migração de dados que podem se beneficiar com

a capacidade de aumento de desempenho da CPU. As classes de instância C4

foram desenvolvidas para fornecer o mais alto nível de desempenho do

processador e atingir um desempenho de pacote por segundo (PPS)

significativamente maior, menos tremulação de rede e menor latência de rede.

Use as classes de instância C4 se você estiver migrando grandes bancos de dados

e quiser minimizar o tempo de migração.


Página 37 de 46

Normalmente, o carregamento completo não requer uma quantidade significativa

de armazenamento de instância na instância de replicação do AWS DMS.

No entanto, se você estiver fazendo replicação com carregamento completo,

as alterações do banco de dados de origem serão armazenadas na instância de

replicação do AWS DMS enquanto o carregamento completo estiver em

andamento. Assim, se você estiver migrando um banco de dados de origem muito

grande que também está recebendo muitas atualizações durante a migração, uma

quantidade significativa de armazenamento de instância poderá ser consumido.

A família de instâncias C4 vem com 100 GB de armazenamento de instância

e a família de instâncias T2 vem com 50 GB. Normalmente, esses espaços de

armazenamento devem ser mais do que suficientes para a maioria dos cenários

de migração.

Além disso, em alguns casos extremos em que bancos de dados muito grandes

com taxas de transação muito altas estão sendo migrados com a replicação

ativada, é possível que a replicação de AWS DMS não termine a tempo. Nessa

situação, talvez seja necessário interromper as alterações no banco de dados de

origem por alguns minutos para que a replicação termine antes que você possa

redirecionar o aplicativo para o banco de dados de destino do Aurora.

Figura 12: Página de criação da instância de replicação no console do AWS DMS


Página 38 de 46

Definir endpoints de origem e destino do banco de dados

Um endpoint de banco de dados é usado pela instância de replicação para

estabelecer a conexão com um banco de dados. Para realizar uma migração de

banco de dados, você deve criar um endpoint de banco de dados de origem e um

endpoint de banco de dados de destino. Os endpoints de banco de dados

especificados podem estar no local ou em execução no Amazon EC2 ou no

Amazon RDS, mas a origem e o destino não podem estar no local.

Recomendamos que você teste a conexão do endpoint de banco de dados depois

de defini-la. A mesma página é usada para criar um endpoint de banco de dados

também pode ser usada para testá-lo, conforme explicado posteriormente neste

documento.

Observação: se você tiver limitações de chave externa no esquema de origem,

ao criar o endpoint de destino, insira o seguinte para Extra connection

attributes (Atributos de conexão extras) na seção Advanced (Avançado):

initstmt=SET FOREIGN_KEY_CHECKS=0

Isso desativa as verificações de chave externa enquanto as tabelas de destino

estão sendo carregadas. Isso, por sua vez, impede que o carregamento seja

interrompido por falhas de verificação de chave externa em tabelas parcialmente

carregadas.


Página 39 de 46

Figura 13: Página de criação de endpoint de banco de dados no console do AWS DMS

Criar e executar uma tarefa de migração

Agora que você criou e testou os endpoints de banco de dados de origem

e destino, pode criar uma tarefa para realizar a migração de dados. Ao criar uma

tarefa, você especifica a instância de replicação que criou, o tipo de método de

migração de banco de dados (discutido anteriormente), o endpoint do banco de

dados de origem e o endpoint do banco de dados de destino para o cluster de

banco de dados do Amazon Aurora.


Página 40 de 46

Além disso, em Task Settings (Configurações de tarefa), se você já tiver criado

o esquema completo no banco de dados de destino, altere Target table

preparation mode (Modo de preparação da tabela de destino) para Do

nothing (Não fazer nada) em vez de usar o valor padrão de Drop tables on

target (Soltar tabelas no destino). Essa última opção pode fazer com que você

perca aspectos da definição de esquema, como restrições de chave externa ao

soltar e recriar tabelas.

Ao criar uma tarefa, você pode criar mapeamentos de tabela que especificam

o esquema de origem junto com as tabelas correspondentes a serem migradas

para o endpoint de destino. O método de mapeamento padrão migra todas as

tabelas de origem para tabelas de destino com o mesmo nome, se houver. Caso

contrário, ele cria as tabelas de origem no destino (dependendo das configurações

de tarefa). Além disso, você pode criar mapeamentos personalizados (usando um

arquivo JSON) se quiser migrar somente algumas tabelas ou se quiser ter mais

controle sobre o processo de mapeamento de campos e tabelas. Você também

pode optar por migrar somente um esquema ou todos os esquemas do endpoint

de origem.


Página 41 de 46

Figura 14: Página de criação de tarefa no console do AWS DMS

Você pode usar o Console de Gerenciamento da AWS para monitorar

o andamento das tarefas do Serviço de Migração de Banco de Dados da AWS

(AWS DMS). Também é possível monitorar os recursos e a conectividade de rede

usada. O console do AWS DMS mostra estatísticas básicas para cada tarefa,

incluindo o status da tarefa, a porcentagem de conclusão, o tempo decorrido e as

estatísticas da tabela, como mostra a imagem a seguir.

Além disso, você pode selecionar uma tarefa e exibir métricas de desempenho

dela, incluindo taxa de transferência, registros por segundo da migração, uso de

disco e memória e latência.

Figura 15: Status da tarefa no console do AWS DMS


Página 42 de 46

Testes e transição Assim que o esquema e os dados forem migrados do banco de dados de origem

para o Amazon Aurora, você poderá realizar o teste completo do processo de

migração. A abordagem de testes deve ser refinada depois de cada migração de

teste, e o plano de migração final deve incluir um plano de teste que garanta os

testes adequados do banco de dados migrado.

Testes de migração

Categoria de teste Finalidade

Testes básicos de

aceitação

Esses testes antes da transição devem ser executados automaticamente

após a conclusão do processo de migração de dados. Seu objetivo

principal é verificar se a migração de dados foi bem-sucedida. Veja alguns

resultados comuns desses testes:

• Número total de itens processados

• Número total de itens importados

• Número total de itens ignorados

• Número total de avisos

• Número total de erros

Se algum desses totais registrados pelos testes se desviar dos valores

esperados, significa que a migração não foi bem-sucedida, e os

problemas precisarão ser resolvidos antes de passar para a próxima

etapa do processo ou a próxima rodada de testes.

Testes funcionais Esses testes após a transição exercem a funcionalidade dos aplicativos

usando o Aurora para armazenamento físico de dados. Eles incluem

testes automáticos e manuais. O objetivo principal dos testes funcionais

é identificar problemas no aplicativo causados pela migração dos dados

para o Aurora.

Testes não funcionais Esses testes após a transição avaliam as características não funcionais

do aplicativo, como desempenho em diferentes níveis de carregamento.

Testes de aceitação do

usuário

Esses testes após a transição devem ser executados pelos usuários finais

do aplicativo assim que a transição e a migração de dados final forem

concluídas. O objetivo desses testes é fazer com que os usuários finais

decidam se o aplicativo pode ser usado de modo suficiente para atender

à sua função principal na organização.


Página 43 de 46

Transição Depois de concluir a migração final e os testes, é hora de direcionar o aplicativo

para o banco de dados do Amazon Aurora. Essa fase da migração é conhecida

como transição. Se o planejamento e a fase de testes tiverem sido devidamente

executados, a transição não deverá causar problemas inesperados.

Ações antes da transição

Escolha uma janela de transição: identifique um período em que você possa

realizar a transição para o novo banco de dados com interrupção mínima

dos negócios. Normalmente, você escolhe um período de pouca atividade

para o banco de dados (em geral, à noite e/ou nos finais de semana).

Verifique se as alterações são captadas: se uma abordagem de migração

com tempo de inatividade praticamente zero foi usada para replicar

alterações do banco de dados de origem para o banco de dados de destino,

verifique se todas as alterações são captadas e se o banco de dados de

destino não tem um atraso significativo em relação ao banco de dados de

origem.

Prepare scripts para fazer as alterações de configuração do aplicativo: para

realizar a transição, você precisa modificar os detalhes de conexão do

banco de dados nos arquivos de configuração do aplicativo. Aplicativos

grandes e complexos talvez precisem de atualizações nos detalhes de

conexão em vários lugares. Verifique se você tem os scripts necessários

prontos para atualizar a configuração de conexão de maneira rápida

e confiável.

Pare o aplicativo: pare os processos do aplicativo no banco de dados de

origem e coloque o banco de dados de origem no modo somente leitura

para que mais nenhuma gravação possa ser feita no banco de dados de

origem. Se as alterações no banco de dados de origem não forem

totalmente captadas com o banco de dados de destino, aguarde alguns

minutos enquanto essas alterações são totalmente propagadas para

o banco de dados de destino.

Execute os testes antes da transição: execute testes automáticos antes da

transição para verificar se a migração de dados foi bem-sucedida.


Página 44 de 46

Transição

Execute a transição: se as verificações antes da transição forem concluídas

com êxito, você poderá direcionar seu aplicativo para o Amazon Aurora.

Execute os scripts criados na fase pré-transição para alterar a configuração

do aplicativo para direcionamento ao novo banco de dados do Aurora.

Inicie o aplicativo: nesse momento, você pode iniciar seu aplicativo. Se você

puder impedir que os usuários acessem o aplicativo enquanto ele estiver

em execução, ative essa opção até executar as verificações pós-transição.

Verificações pós-transição

Execute testes pós-transição: execute testes manuais ou automáticos

predefinidos para verificar se seu aplicativo funciona conforme esperado

com o novo banco de dados. É uma boa estratégia começar a testar

a funcionalidade somente leitura do banco de dados primeiro antes de

executar testes que fazem gravação no banco de dados.

Ative o acesso do usuário e monitore de perto: se os testes tiverem sido

executados com êxito, você poderá conceder ao usuário acesso ao aplicativo

para concluir o processo de migração. O aplicativo e o banco de dados

devem ser monitorados de perto nesse momento.

Conclusão O Amazon Aurora é um banco de dados empresarial com alto desempenho

e extremamente disponível que foi desenvolvido para a nuvem. O uso do Amazon

Aurora pode resultar em melhor desempenho e maior disponibilidade do que

outros bancos de dados de código aberto e custos mais baixos do que a maioria

dos bancos de dados comerciais. Este documento propõe estratégias para

identificar o melhor método para migrar bancos de dados para o Amazon Aurora

e detalha os procedimentos para planejar e executar essas migrações. Em

particular, o AWS Database Migration Service (AWS DMS) e a ferramenta de

conversão de esquema da AWS são as ferramentas recomendadas para os

cenários de migração heterogênea. Essas ferramentas avançadas podem reduzir

muito o custo e a complexidade das migrações de banco de dados.


Página 45 de 46

Colaboradores As seguintes organizações e pessoas contribuíram para este documento:

Puneet Agarwal, arquiteto de soluções, Amazon Web Services

Scott Williams, arquiteto de soluções, Amazon Web Services

Leitura complementar Para obter mais ajuda, consulte estas fontes:

Detalhes do produto Amazon Aurora

Perguntas frequentes sobre o Amazon Aurora

Serviço de Migração de Banco de Dados da Amazon

Perguntas frequentes sobre o Serviço de Migração de Banco de Dados da

Amazon

Observações

1 https://aws.amazon.com/rds/aurora/

2 http://aws.amazon.com/rds/aurora/pricing/

3 https://d0.awsstatic.com/product-

marketing/Aurora/Aurora_Export_Import_Best_Practices_v1-3.pdf

4 http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/

Aurora.Replication.html#Aurora.Overview.Replication.MySQLReplication

5 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/

Aurora.Migrate.html#USER_ImportAurora.PreImport

6 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html

7 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html

8 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/

Aurora.Migrate.html#USER_ImportAuroraCluster.Console

9 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Connect.html

http://aws.amazon.com/rds/aurora/details/

http://aws.amazon.com/rds/aurora/faqs/

https://aws.amazon.com/dms/

https://aws.amazon.com/dms/faqs/

https://aws.amazon.com/dms/faqs/





http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/%20Aurora.Replication.html#Aurora.Overview.Replication.MySQLReplication

http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/%20Aurora.Replication.html#Aurora.Overview.Replication.MySQLReplication

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/%20Aurora.Migrate.html#USER_ImportAurora.PreImport

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/%20Aurora.Migrate.html#USER_ImportAurora.PreImport

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html


http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/%20Aurora.Migrate.html#USER_ImportAuroraCluster.Console

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/%20Aurora.Migrate.html#USER_ImportAuroraCluster.Console

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Connect.html


Página 46 de 46

10 https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html

11 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/Welcome.html

12 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/

CHAP_SchemaConversionTool.GettingStarted.html


CHAP_SchemaConversionTool.Installing.html

14 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide

/CHAP_SchemaConversionTool.Installing.html#CHAP_SchemaConversionTool.Installing

.JDBCDrivers

15 https://forums.aws.amazon.com/forum.jspa?forumID=208

16 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateInstance.html


CHAP_SchemaConversionTool.BestPractices.html

18 http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.html

19 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateInstance.html



http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.GettingStarted.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.GettingStarted.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.Installing.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.Installing.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide%20/CHAP_SchemaConversionTool.Installing.html#CHAP_SchemaConversionTool.Installing.JDBCDrivers



https://forums.aws.amazon.com/forum.jspa?forumID=208


http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.BestPractices.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.BestPractices.html

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.html


Documents

Migração de bancos de dados para o Amazon Aurorad0.awsstatic.com/whitepapers/RDS/Migrating_Databases_to_Amazon... · Migração de esquema usando a ferramenta de conversão de esquema