migração de bancos de dados para o amazon...
TRANSCRIPT
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Opção 3: migração de esquema
usando ferramentas nativas + AWS
DMS para movimentação de dados
MySQL Amazon EC2
ou no local
Opção 1: migração usando
ferramentas nativas
Opção 2: migração de esquema
com ferramentas nativas + AWS
DMS para carregamento de dados
Opção 1: migração usando
ferramentas nativas + replicação de
binlog
Opção 2: migração de esquema
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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.
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
Amazon Web Services – Migração de bancos de dados para o Amazon Aurora Junho de 2016
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
13 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/
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
17 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/
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