Geral

P: O que é o Amazon Aurora?

O Amazon Aurora é um serviço de banco de dados relacional moderno que oferece performance e alta disponibilidade em escala, edições compatíveis com MySQL e PostgreSQL totalmente em código aberto e uma variedade de ferramentas de desenvolvedor para criar aplicações sem servidor e baseadas em machine learning (ML).

O Aurora oferece um sistema de armazenamento distribuído, tolerante a falhas e com recuperação automática que é independente dos recursos de computação e escala automaticamente para até 128 TB por instância de banco de dados. O Amazon Aurora oferece altos níveis de performance e disponibilidade, com até 15 réplicas de leitura de baixa latência, recuperação em um ponto anterior no tempo, backup contínuo para o Amazon Simple Storage Service (Amazon S3) e replicação entre três zonas de disponibilidade (AZs).

O Amazon Aurora também é um serviço totalmente gerenciado que automatiza tarefas de administração demoradas, como provisionamento de hardware, configuração de banco de dados, realização de patches e backups, ao mesmo tempo que oferece segurança, disponibilidade e confiabilidade de bancos de dados comerciais por uma fração do custo.

P: O que significa “compatível com o MySQL”?

O Amazon Aurora é compatível com os bancos de dados de código aberto MySQL existentes e adiciona suporte para novos lançamentos regularmente. Dessa forma, você pode migrar facilmente bancos de dados MySQL entre o Aurora usando ferramentas de importação/exportação padrão ou snapshots. Isso também significa que a maior parte do código, das aplicações, dos drivers e das ferramentas que você já usa com bancos de dados MySQL atualmente poderá ser usada com o Aurora com pouca ou nenhuma alteração. Ao considerar o Aurora vs. MySQL, é importante entender que o mecanismo de banco de dados do Amazon Aurora é projetado para ser compatível com o MySQL 5.6 e 5.7 usando o mecanismo de armazenamento InnoDB. Isso torna mais fácil mover aplicações entre os dois mecanismos. Alguns recursos do MySQL, como o mecanismo de armazenamento MyISAM, não estão disponíveis com o Amazon Aurora.

P: O que significa “compatível com o PostgreSQL”?

O Amazon Aurora é compatível com os bancos de dados de código aberto PostgreSQL existentes e adiciona suporte para novos lançamentos regularmente. Dessa forma, você pode migrar facilmente bancos de dados PostgreSQL entre o Aurora usando ferramentas de importação/exportação padrão ou snapshots do MySQL ou do PostgreSQL. Isso também significa que a maior parte do código, das aplicações, dos drivers e das ferramentas que você já usa com bancos de dados PostgreSQL atualmente poderá ser usada com o Aurora com pouca ou nenhuma alteração. 

P: Como devo pensar sobre o Amazon Aurora vs. Amazon Relational Database Service (Amazon RDS)?

R: O Amazon RDS é um serviço de banco de dados totalmente gerenciado, altamente disponível e seguro que simplifica a configuração, operação e execução de sete mecanismos de banco de dados relacionais: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, Amazon Aurora edição compatível com MySQL e Amazon Aurora edição compatível com PostgreSQL. 

O Amazon Aurora edição compatível com MySQL e o Amazon Aurora edição compatível com PostgreSQL aproveitam os benefícios do Amazon RDS, incluindo a automatização de tarefas administrativas demoradas de banco de dados, e oferecem performance, escalabilidade e disponibilidade aprimoradas em comparação com o MySQL e o PostgreSQL de código aberto da comunidade.

P: Como faço para testar o Amazon Aurora?

Para testar o Amazon Aurora, faça login no Console de Gerenciamento da AWS, selecione RDS na categoria Database e escolha o Amazon Aurora como mecanismo de banco de dados.

P: Quanto custa o Amazon Aurora?

Consulte a página de preços do Aurora para obter informações atualizadas.

P: O Amazon Aurora replica cada bloco do volume do meu banco de dados seis vezes entre as três zonas de disponibilidade. Isso significa que meu preço de armazenamento efetivo será três ou seis vezes o que é mostrado na página de definição de preço?

Não. A replicação do Amazon Aurora está incluída no preço. Você é cobrado com base no armazenamento consumido pelo seu banco de dados na camada de armazenamento, não pelo armazenamento consumido na camada de armazenamento virtualizada do Amazon Aurora.

P: Em quais regiões da AWS o Amazon Aurora está disponível?

Consulte a página de preços do Aurora para obter informações atualizadas sobre regiões e preços.

P: Como posso migrar do MySQL para o Amazon Aurora e vice-versa?

Você tem várias opções. Você pode usar o utilitário padrão mysqldump para exportar os dados do MySQL e o utilitário mysqlimport para importar dados para o Amazon Aurora, e vice-versa. Você também pode usar o recurso de migração de DB Snapshot do Amazon RDS para migrar um snapshot do banco de dados do Amazon RDS for MySQL para o Amazon Aurora usando o Console de Gerenciamento da AWS. Na maioria dos clientes, a migração é concluída em menos de uma hora, embora a duração dependa do formato e do tamanho do conjunto de dados. Para obter mais informações, consulte Melhores práticas para a migração de bancos de dados MySQL para o Amazon Aurora.

P: Como posso migrar do PostgreSQL para o Amazon Aurora e vice-versa?

Você tem várias opções. Você pode usar o utilitário padrão pg_dump para exportar os dados do PostgreSQL e o utilitário pg_restore para importar dados para o Amazon Aurora, e vice-versa. Também é possível usar o recurso de migração DB Snapshot do Amazon RDS para migrar um Snapshot do banco de dados do Amazon RDS for PostgreSQL para o Amazon Aurora usando o Console de Gerenciamento da AWS. Na maioria dos clientes, a migração é concluída em menos de uma hora, embora a duração dependa do formato e do tamanho do conjunto de dados. Para migrar aplicações SQL Server para o Aurora (edição compatível com PostgreSQL), você pode usar o Babelfish para Aurora PostgreSQL. Consulte a página de recursos do Babelfish para obter mais informações.

P: O Amazon Aurora participa do nível gratuito da AWS?

Não neste momento. O nível gratuito da AWS para o Amazon RDS oferece benefícios para microinstâncias de banco de dados. No momento, o Amazon Aurora não é compatível com microinstância do banco de dados. Consulte a página de preços do Aurora para obter informações atualizadas.

P: O que são E/Ss no Amazon Aurora e como são calculadas?

E/Ss são operações de entrada/saída executadas pelo mecanismo de banco de dados Aurora em relação à camada de armazenamento virtualizada baseada em Solid Stade Drive (SSD – Unidade de estado sólido). Cada operação de leitura de página do banco de dados conta como uma E/S. O mecanismo de banco de dados Aurora emite leituras na camada de armazenamento para obter as páginas de banco de dados que não estão presentes no cache. Se o tráfego da consulta puder ser totalmente atendido pela memória ou pelo cache, você não será cobrado por recuperar nenhuma página de dados da memória. Se o tráfego de consulta não puder ser atendido inteiramente pela memória, você será cobrado pelas páginas de dados que precisem ser recuperadas do armazenamento. Cada página de banco de dados tem 16 KB no Aurora edição compatível com MySQL e 8KB no Aurora edição compatível com PostgreSQL. 

O Aurora foi projetado para eliminar operações de E/S desnecessárias com o objetivo de reduzir custos e garantir a disponibilidade de recursos para atender ao tráfego de leitura/gravação. As E/Ss de gravação são consumidas apenas ao persistir os registros de log de refazimento no Aurora edição compatível com MySQL ou gravar os registros de log no Aurora edição compatível com PostgreSQL na camada de armazenamento com o objetivo de tornar as gravações duráveis. E/S de gravação são contadas em unidades de 4 KB. Por exemplo, um registro de log com 1024 bytes contará como uma operação de E/S de gravação. No entanto, se o registro de log for maior que 4 KB, mais de uma operação de E/S de gravação será necessária para persisti-lo. As operações de gravação simultâneas cujos registros de log são inferiores a 4 KB podem ser agrupadas pelo mecanismo de banco de dados do Aurora para otimizar o consumo de E/S se persistirem nos mesmos grupos de proteção de armazenamento. Ao contrário dos mecanismos de banco de dados tradicionais, o Aurora nunca libera páginas de dados incorretos para armazenamento. Você pode ver quantas solicitações de E/S sua instância do Aurora está consumindo verificando o Console de Gerenciamento da AWS. Você pode ver quantas solicitações de E/S sua instância do Aurora está consumindo acessando o console. Para localizar o seu consumo de E/S, consulte a seção Amazon RDS do console, pesquise na lista de instâncias, selecione as suas instâncias do Aurora e procure pelas métricas “Billed read operations” (Operações de leitura faturadas) e “Billed write operations” (Operações de gravação faturadas) na seção de monitoramento.

P: Preciso alterar drivers do cliente para usar o Amazon Aurora edição compatível com PostgreSQL?

Não. O Amazon Aurora funciona com os drivers de banco de dados padrão do PostgreSQL.

Performance

P: O que significa “performance cinco vezes maior que a do MySQL”?

O Amazon Aurora oferece aumentos significativos sobre a performance do MySQL integrando totalmente o mecanismo de banco de dados com uma camada de armazenamento virtualizada SSD criada especificamente para workloads de banco de dados, reduzindo as gravações no sistema de armazenamento, diminuindo a contenção por bloqueio e eliminando atrasos causados por threads de processo do banco de dados. Nossos testes com o SysBench em instâncias r3.8xlarge mostram que o Amazon Aurora entrega mais de 500.000 SELECTs/s e 100.000 UPDATEs/s, cinco vezes mais que o MySQL, executando o mesmo teste comparativo no mesmo hardware. Veja as instruções detalhadas sobre este teste comparativo e sobre como replicá-lo no Guia e benchmarking de performance do Amazon Aurora edição compatível com MySQL.

P: O que significa “performance três vezes maior que a do PostgreSQL”?

O Amazon Aurora oferece aumentos consideráveis de performance em relação ao PostgreSQL, integrando estreitamente o mecanismo de banco de dados com uma camada de armazenamento virtualizado em SSDs, criada especificamente para workloads de banco de dados, reduzindo as gravações no sistema de armazenamento, diminuindo a contenção de bloqueio e eliminando atrasos gerados pelos threads de processo do banco de dados. Nossos testes com o SysBench em instâncias r4.16xlarge mostram que o Amazon Aurora entrega um número de SELECTs/s e UPDATEs/s mais de três vezes maior que o PostgreSQL executando o mesmo teste comparativo no mesmo hardware. Veja as instruções detalhadas sobre este teste comparativo e sobre como replicá-lo no Guia de benchmark de performance do Amazon Aurora edição compatível com PostgreSQL.

P: Como posso otimizar a workload do banco de dados para o Amazon Aurora edição compatível com MySQL?

O Amazon Aurora é projetado para ser compatível com o MySQL, para que aplicações e ferramentas MySQL existentes possam ser executadas sem a necessidade de modificações. No entanto, uma área em que o Amazon Aurora oferece melhorias em relação ao MySQL é no uso de workloads altamente simultâneas. Para maximizar o taxa de transferência da workload no Amazon Aurora, recomendamos que você desenvolva as aplicações para gerar um grande número de consultas simultâneas.

P: Como posso otimizar a workload do banco de dados para o Amazon Aurora edição compatível com PostgreSQL?

O Amazon Aurora foi projetado para ser compatível com o PostgreSQL para permitir a execução de aplicações e ferramentas atuais do PostgreSQL sem modificações. No entanto, uma área em que o Amazon Aurora oferece melhorias em relação ao PostgreSQL é no uso de workloads altamente simultâneas. Para maximizar o throughput do workload no Amazon Aurora, recomendamos que você desenvolva os aplicativos para gerar um grande número de consultas simultâneas.

Hardware e escalabilidade

P: Quais são os limites mínimo e máximo de armazenamento de um banco de dados do Amazon Aurora?

O armazenamento mínimo é 10 GB. Com base na utilização do seu banco de dados, seu armazenamento do Amazon Aurora aumentará automaticamente até 128 TB, em incrementos de 10 GB, sem afetar a performance do banco de dados. Não há necessidade de provisionar antecipadamente o armazenamento.

P: Como posso dimensionar os recursos de computação associados à minha instância de banco de dados do Amazon Aurora?

Você pode usar o Aurora Serverless, uma configuração de escalonamento automático sob demanda para o Amazon Aurora, para dimensionar recursos de computação de banco de dados com base na demanda da aplicação. Ele permite que você execute seu banco de dados na nuvem sem se preocupar com o gerenciamento da capacidade do banco de dados. Você pode especificar o intervalo de capacidade de banco de dados desejado, e seu banco de dados será dimensionado com base nas necessidades de sua aplicação. Leia mais no Guia do usuário do Aurora Serverless.

Você também pode dimensionar manualmente os recursos de computação associados ao banco de dados selecionando o tipo de instância de banco de dados desejado no Console de gerenciamento da AWS. A alteração solicitada será aplicada durante a janela de manutenção especificada ou você pode usar o sinalizador "Aplicar imediatamente" para alterar o tipo de instância de banco de dados imediatamente. As duas opções afetarão a disponibilidade por alguns minutos enquanto a operação de escalabilidade é realizada. Note que qualquer outra alteração pendente do sistema também será aplicada.

Backup e restauração

P: Como faço para habilitar os backups para uma instância de banco de dados?

Backups automáticos estão sempre ativados nas instâncias de banco de dados do Amazon Aurora. Os backups não afetam a performance do banco de dados.

P: Posso fazer snapshots do banco de dados e mantê-los disponíveis pelo tempo que quiser?

Sim, e não há impacto na performance ao fazer snapshots. Observe que restaurar dados a partir de snapshots do banco de dados exige a criação de uma nova instância de banco de dados.

P: Se o meu banco de dados falhar, qual será meu caminho de recuperação?

O Amazon Aurora mantém automaticamente seis cópias dos dados em três zonas de disponibilidade (AZs) e tentará recuperar automaticamente o banco de dados em uma AZ íntegra, sem perda de dados. No caso improvável de seus dados estarem indisponíveis no armazenamento do Amazon Aurora, você pode restaurar a partir de um snapshot do banco de dados ou realizar uma operação de restauração em um ponto anterior no tempo para uma nova instância. Observe que o último momento restaurável para uma operação de restauração em um ponto anterior no tempo pode ser de até cinco minutos atrás.

P: O que acontece com meus backups e snapshots do banco de dados automatizados se eu excluir minha instância de banco de dados?

Você pode escolher criar um snapshot do banco de dados final ao excluir sua instância de banco de dados. Se fizer isso, pode usar este snapshot do banco de dados para restaurar a instância de banco de dados excluída posteriormente. O Amazon Aurora retém esse snapshot do banco de dados final criado pelo usuário junto com todos os outros snapshots de banco de dados criados manualmente após a instância de banco de dados ser excluída. Apenas snapshots do banco de dados são mantidos depois da exclusão da instância de banco de dados (ou seja, os backups automáticos criados para restauração point-in-time não são mantidos).

P: Posso compartilhar meus snapshots com outra conta da AWS?

Sim. O Aurora permite criar snapshots de bancos de dados, que podem ser usados posteriormente para restaurar um banco de dados. Você pode compartilhar um snapshot com uma conta diferente da AWS e o proprietário da conta de destino pode usar esse snapshot para restaurar um banco de dados com os seus dados. Você pode até mesmo optar por tornar seus snapshots públicos, ou seja, qualquer pessoa pode restaurar um BD contendo seus dados (públicos). É possível usar este recurso para compartilhar dados entre seus vários ambientes (produção, desenvolvimento/teste, preparação, etc.) que tenham contas diferentes da AWS, como também manter backups de todos os seus dados seguros em uma conta separada, caso sua conta principal da AWS sofra uma ameaça em algum momento.

P: Serei cobrado por snapshots compartilhados?

Não há cobrança pelo compartilhamento de snapshots entre contas. No entanto, podem haver cobranças pelos snapshots em si, como também por qualquer banco de dados que você restaurar usando os snapshots compartilhados. Saiba mais sobre preços do Aurora.

P: Posso compartilhar snapshots automaticamente?

Não oferecemos suporte ao compartilhamento de snapshots automáticos do banco de dados. Para compartilhar um snapshot automático, você deve criar manualmente uma cópia do snapshot e, então, compartilhar a cópia.

P: Com quantas contas posso compartilhar snapshots?

Você pode compartilhar snapshots manuais com até 20 IDs de conta da AWS. Caso deseje compartilhar um snapshot com mais de 20 contas, torne-o público ou entre em contato com o suporte para aumentar a sua cota.

P: Em quais regiões posso compartilhar meus snapshots do Aurora?

Você pode compartilhar seus snapshots do Aurora em todas as regiões da AWS onde o Aurora estiver disponível.

P: Posso compartilhar meus snapshots do Aurora entre regiões diferentes?

Não. Seus snapshots compartilhados do Aurora só poderão ser acessados por contas na mesma região da conta que os compartilha.

P: Posso compartilhar um snapshot criptografado do Aurora?

Sim, você pode compartilhar snapshots criptografados do Aurora.

Alta disponibilidade e replicação

P: Como o Amazon Aurora melhora a tolerância a falhas de disco do meu banco de dados?

O Amazon Aurora divide automaticamente o volume do seu banco de dados em segmentos de 10 GB em vários discos. Cada bloco de 10 GB do seu volume de banco de dados é replicado seis vezes em três zonas de disponibilidade. O Amazon Aurora é projetado para tratar de maneira transparente a perda de até duas cópias de dados sem afetar a disponibilidade de gravação do banco de dados e até três cópias sem afetar a disponibilidade de leitura. O armazenamento do Amazon Aurora também tem correção automática. Os blocos e discos de dados são varridos continuamente em busca de erros e corrigidos automaticamente.

P: Como o Aurora melhora o tempo de recuperação depois de uma falha do banco de dados?

Diferente dos outros bancos de dados, depois de uma falha, o Amazon Aurora não precisa reproduzir o log de refazimento do último ponto de verificação do banco de dados (normalmente cinco minutos) e confirmar que todas as alterações foram aplicadas antes de disponibilizar o banco de dados para operações. Isso reduz os tempos de reinicialização do banco de dados para menos de 60 segundos na maioria dos casos. O Amazon Aurora move o cache do buffer para fora do processo do banco de dados e o disponibiliza imediatamente no momento da reinicialização. Isso evita que você tenha que controlar o acesso até que o cache esteja preenchido novamente para evitar comprometimentos de performance.

P: Com que tipo de réplicas o Aurora é compatível?

O Amazon Aurora edição compatível com MySQL e o Amazon Aurora edição compatível com PostgreSQL são compatíveis com réplicas do Amazon Aurora que compartilham o mesmo volume subjacente da instância principal na mesma região da AWS. As atualizações feitas pela instância principal são visíveis para todas as réplicas do Amazon Aurora. Com o Amazon Aurora edição compatível com MySQL, você também pode criar réplicas de leitura do MySQL entre regiões usando o mecanismo de replicação baseado em binlog do MySQL. Nas réplicas de leitura do MySQL, os dados da sua instância principal são reproduzidos em sua réplica como transações. Para a maioria dos casos de uso, inclusive escalabilidade e alta disponibilidade de leitura, recomendamos o uso de Réplicas do Amazon Aurora.

Você tem a flexibilidade de misturar e corresponder esses dois tipos de réplicas com base nas necessidades da aplicação:

Recurso Réplicas do Amazon Aurora
Réplicas do MySQL
Número de réplicas Até 15 Até 5
Tipo de réplica Assíncrono (milissegundos) Assíncrono (segundos)
Impacto de performance na instância principal Baixo Alto
Localização da réplica Na região
Entre regiões
Atua como destino de failover Sim (sem perda de dados) Sim (possivelmente minutos de perda de dados)
Failover automatizado Sim Não
Suporte para atraso de replicação definido pelo usuário Não Sim
Suporte para diferentes dados ou esquema x principal Não Sim

Você tem duas opções de replicação adicionais, além das listadas acima. Você pode usar o Amazon Aurora Global Database para obter uma replicação física muito mais rápida entre clusters do Aurora em diferentes regiões. E, para replicação entre bancos de dados que não seja com Aurora edição compatível com MySQL (mesmo fora da AWS), você pode configurar sua própria replicação de binlog autogerenciada.

P: Posso ter réplicas entre regiões com o Amazon Aurora?

Sim, você pode configurar réplicas do Aurora em várias regiões usando replicação lógica ou física. A replicação física, chamada Amazon Aurora Global Database, usa uma infraestrutura dedicada que deixa seus bancos de dados inteiramente disponíveis para atender à aplicação, podendo replicar para até cinco regiões secundárias com latência típica de menos de um segundo. Está disponível para Aurora edição compatível com MySQL e Aurora edição compatível com PostgreSQL. Para leituras globais de baixa latência e recuperação de desastres, recomendamos o uso do banco do Amazon Aurora Global Database.

O Aurora é compatível com replicação lógica nativa em cada mecanismo de banco de dados (log binário para MySQL e slots de replicação PostgreSQL para PostgreSQL), então é possível replicar para bancos de dados Aurora e não Aurora, mesmo entre regiões.

O Aurora edição compatível com MySQL também oferece um recurso lógico de réplica de leitura entre regiões fácil de usar compatível com até cinco regiões da AWS secundárias. Essa replicação é baseada na replicação binlog do MySQL com thread único, assim o atraso da replicação será influenciado pela taxa de alteração/aplicação e demoras na comunicação de rede entre as regiões específicas selecionadas.

Posso criar réplicas do Aurora no cluster de réplica entre regiões?

Sim, você pode adicionar até 15 réplicas do Aurora em cada cluster entre regiões e elas compartilharão o mesmo armazenamento subjacente que a réplica entre regiões. Uma réplica entre regiões atua como a instância principal no cluster e as réplicas do Aurora no cluster, geralmente, apresentam um atraso de dez milissegundos com relação à principal.

Posso fazer o failover da aplicação por meio da instância principal atual para a réplica entre regiões?

Sim, você pode promover a réplica entre regiões como a nova instância principal no console do Amazon RDS. Para replicação lógica (binlog), o processo de promoção costuma levar alguns minutos, dependendo da sua workload. A replicação entre regiões será interrompida quando você iniciar o processo de promoção.

Com o Amazon Aurora Global Database, você pode promover uma região secundária para receber workloads completas de leitura/gravação em menos de um minuto.

P: Eu posso priorizar algumas réplicas como alvos de failover sobre outras?

Sim. Você pode atribuir uma camada de prioridade de promoção para cada instância no seu cluster. Quando a instância principal falhar, o Amazon RDS promoverá a réplica com a maior prioridade como principal. Se duas ou mais Réplicas do Aurora compartilham a mesma prioridade, o Amazon RDS promove a réplica de maior tamanho. Se duas ou mais Réplicas do Aurora compartilham a mesma prioridade e tamanho, o Amazon RDS promove uma réplica arbitrária no mesmo nível de promoção. Para obter mais informações sobre a lógica de failover, leia o Guia do usuário do Amazon Aurora.

P: Posso modificar as camadas de prioridade para instâncias depois que elas forem criadas?

Sim, você pode modificar a camada de prioridade para uma instância a qualquer momento. Um failover não é acionado apenas com a modificação de camadas de prioridade.

P: Posso evitar que determinadas réplicas sejam promovidas para a instância principal?

Você pode atribuir camadas de prioridade mais baixas para réplicas que você não deseja promover para a instância principal. No entanto, se as réplicas de prioridade mais alta no cluster não estiverem saudáveis ou disponíveis por alguma razão, o Amazon RDS promoverá a réplica de prioridade mais baixa.

P: Como posso melhorar a disponibilidade de um único banco de dados do Amazon Aurora?

Você pode adicionar réplicas do Amazon Aurora. As réplicas do Aurora na mesma região da AWS compartilham o mesmo armazenamento subjacente da instância principal. Qualquer réplica do Aurora pode ser promovida a principal sem nenhuma perda de dados e, portanto, pode ser usada para melhorar a tolerância a falhas no caso de falha de uma instância do banco de dados primário. Para aumentar a disponibilidade do banco de dados, basta criar de uma a 15 réplicas em qualquer uma das três zonas de disponibilidade, e o Amazon RDS as incluirá automaticamente na seleção de failover principal no caso de interrupção de um banco de dados.

Você poderá usar o Amazon Aurora Global Database se quiser que seu banco de dados abranja várias regiões da AWS. Isso replicará seus dados sem impactos para a performance do banco de dados, fornecendo recuperação de desastres em caso de interrupções em toda a região.

P: O que acontece durante o failover e quanto tempo leva?

O failover é controlado automaticamente pelo Amazon Aurora para que suas aplicações possam retomar as operações de banco de dados o mais rapidamente possível sem intervenção administrativa manual.

  • Se você tiver uma réplica do Amazon Aurora na mesma zona de disponibilidade ou em outra, ao fazer o failover, o Aurora alterará o registro de nome canônico (CNAME) da sua instância de banco de dados para apontar para a réplica saudável que, por sua vez, é promovida e se torna a nova principal. Normalmente, o failover é concluído em até 30 segundos. 
  • Se você estiver executando o Aurora sem servidor e a instância de banco de dados ou zona de disponibilidade ficar indisponível, o Aurora automaticamente recriará uma instância de banco de dados em outra zona de disponibilidade. 
  • Se você não tiver uma réplica do Amazon Aurora (ou seja, uma instância única) e não estiver executando o Aurora sem servidor, o Aurora tentará criar uma nova instância de banco de dados na mesma zona de disponibilidade da instância original. Essa substituição da instância original é realizada por meio do melhor esforço possível e pode ser que não seja concluída se, por exemplo, houver um problema que potencialmente afete a zona de disponibilidade.

Em caso de perda de conexão, o seu aplicativo deve tentar novamente fazer as conexões do banco de dados. A recuperação de desastre entre regiões é um processo manual, em que você promove uma região secundária para receber cargas de trabalho de leitura/gravação.

P: Se eu tiver um banco de dados primário e uma réplica do Amazon Aurora ativamente usando o tráfego de leitura e ocorrer um failover, o que acontecerá?

O Amazon Aurora detectará automaticamente o problema afetando sua instância principal e acionará um failover. Se você estiver usando o Cluster Endpoint, suas conexões de leitura/gravação serão automaticamente redirecionadas para uma réplica do Amazon Aurora que será promovida como principal. Além disso, o tráfego de leitura atendido pelas réplicas do Aurora será brevemente interrompido. Se você estiver usando o Cluster Reader Endpoint para direcionar seu tráfego de leitura para a réplica do Aurora, as conexões configuradas somente para leitura serão direcionadas para a réplica do Aurora recém-promovida até que o nó principal anterior seja recuperado como uma réplica.

P: Qual a defasagem entre a instância principal e as réplicas?

Como as réplicas do Amazon Aurora compartilham o mesmo volume de dados da instância principal na mesma região da AWS, praticamente não há atraso na replicação. Normalmente, observamos defasagens de dezenas de milissegundos. Para réplicas de leitura do MySQL, o atraso de replicação pode aumentar indefinidamente com base na taxa de alteração/aplicação, bem como atrasos na comunicação da rede. No entanto, em condições normais, é comum um atraso na replicação de menos de um minuto.

As réplicas entre regiões usando replicação lógica serão influenciadas pela taxa de alteração/aplicação e atrasos na comunicação de rede entre as regiões específicas selecionadas. As réplicas entre regiões usando o Amazon Aurora Global Database terão uma defasagem típica de menos de um segundo.

P: Posso configurar a replicação entre um banco de dados Aurora edição compatível com MySQL e um banco de dados MySQL externo?

Sim, você pode configurar a replicação de binlog entre uma instância do Aurora edição compatível com MySQL e um banco de dados MySQL externo. O outro banco de dados pode ser executado no Amazon RDS ou como um banco de dados autogerenciado na AWS ou completamente fora da AWS.

Se você estiver executando o Aurora edição compatível com MySQL 5.7, considere configurar a replicação de binlog baseada em GTIDs. Isso oferecerá consistência completa para que a replicação não perca transações ou gere conflitos, mesmo após failover ou tempo de inatividade.

P: O que é o Amazon Aurora Global Database?

O Amazon Aurora Global Database é um recurso que permite que um único banco de dados do Amazon Aurora abranja várias regiões da AWS. Ele replica seus dados sem gerar impactos para a performance do banco de dados, permitindo leituras locais rápidas em cada região com latência típica de menos de um segundo, fornecendo recuperação de desastres em casos de interrupção em toda a região. No evento improvável de degradação ou interrupção regional, uma região secundária poderá ser promovida para oferecer recursos completos de leitura/gravação em menos de um minuto.

Esse recurso está disponível para Aurora edição compatível com MySQL e Aurora edição compatível com PostgreSQL.

P: Como criar um Amazon Aurora Global Database?

Você pode criar um Aurora Global Database com apenas alguns cliques no console do Amazon RDS. Ou você pode usar o Kit de Desenvolvimento de Software (SDK) ou a Interface de Linha de Comando (CLI) da AWS. Você precisa provisionar pelo menos uma instância por região no seu Amazon Aurora Global Database.

P: Quantas regiões secundárias um Amazon Aurora Global Database pode ter?

Você pode criar até cinco regiões secundárias para um Amazon Aurora Global Database.

P: Se eu usar o Amazon Aurora Global Database, também poderei usar a replicação lógica (binlog) no banco de dados primário?

Sim. Se o seu objetivo é analisar a atividade do banco de dados, considere o uso de auditoria avançada do Aurora, logs gerais e logs de consulta lenta, para evitar impactos na performance do banco de dados.

P: O Aurora fará o failover automaticamente para uma região secundária do Amazon Aurora Global Database?

Não. Se a região principal ficar indisponível, você poderá remover manualmente uma região secundária de um Amazon Aurora Global Database e promovê-la para receber leituras e gravações completas. Você também precisará direcionar a aplicação para a região recém-promovida.

P: O que é o Amazon Aurora Multi-Master?

O Amazon Aurora Multi-Master é um novo recurso do Aurora edição compatível com MySQL que adiciona a capacidade de aumentar a escala da performance de gravação em várias zonas de disponibilidade, permitindo que as aplicações direcionem workloads de leitura/gravação para várias instâncias em um cluster de banco de dados e operem com maior disponibilidade.

P: Como posso começar a usar o Amazon Aurora Multi-Master?

O Amazon Aurora Multi-Master já está disponível. Leia a documentação do Amazon Aurora para saber mais. Você pode criar um cluster do Aurora Multi-Master com apenas alguns cliques no console do Amazon RDS ou baixando o SDK ou a CLI mais recente da AWS.

Segurança

P: Posso usar o Amazon Aurora no Amazon Virtual Private Cloud (Amazon VPC)?

Sim, todas as instâncias de banco de dados do Amazon Aurora devem ser criadas em uma VPC. Com o Amazon VPC, é possível definir uma topologia de rede virtual que lembra muito uma rede tradicional que você poderá operar no seu próprio datacenter. Isso oferece a você total controle sobre quem acessa seus bancos de dados do Amazon Aurora.

P: O Amazon Aurora criptografa meus dados em trânsito e ociosos?

Sim. O Amazon Aurora usa SSL (AES-256) para proteger a conexão entre a instância de banco de dados e a aplicação. O Amazon Aurora permite criptografar bancos de dados usando chaves gerenciadas pelo AWS Key Management Service (AWS KMS). Em uma instância de banco de dados em execução com a criptografia do Amazon Aurora, os dados ociosos mantidos no armazenamento subjacente são criptografados, bem como os backups automáticos, as réplicas de leitura e os snapshots desses dados no mesmo cluster. A criptografia e a descriptografia são processadas de forma transparente. Para obter mais informações sobre o uso do AWS KMS com o Amazon Aurora, consulte o Guia do usuário do Amazon RDS.

P: Posso criptografar um banco de dados não criptografado existente?

No momento, a criptografia de uma instância do Aurora não criptografada não é suportada. Para usar a criptografia do Amazon Aurora para um banco de dados descriptografado existente, crie uma nova instância de banco de dados com criptografia ativada e migre seus dados para ela.

P: Como posso acessar meu banco de dados do Amazon Aurora?

Os bancos de dados do Amazon Aurora devem ser acessados pela porta de banco de dados inserida na criação do banco de dados. Isso oferece uma camada adicional de segurança para os seus dados. Instruções detalhadas sobre como conectar ao seu banco de dados do Amazon Aurora são fornecidas no Guia de conectividade do Amazon Aurora.

P: Posso usar o Amazon Aurora com aplicações que exigem conformidade com a HIPAA?

Sim. As edições do Aurora compatíveis com MySQL e PostgreSQL são qualificadas pela Health Insurance Portability and Accountability Act (HIPAA – Lei de portabilidade e responsabilidade de seguro saúde). Portanto, podem ser utilizadas para criar aplicações em conformidade com a HIPAA e armazenar informações relacionadas à saúde, incluindo Protected Health Information (PHI – Informações de saúde protegidas), mediante a assinatura de um Business Associate Agreement (BAA – Acordo de Associação Comercial) com a AWS. Se você já tiver um BAA assinado, nenhuma ação será necessária para começar a usar esses serviços nas contas cobertas pelo BAA. Para obter mais informações sobre a criação de aplicativos compatíveis com a AWS, consulte Provedores e seguradoras de serviços de saúde na nuvem.

P: Onde posso acessar uma lista com entradas de Vulnerabilidades e exposições comuns (CVE) de vulnerabilidades de segurança publicamente conhecidas nas versões do Amazon Aurora?

Atualmente, essa lista de CVEs pode ser encontrada nas Atualizações de segurança do Amazon Aurora.

Sem servidor

P: O que é o Amazon Aurora Serverless?

O Aurora Serverless é uma configuração com escalabilidade automática sob demanda para Amazon Aurora. Ele permite que você execute um banco de dados na nuvem sem gerenciar qualquer capacidade de banco de dados. O gerenciamento manual da capacidade do banco de dados desperdiça um tempo valioso e pode levar ao uso ineficiente dos recursos do banco de dados. Com o Aurora Serverless, basta criar um banco de dados, especificar o intervalo da capacidade desejada para o banco de dados e conectar suas aplicações. O Aurora ajusta automaticamente a capacidade dentro do intervalo especificado com base nas necessidades de sua aplicação. Você paga por segundo pela capacidade do banco de dados que usa quando o banco de dados está ativo. Saiba mais sobre o Aurora Serverless e comece a usar com alguns cliques no Console de Gerenciamento do Amazon RDS.

P: Qual é a diferença entre o Aurora Serverless v2 e v1?

O Aurora Serverless v2 oferece suporte a todos os tipos de workloads de banco de dados, desde ambientes de desenvolvimento e teste, sites e aplicações com workloads pouco frequentes, intermitentes ou imprevisíveis até as aplicações mais exigentes e essenciais aos negócios que exigem alta escala e alta disponibilidade. Ele reduz a escala na horizontal no local adicionando mais CPU e memória sem precisar fazer failover do banco de dados para uma instância de banco de dados maior ou menor. Como resultado, ele pode ser escalado mesmo quando há transações de longa duração, bloqueios de tabela etc. Além disso, ele dimensiona a capacidade do banco de dados em incrementos tão pequenos quanto 0,5 da Unidade de capacidade do Aurora (ACUs) para que a capacidade do banco de dados corresponda às necessidades de sua aplicação.

O Aurora Serverless v1 é uma opção relativamente simples e com bom custo-benefício para workloads pouco frequentes, intermitentes ou imprevisíveis. Ele é inicializado automaticamente, dimensiona a capacidade computacional para corresponder ao uso de sua aplicação e é desligado quando não está em uso. Acesse o Guia do usuário do Aurora para saber mais.

P: Quais recursos do Aurora são compatíveis com o Aurora Serverless v2?

O Aurora Serverless v2 oferece suporte a todos os recursos do Aurora provisionado, incluindo réplica de leitura, configuração multi-AZ, Global Database, proxy RDS e Performance Insights.

P: Posso começar a usar o Aurora Serverless v2 com meu cluster de banco de dados do Aurora existente?

Sim, você pode começar a usar o Aurora Serverless v2 para gerenciar a capacidade computacional do banco de dados em seu cluster de banco de dados do Aurora existente. Um cluster que contém as instâncias provisionadas e o Aurora Serverless v2 é chamado de cluster de configuração mista. Você pode optar por ter qualquer combinação de instâncias provisionadas e Aurora Serverless v2 em seu cluster. Para testar o Aurora Serverless v2, adicione um leitor ao cluster de banco de dados do Aurora e selecione Serverless v2 como o tipo de instância. Depois que o leitor for criado e estiver disponível, você poderá começar a usá-lo para workloads de somente leitura. Depois de confirmar que o leitor está funcionando conforme o esperado, você pode iniciar um failover para começar a usar o Aurora Serverless v2 para leituras e gravações. Essa opção oferece uma experiência mínima de tempo de inatividade para começar a usar o Aurora Serverless v2.

P: Posso migrar do Aurora Serverless v1 para o Aurora Serverless v2?

Sim, você pode migrar do Aurora Serverless v1 para o Aurora Serverless v2. Consulte o Guia do usuário do Aurora para saber mais.

P: Quais versões do Amazon Aurora são compatíveis com o Aurora Serverless?

O Aurora Serverless v2 está disponível para edição compatível com MySQL do Amazon Aurora, a partir da versão 8.0 e edição compatível com PostgreSQL, a partir da versão 13.5. O Aurora Serverless v1 está disponível para Aurora MySQL 5.6 e 5.7 e Aurora PostgreSQL 10.14.

P: Posso migrar um cluster de banco de dados do Aurora para o Aurora Serverless?

Sim. Você pode restaurar um snapshot obtido de um cluster provisionado existente do Aurora para um cluster de banco de dados do Aurora Serverless (e vice-versa).

P: Como faço para conectar a um cluster de banco de dados do Aurora Serverless?

Acesse um cluster de banco de dados do Aurora Serverless de uma aplicação cliente que esteja sendo executada na mesma VPC. Não é possível associar um endereço IP público a um cluster de banco de dados do Aurora Serverless.

P: Posso definir explicitamente a capacidade de um cluster do Aurora Serverless?

Embora o Aurora Serverless escale automaticamente de acordo com a workload ativa do banco de dados, a capacidade pode não escalar com velocidade suficiente para absorver uma mudança súbita da workload, como um grande número de novas transações. Nesses casos, você pode definir explicitamente a capacidade para um valor específico no Console de Gerenciamento da AWS, na AWS CLI ou na API do Amazon RDS.

P: Por que o meu cluster de banco de dados do Aurora Serverless não escala automaticamente?

Após o início de uma operação de escalabilidade, o Aurora Serverless tenta encontrar um ponto de alteração de escala, que é o momento em que o banco de dados pode concluir a alteração de escala com segurança. Se você tiver consultas com execução demorada, transações em andamento ou bloqueios temporários em tabelas ou tabelas temporárias, o Aurora Serverless poderá não encontrar um ponto de alteração de escala.

P: Como é a cobrança pelo Aurora Serverless?

No Aurora Serverless, a capacidade do banco de dados é medida em unidades de capacidade do Aurora (ACUs). Você paga uma taxa fixa por segundo de uso do ACU. Os preços do armazenamento e da E/S das configurações provisionadas e Serverless são os mesmos. Acesse a página de preços do Aurora para obter informações atualizadas sobre preços e disponibilidade de região da AWS.

Consulta paralela

P: O que é o Amazon Aurora Parallel Query?

O Amazon Aurora Parallel Query é a capacidade de transferir e distribuir a carga computacional de uma única consulta entre milhares de CPUs na camada de armazenamento do Aurora. Sem o Parallel Query, uma consulta emitida para um banco de dados do Amazon Aurora seria executada inteiramente em uma instância do cluster de banco de dados, de forma similar à operação da maioria dos bancos de dados.

P: Qual é o caso de uso pretendido?

O Parallel Query é adequado para cargas de trabalho analíticas que exigem dados atualizados e boa performance de consulta, mesmo em tabelas grandes. Muitas vezes, as cargas de trabalho desse tipo são de natureza operacional.

P: Quais os benefícios oferecidos pelo Parallel Query?

O Parallel Query resulta em performance mais rápida, acelerando as consultas analíticas em até duas ordens de magnitude. Também proporciona simplicidade operacional e dados atualizados, pois você pode emitir uma consulta diretamente para os dados transacionais atuais no cluster do Aurora. E o Parallel Query possibilita workloads transacionais e analíticas no mesmo banco de dados, permitindo que o Aurora mantenha um alta taxa de transferência de transações juntamente com consultas analíticas simultâneas.

P: Quais consultas específicas são beneficiadas com o Parallel Query?

A maioria das consultas usando conjuntos de dados grandes que ainda não estão no grupo de buffers são candidatas a obter benefícios. A versão inicial do Parallel Query pode transferir e escalar horizontalmente o processamento de mais de 200 funções, associações de igualdade (equijoins) e projeções SQL.

P: Qual aumento de performance posso esperar?

O aumento de performance de uma consulta específica depende de quanto do plano de consulta pode ser transferido para a camada de armazenamento do Aurora. Os clientes relataram mais do que uma melhoria da ordem de magnitude para consultar a latência.

P: Existe alguma chance de a performance ser mais lenta?

Sim, mas esperamos que esses casos sejam raros.

P: Quais mudanças são necessárias em uma consulta para usar o Parallel Query?

Não é necessário alterar a sintaxe da consulta. O otimizador de consultas decidirá automaticamente se o Parallel Query será usado para uma consulta específica. Para verificar se uma consulta está usando o Parallel Query, você pode ver o plano de execução da consulta executando o comando EXPLAIN. Se você quiser ignorar a heurística e forçar a utilização do Parallel Query para fazer testes, use a variável de sessão aurora_pq_force.

P: Como faço para ativar ou desativar o recurso?

O Parallel Query pode ser habilitado e desabilitado dinamicamente no nível global ou de sessão usando o parâmetro aurora_pq.

P: Há alguma cobrança adicional associada ao uso do Parallel Query?

Não. Você não será cobrado por nada além do que já paga pelas instâncias, pela E/S e pelo armazenamento.

P: Como o Parallel Query reduz a E/S, sua ativação reduzirá a cobrança de E/S do Aurora?

Não. O Parallel Query reduz os custos de E/S para sua consulta que são medidos na camada de armazenamento, e eles serão iguais ou maiores com o Parallel Query ativado. O seu benefício é o aumento na performance da consulta. Há dois motivos para os custos de E/S possivelmente mais altos com o Parallel Query. Primeiro, mesmo se parte dos dados de uma tabela estiver no grupo de buffers, o Parallel Query exige que todos os dados sejam varridos na camada de armazenamento, o que consome E/S. Segundo, um efeito colateral de evitar a contenção no grupo de buffers é que a execução de uma consulta com Parallel Query não atualiza o grupo de buffers. Como resultado, execuções consecutivas da mesma consulta com Parallel Query incorrerão o custo completo de E/S.

P: Quais versões do Amazon Aurora oferecem suporte ao Parallel Query?

O Parallel Query está disponível para o Amazon Aurora na versão compatível com o MySQL 5.6, a partir da versão v1.18.0. Pretendemos estender o Parallel Query para o Aurora com compatibilidade com o MySQL 5.7 e para o Aurora edição compatível com PostgreSQL.

P: O Parallel Query está disponível em todos os tipos de instância?

Não. No momento, é possível usar o Parallel Query com instâncias na família de instâncias R*.

P: O Parallel Query é compatível com todos os outros recursos do Aurora?

Não inicialmente. No momento, você somente pode ativá-lo para clusters de banco de dados que não executam os recursos do Serverless ou do Backtrack. Além disso, ele não oferece suporte a funcionalidades específicas do Aurora com compatibilidade com o MySQL 5.7.

P: Se o Parallel Query acelera as consultas com apenas algumas raras perdas de performance, devo simplesmente ativá-lo sempre?

Não. Embora esperemos que o Parallel Query melhore a latência das consultas na maioria dos casos, você poderá incorrer em custos de E/S mais altos. Recomendamos que você teste completamente a workload com o recurso habilitado e desabilitado. Quando estiver convencido de que o Parallel Query é a opção correta, poderá deixar que o otimizador decida automaticamente quais consultas o utilizarão. Quando o otimizador não tomar a decisão ideal, o que deve ocorrer raramente, você poderá substituir a configuração.

P: O Parallel Query do Aurora pode substituir um data warehouse?

O Parallel Query do Aurora não é um data warehouse e não oferece a funcionalidade normalmente encontrada nesses sistemas. Ele foi projetado para acelerar a performance de consultas em um banco de dados relacional e é adequado para casos de uso, como análises operacionais, quando você precisa executar consultas analíticas rápidas em dados atualizados em seu banco de dados.

Amazon DevOps Guru for RDS

P: O que é o Amazon DevOps Guru for RDS?

O Amazon DevOps Guru for RDS é uma nova funcionalidade com a tecnologia de ML para o Amazon RDS desenvolvida para detectar e diagnosticar automaticamente problemas operacionais e de performance do banco de dados, permitindo que você resolva gargalos em minutos em vez de dias. O Amazon DevOps Guru for RDS é um recurso do Amazon DevOps Guru que detecta problemas operacionais e de performance em todos os mecanismos do Amazon RDS e em dezenas de outros tipos de recurso. O DevOps Guru for RDS expande as capacidades do DevOps Guru para detectar, diagnosticar e remediar vários problemas relacionados ao banco de dados no Amazon RDS (como utilização excessiva de recursos e comportamento indevido de consultas SQL). Quando ocorre um problema, o Amazon DevOps Guru for RDS é desenvolvido para notificar desenvolvedores e engenheiros de DevOps imediatamente e fornecer informações de diagnóstico, detalhes sobre a extensão desse problema e recomendações de remediação inteligentes para ajudar os clientes a resolver rapidamente gargalos de performance e problemas operacionais relacionados ao banco de dados.

Q: Por que eu devo usar o DevOps Guru for RDS?

O Amazon DevOps Guru for RDS foi projetado para remover o esforço manual e reduzir o tempo (de horas e dias para minutos) para detectar e resolver gargalos de performance difíceis de encontrar na workload de banco de dados relacional. Você pode habilitar o DevOps Guru for RDS para cada banco de dados Amazon Aurora e ele detectará automaticamente problemas de performance em suas workloads, enviará alertas sobre cada problema, explicará as descobertas e recomendará ações para resolvê-los. O DevOps Guru for RDS ajuda a tornar a administração de banco de dados mais acessível para não especialistas e auxilia especialistas em banco de dados para que eles possam gerenciar ainda mais bancos de dados.

Q: Como funciona o Amazon DevOps Guru for RDS?

O Amazon DevOps Guru for RDS usa ML para analisar dados de telemetria coletados pelo Amazon RDS Performance Insights (PI). O DevOps Guru for RDS não usa nenhum dos seus dados armazenados no banco de dados na análise. O PI mede a carga do banco de dados, uma métrica que caracteriza como uma aplicação passa o tempo no banco de dados e as métricas selecionadas geradas pelo banco de dados, como variáveis de status do servidor no MySQL e tabelas pg_stat no PostgreSQL.

Q: Como posso começar a usar o Amazon DevOps Guru for RDS?

Para começar a usar o DevOps Guru for RDS, certifique-se de que o Performance Insights esteja ativado no console do RDS. Em seguida, basta ativar o DevOps Guru para os bancos de dados do Amazon Aurora. Com o DevOps Guru, você pode escolher seu limite de cobertura de análise como toda a sua conta da AWS, prescrever as pilhas específicas do AWS CloudFormation que deseja que o DevOps Guru analise ou usar as etiquetas da AWS para criar o agrupamento de recursos que deseja que o DevOps Guru analise.

Q: Que tipos de problema o Amazon DevOps Guru for RDS detecta?

O Amazon DevOps Guru for RDS ajuda a identificar uma ampla variedade de problemas de performance que podem afetar a qualidade do serviço da aplicação, como empilhamento de bloqueios, tempestades de conexão, regressões de SQL, contenção de CPU e E/S e problemas de memória.

Q: Qual a diferença entre o DevOps Guru for RDS e Amazon RDS Performance Insights?

O Amazon RDS Performance Insights é um recurso de ajuste e monitoramento de performance de banco de dados que coleta e visualiza as métricas de performance do banco de dados do Amazon RDS, ajudando na avaliação rápida da carga em seu banco de dados e a determinar quando e onde agir. O Amazon DevOps Guru for RDS foi projetado para monitorar essas métricas, detectar quando seu banco de dados enfrenta problemas de performance, analisar as métricas e, em seguida, dizer o que está errado e o que deve ser feito.

Saiba mais sobre os preços do Amazon Aurora

Acesse a página de definição de preço