O documento apresenta o Amazon Aurora, um banco de dados relacional gerenciado pela AWS. O Aurora oferece desempenho 5x maior que o MySQL com disponibilidade e segurança equivalentes aos bancos de dados comerciais. O documento discute as melhorias de desempenho e disponibilidade do Aurora, incluindo índices mais rápidos e gerenciamento de bloqueios aprimorado.

1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Damian Traverso, Solutions Architect
Junho 2017, São Paulo
Deep Dive com Amazon Aurora

2. Atualizações – 18 meses desde GA
Agenda
O que é o Amazon Aurora?
Quem está usando?
Anúncios recentes
Desenhado para desempenho
Melhorias de desempenho do Aurora
Desenhado para disponibilidade
Melhorias recentes na disponibilidade
Desempenho do Aurora – Deep Dive
Arquitetura de disponibilidade

3. Amazon Aurora…
Banco de Dados reimaginado para a nuvem
Velocidade e disponibilidade dos bancos de dados
comerciais high-end
Simplicidade e baixo-custo dos bancos de dados Open
Source
Compatível com MySQL e PostgreSQL
Pague somente pelo uso
Fornecido como um serviço gerenciado

4. Serviço totalmente gerenciado – automatização
de tarefas
1
2
3
Escalável, distribuído, desenho multi-tenant
Arquitetura orientada a serviços, alavancando
serviços da AWS
Reimaginando o banco de dados
relacional

5.  Sistema de armazenamento de logs,
distribuído, concebido para banco de
dados
 O volume do armazenamento é
dividido em centenas de nós
distribuídos em 3 zonas de
disponibilidade
 Seis cópias de dados, duas cópias
em cada zona de disponibilidade para
proteger contra falhas AZ + 1
Master Replica Replica Replica
Availability
Zone 1
Shared storage volume
Availability
Zone 2
Availability
Zone 3
Storage nodes with SSDs
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
Arquitetura escalável, distribuída e multi-tenant

6. AWS Lambda
Amazon S3
AWS IAM
Invoque eventos de AWS Lambda a partir de stored
procedures/triggers.
Carregue dados de/para Amazon S3, armazene
snapshots e backups no S3.
Use AWS Identity & Access Management (IAM) roles para
gerenciar o controle de acesso.
Transfira métricas do sistema e logs de auditoria para
Amazon CloudWatch.
Alavancando o ecossistema de Nuvem
Amazon
CloudWatch

7. Desenho do esquema/modelo
Construção das queries
Otimização das queries
Recuperação automática
de falhas
Backup & recovery
Isolamento e segurança
Conformidade
Escalonamento a
distância de um clique
Automatização de
patches
Monitoramento avançado
Rotinas de manutenção
Se encarga das tarefas de gerenciamento de banco de dados, liberando
você para se concentrar em suas aplicações e em seu negócio.
Você
AWS
Automatize tarefas administrativas

8. Aurora é usado por:
2/3 dos 100 principais clientes da
AWS
8 dos 10 principais clientes de
Gaming
Serviço com o mais rápido
crescimento na história da AWS
Adoção do Aurora

9. Clientes usando banco
de dados comerciais
Clientes usando banco de
dados Open Source
Maior desempenho – até 5x
Maior disponibilidade e durabilidade
Redução de custos – até 60%
Facilidade para migrar; sem mudanças nas aplicações
Um décimo do custo; sem licenciamento
Integração com o ecossistema de nuvem
Desempenho e disponibilidade equivalente
Ferramentas e serviços de migração
Quem está migrando para Aurora e por que?

10.  Melhorias de desempenho: Fast DDL, fast index build, spatial indexing, hot row
contention
 Disponibilidade: Zero-downtime patching, database cloning (Q2), database backtrack
(Q3)
 Integração com ecossistema: Load from S3, Integração com IAM (Q2), select into S3
(Q2), upload de logs para o CloudWatch Logs & S3 (Q2)
 Redução de custos: t2.small – reduz o custo inicial pela metade– você pode rodar
Aurora por $1 / dia
 Crescimento: lançamento em LHR, YUL, CMH, e SFO – agora disponível em todas as
regiões com 3 AZs
Anúncios recentes

11. Business Intelligence Data Integration Query and Monitoring
“Executamos nossos testes de compatibilidade contra
o Amazon Aurora e simplesmente tudo funcionou”
- Dan Jewett, VP, Product Management do Tableau
Compatível com MySQL 5.6 / InnoDB
 Sem reportes de incompatibilidades
nos últimos 18 meses
 As aplicações MySQL ISV geralmente
rodam sem a necessidade de
qualquer mudança
Trabalhando na compatibilidade com
MySQL 5.7
 Mais lento do que o esperado
 81 fixes de diferentes releases do
MySQL foram incorporados
Compatibilidade com MySQL

12. A compatibilidade do Amazon Aurora para PostgreSQL já
está disponível como Preview
Utiliza o mesmo serviço escalável de armazenamento,
distribuído em 3 AZs, com 6 cópias, tolerância a falhas e
otimizado para banco de dados
Integração com banco de dados PostgreSQL 9.6
Logging + Storage
SQL
Transactions
Caching
Amazon S3
Suporte para PostgreSQL

13. Desenhado para desempenho

14. Fazendo menos I/Os
Reduzindo os pacotes de rede
Cache de resultados
Desonerando o motor do banco de dados
FAZENDO MENOS TRABALHO
Processando de maneira assíncrona
Reduzindo a latência
Usando estruturas de dados sem locking
Agrupando operações em batch
SENDO MAIS EFICIENTE
PARA BANCO DE DADOS, I/O É TUDO O QUE IMPORTA
PARA NAS, PACOTES POR SEGUNDO É TUDO O QUE IMPORTA
PARA PROCESSAMENTO DE GRANDE THROUGHPUT, CONTEXT SWITCHES É TUDO O QUE IMPORTA
Princípios de desempenho do Aurora

15. BINLOG DATA DOUBLE-WRITELOG FRM FILES
TIPOS DE ESCRITAS
MYSQL COM STANDBY
EBS mirrorEBS mirror
AZ 1 AZ 2
Amazon S3
EBS
Amazon Elastic
Block Store (EBS)
Primary
Instance
Replica
Instance
1
2
3
4
5
Envia uma escrita para o Amazon EBS – EBS envia para o volume
espelhado, ack somente quando ambos estiverem prontos
Envia para a instância standby usando replicação síncrona
Envia a escrita para o EBS na instância standby
FLUXO DE IO
Os passos 1, 3, 4 são sequenciais e síncronos
Isso amplifica a latência e o jitter
Vários tipos de escritas para cada operação do usuário
Precisa duplicar a escrita dos blocos de dados para evitar escritas
corrompidas
OBSERVAÇÕES
780K transações
7,388K I/Os por milhão txs (sem incluir o espelhamento nem
standyby)
Média 7.4 I/Os por transação
SysBench durante 30 minutos, carga somente de escrita, 100GB,
RDS Multi-AZ, 30K PIOPs
DESEMPENHO
Tráfego de I/O no MySQL

16. AMAZON AURORA
AZ 1 AZ 3
Primary
Instance
Amazon S3
AZ 2
Replica
Instance
ASYNC
4/6 QUORUM
DISTRIBUTED
WRITES
Replica
Instance
Tráfego de I/O no Aurora
BINLOG DATA DOUBLE-WRITELOG FRM FILES
TIPOS DE ESCRITAS
Agrupamento de registros redo logs – totalmente ordenados por LSN
Distribuição para os segmentos apropriados – parcialmente
ordenados
Agrupamento para os nós de armazenamento e emissão de escritas
FLUXO DE IO
Somente são escritos os registros redo logs; todos os passos são
assíncronos
Não são escritos blocos de dados (checkpoint, cache replacement)
6X mais escritas de log, mas 9X menos tráfego de rede
Tolerante à latência de rede e armazenamento
OBSERVAÇÕES
27.378K transações 35X MAIS
950K I/Os por 1M txs (amplificação de 6X) 7,7X MENOS
DESEMPENHO

17. ①Recebe o registro e o adiciona a uma fila em memória
②Persiste o registro e retorna ACK
③Organiza os registros e identifica logs incompletos
④Gossip com outros nós para completar esses logs
⑤Adere registros de log em novas versões dos blocos de
dados
⑥Envia periodicamente logs e novas versões dos blocos
para S3
⑦Executa periodicamente garbage collection de versões
antigas
⑧Valida periodicamente códigos CRC nos blocos
LOG RECORDS
Primary
Instance
INCOMING QUEUE
STORAGE NODE
S3 BACKUP
1
2
3
4
5
6
7
8
UPDATE
QUEUE
ACK
HOT
LOG
DATA
BLOCKS
POINT IN TIME
SNAPSHOT
GC
SCRUB
COALESCE
SORT
GROUP
PEER TO PEER GOSSIP
Peer
Storage
Nodes
Tráfego de I/O no Aurora
(Nó de Armazenamento) FLUXO DE IO
OBSERVAÇÕES
Todos os passos são assíncronos
Somente os passos 1 e 2 podem são sensíveis a latência
A fila de entrada é 46X menor do que no MySQL (sem amplificar,
por nó)
Favorece às operações sensíveis à latência
Usa espaço em disco como buffer suportar picos de atividade

18. Replicação lógica:
Envio de instrução SQL para a Réplica
Carga de escrita semelhante em ambas
instâncias
Armazenamento independente
Pode resultar em derivação de dados entre
Master e Réplica
Replicação física:
Envio de redo do Master para a Réplica
A Réplica compartilha o armazenamento. Não
são feitas escritas
Se aplicam os redo nas páginas em cache
Progride a vista de leitura quando todos os
commits são processados
ESCALABILIDADE DE LEITURA NO MYSQL ESCALABILIDADE DE LEITURA NO AMAZON AURORA
PAGE
CACHE
UPDATE
Aurora
Master
30% Read
70% Write
Aurora
Replica
100% New
Reads
Shared Multi-AZ Storage
MySQL
Master
30% Read
70% Write
MySQL
Replica
30% New
Reads
70% Write
SINGLE-
THREADED
BINLOG APPLY
Data Volume Data Volume
Tráfego de I/O nas Réplicas do Aurora

19. “Em MySQL, chegamos ver picos de replica lag de até 12 minutos o
que é praticamente absurdo para uma aplicação. No Aurora, o
máximo lag para as read replicas nunca superou os 20 ms”
Latência de leitura - Métricas de um caso real

20. Commit (T1)
Commit (T2)
Commit (T3)
LSN 10
LSN 12
LSN 22
LSN 50
LSN 30
LSN 34
LSN 41
LSN 47
LSN 20
LSN 49
Commit (T4)
Commit (T5)
Commit (T6)
Commit (T7)
Commit (T8)
LSN GROWTH
Durable LSN at head-node
COMMIT QUEUE
Commits pendentes ordenados por LSN
GROUP
COMMIT
Read
Write
Commit
Read
Read
T1
TEMPO
TRANSAÇÕES
Read
Write
Commit
Read
Read
T1
Read
Write
Commit
Read
Read
Tn
ABORDAGEM TRADICIONAL AMAZON AURORA
Manter um buffer dos registros de logs a serem
escritos a disco
Emitir a escrita quando o buffer estiver cheio ou
depois de um timeout
Se o taxa de escrita for baixa, quem escrever em
primeiro lugar tem uma penalidade em latência
Solicita I/O com a primeira escrita, completa o
buffer até a ela ser resolvida
Cada escrita é considerada durável quando 4 dos
6 nós retornam ACK
Muda o ponto durável do BD até o ACK mais
antigo
Group Commits Assíncronos

21. As conexões reentrantes são multiplexadas para threads
ativos
A função epoll() em Kernel-space insere as conexões numa
fila sem bloqueio
Dinamicamente dimensiona o thread pool
Facilmente lida com 5000+ sessões de clientes em r3.8xlarge
Standard MySQL – um thread por conexão
Não escala conforme a quantidade de conexões
MySQL EE – as conexões são atribuídas a um grupo
de threads
Requer um ajuste cuidadoso dos limites
Adaptive thread pool
CLIENTCONNECTION
LATCH FREE
TASK QUEUE
epoll()
AURORA THREAD MODEL
CLIENTCONNECTION
MYSQL THREAD MODEL

22. Mesma semântica de bloqueio que o MySQL
Acesso simultâneo a lock chains
Múltiplos scanners são permitidos em lock chains individuais
Detecção de deadlock sem trava
Necessário para suportar grandes quantidades de sessões simultâneas e uma alta taxa de atualização
Gerenciamento de locks

23. Resultados do MySQL SysBench
R3.8XL: 32 cores / 244 GB RAM
Desempenho cinco vezes maior do que MySQL
baseado em benchmarks da indústria
DESEMPEHO ESCRITA
0
25,000
50,000
75,000
100,000
125,000
150,000
DESEMPEHO LEITURA
0
100,000
200,000
300,000
400,000
500,000
600,000
700,000
Aurora MySQL 5.6 MySQL 5.7
5X mais rápido do que MySQL 5.6 & 5.7

24. Escalabilidade acompanha o
tamanho da instância
DESEMPEHO ESCRITA DESEMPEHO LEITURA
Aurora MySQL 5.6 MySQL 5.7

25. Aurora 3X faster on r3.4xlarge
Dados de um caso real – Gaming
Aurora vs RDS MySQL – r3.4XL, MultiAZ

26. Melhorias de desempenho recentes

27.  MySQL 5.6 alavanca a funcionalidade de Linux
read ahead – mas isso requer blocos de
endereços em btree. Insere as entradas de cima
para baixo no novo btree, causando divisões e
muitos registros de log.
 O scan do Aurora faz um pre-fetch dos blocos
baseado na posição na árvore, e não no
endereço do bloco.
 Aurora constrói as páginas folha e depois os
galhos (ramos) da árvore.
• Não existem divisões durante a construção,
• Cada página é acessada apenas uma vez.
• Um registro de log por página.
2-4X vezes mais desempenho do que
MySQL 5.6 ou MySQL 5.7
Faster Index Build – Agosto 2016

28. Hot row contention – Nov 2016
As cargas de trabalho altamente disputadas tinham um alto uso de memória e CPU
• Compressão de bloqueios (bitmap para hot locks)
• Substituição de spinlocks por blocking futex - até 12x de redução na CPU, 3x de
melhora na taxa de transferência
• Dezembro – uso de programação dinâmica para liberar bloqueios: de
O(totalLocks * waitLocks) para O(totalLocks)
O throughput no teste Percona TPC-C 100 melhorou 29x (de 1,452 txs/min para 42,181 txs/min)

29. MySQL 5.6 MySQL 5.7 Aurora Melhoria
500 conexões 6,093 25,289 73,955 2.92x
5000 conexões 1,671 2,592 42,181 16.3x
Percona TPC-C – 10GB
• As medidas no Aurora estão expressas em tpmC, usando a versão 1.10 em
R3.8xlarge, no caso de MySQL usando RDS e EBS com 30K PIOPS
MySQL 5.6 MySQL 5.7 Aurora Melhoria
500 conexões 3,231 11,868 70,663 5.95x
5000 conexões 5,575 13,005 30,221 2.32x
Percona TPC-C – 100GB
Hot row contention

30.  Acelera as inserções em lote classificadas pela chave
primária - funciona ao armazenar em cache a posição
do cursor em um índice transversal.
 De maneira dinâmica liga ou desliga-se com base no
padrão dos dados.
 Evita a contenção na aquisição de travas enquanto
navega pela árvore.
 Bidirecional, funciona em todas as instruções de
inserção
 LOAD INFILE, INSERT IN SELECT, INSERT IN
REPLACE e, Multi-value inserts.
Desempenho de INSERT – Dez 2015

31. Desempenho do cache na leitura
Concorrência do catálogo: sincronização de
dicionário de dados e despejo de cache aprimorados.
NUMA aware scheduler: o agendador do Aurora
agora é NUMA aware. Ajuda a escalar em instâncias
de múltiplos sockets.
Read views: O Aurora agora usa um algoritmo de
read-view simultâneo sem trava para construir
visualizações de leitura.
Ganho de 25% no
throughput
Agendador inteligente: O agendador do Aurora
agora atribui dinamicamente threads entre as cargas
intensivas de IO e CPU.
Seletor inteligente: Aurora reduz a latência de leitura
selecionando a cópia de dados em um nó de
armazenamento com melhor desempenho
Logical read ahead(LRA): evita esperas nos IOs de
leitura fazendo pre-fetch das páginas baseadas na
ordem no btree.
Ganho de 10% no
throughput
Desempenho de leitura fora do cache
Desempenho de leitura – Dez 2016

32. Suporte de auditoria nativo no Aurora
Podemos suportar mais de 500K eventos/seg
DDL
DML
Query
DCL
Connect
MariaDB server_audit plugin
Create event string
DDL
DML
Query
DCL
Connect
Write to
File
Create event string
Create event string
Create event string
Create event string
Create event string
Latch-free
queue
Write to File
Write to File
Write to File
MySQL 5.7 Aurora
Audit Off 95K 615K 6.47x
Audit On 33K 525K 15.9x
Sysbench: somente SELECTs em instância 8xlarge
Auditoria de alto desempenho – Jan 2017

33.  Cópia da tabela completa; reconstrói todos os
índices - pode levar horas para completar.
 Precisa de espaço temporário para operações DML;
bloqueio da tabela para mudanças de DML
 A operação de DDL afeta o throughput de DML
table name operation column-name time-stamp
Table 1
Table 2
Table 3
add-col
add-col
add-col
column-abc
column-qpr
column-xyz
t1
t2
t3
 Adiciona o registro em uma tabela de metadados –
é usado controle de versão para decodificar o
bloco.
 Quando o dado é modificado, atualiza o bloco para
o ultimo esquema
Aurora DDL
NULLable column at the end; other add column, drop/reorder, modify data types
Fast DDL: Aurora vs MySQL – Mar 2017

34. Desempenho DDL em r3.large Desempenho DDL em r3.8xlarge
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.27 sec 3,960 sec 1,600 sec
50GB table 0.25 sec 23,400 sec 5,040 sec
100GB table 0.26 sec 53,460 sec 9,720 sec
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.06 sec 900 sec 1,080 sec
50GB table 0.08 sec 4,680 sec 5,040 sec
100GB table 0.15 sec 14,400 sec 9,720 sec
Desempenho Fast DDL

35. Q1 2017 Q2 2017 2H 2017+
Adicionar uma coluna
nullable no final da
tabela, sem precisar
definir valor por
padrão
• Outras operações ADD
COLUMN
• Colunas Nullable e not
null
• Com e sem valor por
padrão
• No final, ou em qualquer
posição
• Marcar colunas como
nullable
• Reordenar colunas
• Aumentar o tamanho da
coluna dentro da família do
tipo de dado, como int para
bigint
• Apagar coluna
• Marcar colunas como not-
nullable
• …
Roadmap Fast DDL

36. Desenhado para disponibilidade

37. Seis cópias através de três Zonas de Disponibilidade
Quórum de 4 de 6 para escritas; 3 de 6 para leituras
Replicação Peer-to-peer para reparos
O volume é distribuído através de centenas de nós de armazenamento
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
Disponibilidade para Escritas e LeiturasDisponibilidade para Leituras
Replicação de 6 cópias
Sobrevive a falhas catastróficas

38.  Escalonamento automático do armazenamento até 64 TB
 Sistema de quórum para leituras/escritas; tolerante a
latência
 Protocolo Gossip peer-to-peer para reparar logs
incompletos
 Backups contínuos e incrementais no Amazon S3
(construído para 11 9s de durabilidade)
 Monitoramento contínuo de nós e discos para reparos
 Segmentos de 10GB como unidade de reparo ou re-
balanceio de hotspots
 As mudanças dos participantes do quórum não bloqueiam
as escritas
AZ 1 AZ 2 AZ 3
Amazon S3
Durabilidade do armazenamento

39. Segment snapshot Log records
Recovery point
Segment 1
Segment 2
Segment 3
Time
• Executa snapshot periódico de cada segmento em paralelo; envia redo logs para Amazon S3
• O backup acontece continuamente sem impacto no desempenho nem na disponibilidade
• Na restauração, resgata os snapshots apropriados de cada segmento e transfere os logs para os
nós de armazenamento
• Aplica os logs nos snapshots dos segmentos em paralelo e de maneira assíncrona
Backup contínuo e recuperacão point-in-time

40. Banco de dados tradicionais
Precisa reproduzir logs desde o último
checkpoint
Tipicamente 5 minutos entre cada checkpoint
Em MySQL essa operação é single-
threaded; requer uma grande quantidade de
acessos ao disco
Amazon Aurora
Por detrás, o armazenamento reproduz redo
logs sob demanda como parte da leitura do
disco
De maneira paralela, distribuída e assíncrona
Não existe reaplicação para a inicialização
Checkpointed Data Redo Log
Falha em T0 requer
a reaplicação do SQL
nos redo log a partir do último
checkpoint
T0
Falha em T0 resultará em redo logs sendo
aplicadas a cada segmento sob demanda,
em paralelo, de forma assíncrona
Recuperação instantânea de falhas
T0

41. O processo de cache foi movido fora do processo
do banco de dados
O cache se mantém “quente” no caso de
reinicialização do banco
Permite retomar toda a carga rapidamente
Recuperação instantânea de falhas + persistência
de caches = recuperação de falhas do BD de
maneira rápida e simples
O processo de Cache se encontra fora do processo do
BD e se mantém populado em eventos de restarts
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
Persistência de caches

42. Master
Read
Replica
Read
Replica
Read
Replica
Shared distributed storage volume
Reader end-point
► Até 15 réplicas de leitura através múltiplas Zonas de
Disponibilidade que podem ser promovidas
► Replicação baseada em redo logs leva a um baixo lag
– tipicamente < 10ms
► End-point de leitura com balanceamento; cliente pode
especificar a ordem do failover
Writer end-point
Até 15 Réplicas de leitura

43. App
ExecutandoDetecção de falhas Propagação de DNS
Recuperação Recuperação
Falha no
banco
RDS MYSQL
App
Executando
Detecção de falhas Propagação de DNS
Recuperação
Falha no
banco
AURORA COM MARIADB DRIVER
5 - 6 s e g
3 - 1 5 s e g
Failover mais rápido
5 - 6 s e g

44. 0.00%
5.00%
10.00%
15.00%
20.00%
25.00%
30.00%
35.00%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0 - 5s – 30% dos fail-overs
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
5 - 10s – 40% dos fail-overs
0%
10%
20%
30%
40%
50%
60%
1 2 3 4 5 6 7 8 9 1011121314151617181920212223242526272829303132333435
10 - 20s – 25% dos fail-overs
0%
2%
4%
6%
8%
10%
12%
14%
16%
18%
20%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
20 - 30s – 5% dos fail-overs
Tempos de failover

45. Recentes e futuras melhorias de
disponibilidade

46. Você também pode sofrer interrupções de disponibilidade quando você:
1. Aplicar patches do seu banco de dados
2. Modificar o esquema do seu banco de dados
3. Executar reorganizações do banco de dados em larga escala
4. Erros de DBA que requerem restaurações do banco
A disponibilidade é mais do que
falhas de HW

47. Networkin
g
state
Applicatio
n
state
Storage Service
App
state
Net
state
App
state
Net
state
Before
ZDP
New DB
Engine
Old DB
Engine
New DB
Engine
Old DB
Engine
With
ZDP
User sessions terminate
during patching
User sessions remain active
through patching
Storage Service
Zero downtime patching – Dez 2016

48. • Existem mudanças
pendentes nos parâmetros
• Tabelas temporárias
abertas
• Tabelas bloqueadas
Temos que aplicar o modelo de patching atual quando não é possível “estacionar” as conexões:
• Queries de longa
duração
• Transações abertas
• Bin-log ativado
• Conexões SSL abertas
Estamos trabalhando para resolver essas limitações
Zero downtime patching – limitações

49. Crie uma cópia de um banco de dados sem custos de
armazenamento duplicados
• A criação de um clone é quase instantânea - não
copiamos dados
• A cópia de dados ocorre apenas na gravação - quando
os dados originais e clonados diferem
Casos de uso típicos:
• Clonar um DB de produção para executar testes
• Reorganizar um banco de dados
• Salvar um point-in-time snapshot para análise sem
afetar o sistema de produção.
Production database
Clone Clone
Clone
Dev/test
applications
Benchmarks
Production
applications
Production
applications
Database cloning – Jun 2017

50. Page
1
Page
2
Page
3
Page
4
Banco origem Banco clonado
Sistema de Armazenamento Distribuído e Compartilhado: páginas físicas
Ambos bancos referenciam as mesmas páginas no sistema de armazenamento distribuído
Como funciona?
Page
1
Page
2
Page
3
Page
4
Page
1
Page
3
Page
2
Page
4

51. Page
1
Page
2
Page
3
Page
4
Page
5
Page
1
Page
3
Page
5
Page
2
Page
4
Page
6
Page
1
Page
2
Page
3
Page
4
Page
5
Page
6
À medida que os bancos divergem, novas páginas são adicionadas apropriadamente a cada
banco, enquanto ainda fazem referência a páginas comuns a ambos
Page
2
Page
3
Page
5
Como funciona? (cont)
Sistema de Armazenamento Distribuído e Compartilhado: páginas físicas
Banco origem Banco clonado

52. Backtrack rapidamente traz o banco de dados para um ponto no tempo sem exigir a restauração de
backups
• Backtracking de uma operação DML ou DDL não intencional
• O processo de backtrack não é destrutivo. Você pode retroceder várias vezes para encontrar o
ponto certo no tempo
t0 t1 t2
t0 t1
t2
t3 t4
t3
t4
Rebobinar para t1
Rebobinar para t3
Invisível Invisível
O que seria database backtrack?
Planejado para Q3 2017

53. Segment snapshot Log records
Rewind Point
Segment 1
Segment 2
Segment 3
Time
 Executa snapshots periódicos dentro de cada segmento em paralelo e os
armazena localmente
 No tempo de retrocesso, cada segmento escolhe o snapshot local anterior e
aplica os log ao snapshot para produzir o estado desejado do banco de dados
Storage Segments
Como funciona?

54. Os logs dentro do fluxo se tornam visíveis ou invisíveis no ramo da árvore LSN para
fornecer uma visão consistente para o DB
• O primeiro backtrack realizado em t2 para rebobinar o DB para t1, torna os logs
em cor roxa invisíveis
• O segundo backtrack executado no tempo t4 para rebobinar o DB para t3, torna os
logs em vermelho e roxo invisíveis
t0 t1 t2
t0 t1
t2
t3 t4
t3
t4
Rebobinar para t1
Rebobinar para t3
Invisible Invisible
Como funciona?

55. Removendo barreiras

56.  Aurora fornece proteção de firewall de IP para cada
instância
 Aurora oferece criptografia transparente em repouso
e proteção SSL para dados em trânsito
 Amazon VPC permite isolar e controlar a
configuração da rede e se conectar de forma segura
à sua infraestrutura de TI
 AWS Identity and Access Management fornece
controle de permissão ao nível de recurso
*Novo*
Meus bancos precisam atender
certificações
*Novo*

57. Desconto RI t2
Até 34% com 1-year RI
Até 57% com 3-year RI
vCPU Mem Preço / hora
db.t2.small 1 2 $0.041
db.t2.medium 2 4 $0.082
db.r3.large 2 15.25 $0.29
db.r3.xlarge 4 30.5 $0.58
db.r3.2xlarge 8 61 $1.16
db.r3.4xlarge 16 122 $2.32
db.r3.8xlarge 32 244 $4.64
*Preços para a região de Virginia
*NOVO*
Executar Aurora por $1 por dia?
Suporte para t2.small
*NOVO*

58. Banco de dados origem Desde Opção recomendadas
RDS
EC2, on premises
EC2, on premises, RDS
Snapshots automáticos ou
manuais feitos pelo console
mais replicação com binlog
Ingestão de snapshot
binário pelo S3 mais
replicação com binlog
Conversão do esquema
usando AWS SCT e
migração de dados com o
AWS DMS
Opções de migração para Aurora

59. Amazon Aurora roadmap

60. Category Q4/2016 Q1/2017 Q2 and Q3/2017
Performance • Spatial indexing
• R4 instance support
• Parallel data load from S3
• Out-of-cache read improvements
• Asynchronous key-based pre-fetch
Availability
• Reader cluster end
point and load
balancing
• Zero downtime
patching
• Cross-region snapshot copy
• Cross region replication for encrypted
databases
• Fast DDL v1
• Copy-on-write database cloning
• Backtrack
• Fast DDL v2
• Zero downtime restart
Security
• HIPAA/BAA
Compliance
• Enhanced auditing
• Cross account and cross region
encrypted snapshot sharing
• IAM Integration and Active
Directory integration
• Encrypted RDS MySQL-Aurora
replication
Ecosystem
Integration
• Lambda Integration
with Aurora
• Load tables from S3
• Load from S3 (manifest option)
• Load compressed files from S3
• Log upload to S3 and CloudWatch
• Select into S3
• Integration with AWS Performance
Insights
Cost-effective
• T2.medium instance
type
• T2.small instance type
MySQL-compatible
• RDS MySQL to Aurora replication (in
region)
• MySQL 5.7 compatibility
Regions • US West (N. California) • EU (Frankfurt)
Roadmap curto prazo – 3-6 meses
Acelerando a migração de BDs comerciais

61. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Damian Traverso, Solutions Architect
Junho 2017, São Paulo
Obrigado!

62. Ainda não tem o App oficial do
AWS Summit São Paulo?
http://amzn.to/2rOcsVy
Não deixe de avaliar as sessões no app!