Baixado 50 vezes
Carregado porAmazon Web Services LATAM
Deep dive com Amazon Aurora
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.
Mais conteúdo relacionado
Semelhante a Deep dive com Amazon Aurora
Deep dive com Amazon Aurora
- 1. © 2016, AmazonWeb 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 – 18meses 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 deDados 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 dearmazenamento 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 AWSIAM 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çãodas 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 é usadopor: 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 dedados 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 dedesempenho: 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 DataIntegration 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 doAmazon 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.
- 14. Fazendo menos I/Os Reduzindoos 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-WRITELOGFRM 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 1AZ 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 registroe 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 deinstruçã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, chegamosver 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 reentrantessã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 debloqueio 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 MySQLSysBench 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 tamanhoda instância DESEMPEHO ESCRITA DESEMPEHO LEITURA Aurora MySQL 5.6 MySQL 5.7
- 25. Aurora 3X fasteron r3.4xlarge Dados de um caso real – Gaming Aurora vs RDS MySQL – r3.4XL, MultiAZ
- 26. Melhorias de desempenhorecentes
- 27. MySQL 5.6alavanca 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 MySQL5.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 asinserçõ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 cachena 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 auditorianativo 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 databela 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 emr3.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 Q22017 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.
- 37. Seis cópias atravésde 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áticodo 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 Logrecords 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 dadostradicionais 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 decache 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 storagevolume 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 falhasPropagaçã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 57 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 futurasmelhorias de disponibilidade
- 46. Você também podesofrer 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 OldDB 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 pendentesnos 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ópiade 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 Bancoclonado 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 queos 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 trazo 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 Logrecords 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 dentrodo 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.
- 56. Aurora forneceproteçã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 dadosorigem 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.
- 60. Category Q4/2016 Q1/2017Q2 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, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Damian Traverso, Solutions Architect Junho 2017, São Paulo Obrigado!
- 62. Ainda não temo App oficial do AWS Summit São Paulo? http://amzn.to/2rOcsVy Não deixe de avaliar as sessões no app!
Notas do Editor
- #5 Control plane applies to storage Use Icons Another Box Collapsing The relational database reinvented using a service-oriented approach Make the layers of the database scale out and multi-tenant. Started with storage Retained drop-in compatibility with MySQL 5.6. Your existing applications should just work
- #11 ANURAG to edit
- #18 Talk about inflow traffic seen – latency path is1. writing the log and returning. Then 2. sorting, grouping by block. 3. coalesce into blocks 4. generate snapshot for s3. 5. gc once in s3. 6. peer to peer replication to fill in holes. 7.
- #21 User is only allowed to see acknowledgements back Each storage node is acknowledging back. Determine when we’ve made quorum per write. Determine when we’ve made quorum on enough writes to advance volume durable LSN See if any requests are pending commit acknowledgement Ack those back “group commits” are asynchronous, not managed/issued by the database. Receive ACKs back from Storage Nodes Consider durable when first 4 of 6 ACK Advance DB Durable LSN once no holes ACK all pending commits below new DB Durable
- #22 Commits are async Locks we use growing threads Reads, we’re working on it Default mysql – 1 thread per connection Mysql ee adds a thread pool. Assigns connections to thread groups. One statement executes per group, remainder queue If beyond stall threshold or blocked, allow a second to execute Useful for short queries, homogenous pattern
- #29 We already mentioned how the lock was removed from the lock manager, but it was some impact on highly contended row/workloads Instead of keeping an entry per thread per lock, it was flipped and a bitmap saying which threads are waiting
- #40 Incrementos de segmentos de 10 GBs Bom para Custo e Disponibilidade, não ficar offline por falta de espaço
- #41 Não existe um momento específico que tenhã impacto no desempeho, backup é contínuo
- #45 Let’s take a look at how Aurora does in terms of failover times. Let’s say you have a primary database in one AZ, and a standby database running in another AZ. How much time would it take to failover from primary to standby in case of a failure. In case of RDS MySQL, which is shown on top of the screen, failure detection takes about 30 seconds, and then database starts doing crash recovery. This recovery time is unpredictable and largely depends on how many logs your database needs to replay to get to a consistent state. While database is replaying logs, DNS propagates from old master to the new master, and when everything is done – your app can again connect to the database and continue operations. In case of Aurora, shown on the bottom of the screen, failure detection isn’t much different than RDS MySQL. Right now it takes about 15 to 30 seconds, but we are working on improving this so that we can detect genuine failures in under 5 seconds. Crash recovery however, is much faster and predictable in case of Aurora, as we saw on the last slide. You can further reduce DNS propagation time by using a special connection driver, that instead of waiting on DNS propagation, queries a system table in Aurora to check who the new master is, and points applications to the new master. With this new connection driver, Aurora failover can be achieved in less than 30 seconds, and we hope to bring it down to less than 10 seconds with quick failure detection.
- #46 35 semanas de métricas de clusters dentro da AWS
- #49 Traditionally added a new DB and switch Now it looks like a bump in the wire/DB for about more 3 seconds than expected
- #59 Storage consumed