Geral

O que é o Amazon Aurora?

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

O Aurora oferece um sistema de armazenamento distribuído, tolerante a falhas e com autorrecuperação que é independente dos recursos de computação e aumenta a escala verticalmente de maneira automática para até 128 TiB por instância de banco de dados. Ele oferece alta performance e disponibilidade com até 15 réplicas de leitura de baixa latência, recuperação a 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, aplicação de patch e backups, ao mesmo tempo que oferece segurança, disponibilidade e confiabilidade de bancos de dados comerciais por uma fração do custo.

O Amazon Aurora é compatível com 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. Isso significa que você pode facilmente migrar bancos de dados MySQL para o e do Aurora usando ferramentas de importação/exportação padrão ou snapshots. Isso também significa que a maior parte do código, aplicações, drivers e ferramentas que você já usa com bancos de dados MySQL hoje pode ser usada com o Aurora com pouca ou nenhuma alteração. Isso torna mais fácil mover aplicações entre os dois mecanismos.

É possível ver as informações atuais sobre a compatibilidade com MySQL do lançamento do Amazon Aurora na documentação.

O Amazon Aurora é 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. Assim, você pode migrar facilmente bancos de dados PostgreSQL de e para o Aurora usando ferramentas padrão de importação/exportação ou snapshots. Isso também significa que a maior parte do código, aplicações, drivers e ferramentas que você já usa com bancos de dados PostgreSQL atualmente pode ser usada com o Aurora com pouca ou nenhuma alteração.

É possível ver as informações atuais sobre a compatibilidade com PostgreSQL do lançamento do Amazon Aurora na documentação.

A Amazon oferece suporte total ao Aurora edição compatível com PostgreSQL e a todas as extensões disponibilizadas com o Aurora. Se você precisar de suporte para o Aurora edição compatível com PostgreSQL, entre em contato com o AWS Support. Se você tiver uma conta ativa do AWS Premium Support, basta entrar em contato com o AWS Premium Support para tratar de questões específicas sobre o Amazon Aurora.

Como começar a utilizar o Amazon Aurora?

Para testar o Amazon Aurora, faça login no Console de Gerenciamento da AWS, selecione RDS na categoria Database (Banco de dados) e escolha o Amazon Aurora como seu mecanismo de banco de dados. Para obter orientações detalhadas e recursos, confira a nossa página Conceitos básicos do Amazon Aurora.

Quanto custa o Amazon Aurora?

Para o Aurora provisionado, é possível escolher On-Demand Instances (Instâncias sob demanda) e pagar seu banco de dados por hora, sem compromissos de longo prazo ou custos iniciais, ou escolher Reserved Instances (Instâncias reservadas) para economizar ainda mais. Se preferir, o Aurora Sem Servidor inicia, encerra e escala a capacidade automaticamente de acordo com as necessidades de sua aplicação, e você paga apenas pela capacidade consumida.

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

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 efetivo de armazenamento será três ou seis vezes o valor que aparece na página de preço?

Não. A replicação do Amazon Aurora está incluída no preço. A sua cobrança é feita com base no armazenamento consumido pelo seu banco de dados na camada de do banco de dados, e não pelo armazenamento consumido na camada de armazenamento virtualizado do Amazon Aurora.

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

É possível ver a disponibilidade do Amazon Aurora por região aqui.

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

Se quiser migrar do MySQL para o Amazon Aurora (e vice-versa), há várias opções:

  • Você pode usar o utilitário padrão mysqldump para exportar 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 do DB snapshot do Amazon RDS para migrar um DB snapshot do Amazon RDS para MySQL para o Amazon Aurora usando o Console de Gerenciamento da AWS.

Para a maioria dos clientes, a migração para o Aurora é 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 Best Practices for Migrating MySQL Databases to Amazon Aurora (Práticas recomendadas para a migração de bancos de dados MySQL para o Amazon Aurora).

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

Se quiser migrar do PostgreSQL para o Amazon Aurora (e vice-versa), há várias opções:

  • Você pode usar o utilitário padrão pg_dump para exportar 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 do DB snapshot do Amazon RDS para migrar um DB snapshot do Amazon RDS para PostgreSQL para o Amazon Aurora usando o Console de Gerenciamento da AWS.

Para a maioria dos clientes, a migração para o Aurora é concluída em menos de uma hora, embora a duração dependa do formato e do tamanho do conjunto de dados.

Para migrar bancos de dados SQL Server para o Aurora edição compatível com PostgreSQL, você pode usar o Babelfish para Aurora PostgreSQL. Suas aplicações funcionarão sem nenhuma alteração. Consulte a documentação do Babelfish para obter mais informações.

O Amazon Aurora faz parte 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 sobre preços.
Para testar o Amazon Aurora, faça login no Console de Gerenciamento da AWS, selecione RDS na categoria Database (Banco de dados) e escolha o Amazon Aurora como seu mecanismo de banco de dados.

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 unidade de estado sólido (SSD). 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 do banco de dados que não estão presentes na memória no cache:

  • Se o seu tráfego de consultas puder ser totalmente atendido pela memória ou pelo cache, você não receberá a cobrança pela recuperação de 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 repetição no Aurora edição compatível com MySQL ou os registros de log de gravação antecipada 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 a sua instância do Aurora está consumindo verificando o Console de Gerenciamento da AWS. Para localizar o seu consumo de E/S, consulte a seção Amazon RDS do console, pesquise na sua 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.

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

Não, o Amazon Aurora funcionará com os drivers de banco de dados padrão do PostgreSQL.

Performance

O que representa uma “performance cinco vezes maior que a do MySQL”?

O Amazon Aurora oferece aumentos consideráveis de performance em relação ao MySQL, integrando totalmente o mecanismo de banco de dados com uma camada de armazenamento virtualizada baseada em 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 parâmetro de comparação e sobre como replicá-lo no Amazon Aurora MySQL-Compatible Edition Performance Benchmarking Guide (Guia de benchmarking de performance do Amazon Aurora edição compatível com MySQL).

O que representa uma “performance três vezes maior que a do PostgreSQL”?

O Amazon Aurora oferece aumentos consideráveis de performance em relação ao PostgreSQL, integrando totalmente o mecanismo de banco de dados com uma camada de armazenamento virtualizada baseada em 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 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 parâmetro de comparação e sobre como replicá-lo no Amazon Aurora PostgreSQL-Compatible Edition Performance Benchmarking Guide (Guia de benchmarking de performance do Amazon Aurora edição compatível com PostgreSQL).

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

O Amazon Aurora é projetado para ser compatível com o MySQL, de maneira que as aplicações e ferramentas existentes do MySQL 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 throughput da sua workload no Amazon Aurora, recomendamos que você desenvolva suas aplicações para gerarem um grande número de consultas e transações simultâneas.

Como posso otimizar a minha workload de 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, de maneira que as aplicações e ferramentas existentes do PostgreSQL possam ser executadas sem a necessidade de 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 da sua workload no Amazon Aurora, recomendamos que você desenvolva suas aplicações para gerarem um grande número de consultas e transações simultâneas.

Hardware e escalabilidade

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

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

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

Há duas formas de escalar os recursos de computação associados à instância de banco de dados do Amazon Aurora: pelo Aurora Sem Servidor ou por meio de um ajuste manual.

Você pode usar o Aurora Sem Servidor, uma configuração de escalabilidade automática sob demanda para o Amazon Aurora, para escalar recursos de computação de banco de dados com base em demandas de aplicações. 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 Aurora Serverless User Guide (Guia do usuário do Aurora Sem Servidor).

Também é possível escalar manualmente os seus recursos de computação associados ao seu 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 sua janela de manutenção especificada. Alternativamente, você pode usar o sinalizador "Apply Immediately" (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

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

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

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

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

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

O Amazon Aurora mantém automaticamente seis cópias dos seus 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 fazer a restauração utilizando um DB snapshot ou fazer uma operação de restauração a um ponto anterior no tempo para uma nova instância. Observe que o último momento restaurável para uma operação de restauração a um ponto anterior no tempo pode ser de até cinco minutos atrás.

O que acontecerá com meus backups e DB snapshots automatizados se eu excluir minha instância de banco de dados?

Você pode escolher criar um DB snapshot final ao excluir a sua instância de banco de dados. Se o fizer, poderá usar o DB snapshot para restaurar a instância de banco de dados excluída posteriormente. O Amazon Aurora retém esse DB snapshot final criado pelo usuário junto com todos os outros DB snapshots criados manualmente após a exclusão da instância de banco de dados. Apenas DB snapshots são retidos após a exclusão da instância de banco de dados (ou seja, os backups automáticos criados para uma restauração a um ponto anterior no tempo não são mantidos).

Posso compartilhar os 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.

Eu receberei cobrança 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 os preços do Aurora.

Posso compartilhar snapshots de maneira automática?

Nós não oferecemos suporte ao compartilhamento automático de DB snapshots. Para compartilhar um snapshot, será necessário criar manualmente uma cópia do snapshot e, em seguida, compartilhá-la.

Com quantas contas posso compartilhar snapshots?

É possível 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.

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.

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.

Posso compartilhar um snapshot criptografado do Aurora?

Sim, você pode compartilhar snapshots criptografados do Aurora.

Alta disponibilidade e replicação

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 autorrecuperação. Os blocos e discos de dados são verificados de maneira contínua em busca de erros e, então, são automaticamente corrigidos.

Como o Aurora melhora o tempo de recuperação após uma falha de banco de dados?

Diferente de outros bancos de dados, depois de uma falha, o Amazon Aurora não precisa reproduzir o log de repetição 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 quedas de energia.

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 oferecem suporte a réplicas do Amazon Aurora, que compartilham o mesmo volume subjacente da instância primária na mesma região da AWS. As atualizações feitas pela instância primária 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 logs binários do MySQL. Nas réplicas de leitura do MySQL, os dados da sua instância primária 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 do seu aplicativo:

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 Global Database para obter uma replicação física muito mais rápida entre clusters do Aurora em diferentes regiões. E, para a replicação entre bancos de dados do Aurora e externos ao Aurora, edições compatíveis com MySQL (mesmo fora da AWS), você pode configurar a sua própria replicação autogerenciada de logs binários.

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 a replicação lógica nativa em cada mecanismo de banco de dados (log binário para slots de replicação de MySQL e PostgreSQL para PostgreSQL), de maneira que você possa replicar para bancos de dados Aurora e externos ao 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 de log binário 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 primária no cluster e as réplicas do Aurora no cluster, geralmente, apresentam um atraso de dez milissegundos em relação à primária.

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

Sim, você pode promover a sua réplica entre regiões como a nova instância primária 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.

Posso priorizar algumas réplicas como destinos de failover em relação a 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 Amazon Aurora User Guide (Guia do usuário do Amazon Aurora).

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

Sim, é possível 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.

Posso evitar que determinadas réplicas sejam promovidas como a instância primária?

É possível atribuir camadas de prioridade mais baixas a réplicas que você não deseja promover como a instância primária. No entanto, se as réplicas de prioridade mais alta no cluster não estiverem íntegras ou disponíveis por alguma razão, o Amazon RDS promoverá a réplica de prioridade mais baixa.

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.

O que acontece durante o failover e quanto tempo o processo demora?

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 primária. 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 workloads de leitura/gravação.

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

O Amazon Aurora detectará automaticamente um problema afetando a sua instância primária 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 endpoint de leitor do cluster 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ó primário anterior seja recuperado como uma réplica.

Qual é a defasagem entre a instância primária e as réplicas?

Como as réplicas do Amazon Aurora compartilham o mesmo volume de dados que a instância primária na mesma região da AWS, praticamente não há atraso na replicação. Normalmente, observamos defasagens de dezenas de milissegundos.

Para a replicação entre regiões, o atraso de replicação logica baseada em logs binários 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 que usam o processo de replicação física do Amazon Aurora Global Database terão uma defasagem típica de menos de um segundo.

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 logs binários 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 5.7 compatível com MySQL, considere configurar a replicação de logs binários baseada em GTID. Isso oferecerá consistência total para que a replicação não perca transações ou gere conflitos, mesmo após o failover ou um tempo de inatividade.

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.

Como posso criar um Amazon Aurora Global Database?

Você pode criar um Aurora Global Database com apenas alguns cliques no console do Amazon RDS. Alternativamente, você pode usar o kit de desenvolvimento de software (SDK) ou a AWS Command Line Interface (CLI) . Você precisa provisionar pelo menos uma instância por região no seu Amazon Aurora Global Database.

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.

Se eu usar o Amazon Aurora Global Database, também poderei usar a replicação lógica (logs binários) 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.

O Aurora fará o failover para uma região secundária do Amazon Aurora Global Database de maneira automática?

Não. Se a região primária ficar indisponível, você poderá remover uma região secundária manualmente 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.

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 horizontalmente 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.

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

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

Segurança

Posso usar o Amazon Aurora na 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 a 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.

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 que você gerencia por meio do 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 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 Amazon RDS User's Guide (Guia do usuário do Amazon RDS).

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

No momento, não há suporte para criptografia de uma instância do Aurora não criptografada. 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 habilitada e migre seus dados para ela.

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 fornece aos seus dados uma camada adicional de segurança. Instruções detalhadas sobre como conectar-se ao seu banco de dados do Amazon Aurora são fornecidas no Amazon Aurora Connectivity Guide (Guia de conectividade do Amazon Aurora).

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 Lei de portabilidade e responsabilidade de seguro saúde (HIPAA). Logo, podem ser utilizadas para o desenvolvimento de aplicações em conformidade com a HIPAA, e para armazenar informações relacionadas à saúde, incluindo informações de saúde protegidas (PHI), mediante a assinatura de um Acordo de Associação Comercial (BAA) 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 abrangidas pelo seu BAA. Para obter mais informações sobre o desenvolvimento de aplicações compatíveis com a AWS, consulte Healthcare Providers & Insurers in the Cloud (Provedores e seguradoras de serviços de saúde na nuvem).

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

No momento, essa lista de CVEs pode ser encontrada em Amazon Aurora Security Updates (Atualizações de segurança do Amazon Aurora).

Tecnologia sem servidor

O que é o Amazon Aurora Sem Servidor?

O Aurora Sem Servidor é uma configuração com escalabilidade automática e sob demanda do 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 Sem Servidor e comece a usá-o com apenas alguns cliques no Console de Gerenciamento do Amazon RDS.

Qual é a diferença entre o Aurora Sem Servidor v2 e v1?

O Aurora Sem Servidor v2 oferece suporte a todo tipo de workload de banco de dados, desde ambientes de desenvolvimento e teste, sites e aplicações com workloads pouco frequentes, intermitentes ou imprevisíveis, até aplicações mais exigentes e essenciais aos negócios que exigem uma escala elevada e alta disponibilidade. Ele reduz a escala horizontalmente 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 escala 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 Sem Servidor v1 é uma opção relativamente simples e econômica para workloads pouco frequentes, intermitentes ou imprevisíveis. Ele é inicializado automaticamente, escala a capacidade computacional para corresponder ao uso de sua aplicação e é desligado quando não está em uso. Para saber mais, acesse o Guia do usuário do Aurora.

Quais recursos do Aurora são compatíveis com o Aurora Sem Servidor v2?

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

Posso começar a usar o Aurora Sem Servidor v2 com meu cluster de banco de dados do Aurora existente?

Sim, você pode começar a usar o Aurora Sem Servidor 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 Sem Servidor v2.

Posso migrar do Aurora Sem Servidor v1 para o Aurora Sem Servidor v2?

Sim, você pode migrar do Aurora Sem Servidor v1 para o Aurora Sem Servidor v2. Para saber mais, consulte o Guia do usuário do Aurora.

Quais versões do Amazon Aurora são compatíveis com o Aurora Sem Servidor?

Posso migrar um cluster de banco de dados do Aurora para o Aurora Sem Servidor?

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

Como faço para me conectar a um cluster de banco de dados do Aurora Sem Servidor?

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

Posso definir explicitamente a capacidade de um cluster do Aurora Sem Servidor?

Embora o Aurora Sem Servidor escale automaticamente de acordo com a workload ativa do banco de dados, em alguns casos, pode ser que a capacidade não escale com velocidade suficiente para atender a uma mudança repentina 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.

Por que o meu cluster de banco de dados do Aurora Sem Servidor não escala automaticamente?

Após o início de uma operação de escalabilidade, o Aurora Sem Servidor tenta encontrar um ponto de alteração de escala, que é um momento no qual 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, pode ser que o Aurora Sem Servidor não encontre um ponto de alteração de escala.

Como é a cobrança pelo Aurora Sem Servidor?

No Aurora Sem Servidor, 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 de tecnologia sem servidor são os mesmos. Acesse a Página de preço do Aurora para obter informações atualizadas sobre preços e disponibilidade por região da AWS.

Parallel Query

O que é o Amazon Aurora Parallel Query?

O Amazon Aurora Parallel Query refere-se à 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.

Qual é o caso de uso pretendido?

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

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, uma vez que 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 throughput de transações juntamente com consultas analíticas simultâneas.

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 aumentar a escala horizontalmente do processamento de mais de 200 funções, associações de igualdade (equijoins) e projeções de SQL.

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.

Existe alguma chance de a performance ser mais lenta?

Sim, mas esperamos que esses casos sejam raros.

Quais mudanças são necessárias em uma consulta para aproveitar 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.

Como eu ativo ou desativo o recurso Parallel Query?

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

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

Não. Você não receberá cobrança referente a nada além do que já paga pelas instâncias, pela E/S e pelo armazenamento.

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

Não. Os custos de E/S do Parallel Query para a sua consulta são calculados na camada de armazenamento, e serão iguais ou maiores com o Parallel Query ativado. O seu benefício é o aumento na performance de consultas.

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. Consequentemente, execuções consecutivas da mesma consulta do Parallel Query incorrerão o custo completo de E/S.

Saiba mais sobre o Parallel Query na documentação.

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 da família de instâncias R*.

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

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

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. Assim que você se convencer do potencial do Parallel Query, deixe que o otimizador de consultas decida automaticamente quais consultas utilizarão o Parallel Query. Em raras ocasiões em que o otimizador não tomar a decisão ideal, você poderá substituir a configuração.

O Parallel Query do Aurora pode substituir um data warehouse?

O Aurora Parallel Query não é um data warehouse e não oferece a funcionalidade que costuma ser encontrada nesses sistemas. Ele foi projetado para acelerar a performance de consultas em seu 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.

Para obter um data warehouse de nuvem na escala de exabytes, considere o Amazon Redshift.

Amazon DevOps Guru para RDS

O que é o Amazon DevOps Guru para RDS?

O Amazon DevOps Guru para RDS é uma nova funcionalidade com a tecnologia de ML para o Amazon RDS (o que inclui o Amazon Aurora) desenvolvida para detectar e diagnosticar automaticamente problemas operacionais e de performance do banco de dados, permitindo que você solucione problemas em minutos em vez de dias.

O Amazon DevOps Guru para 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 para RDS amplia as capacidades do DevOps Guru para detectar, diagnosticar e remediar vários problemas relacionados a bancos de dados no Amazon RDS (como, por exemplo, a utilização excessiva de recursos e o comportamento indevido de determinadas consultas SQL).

Quando ocorre um problema, o Amazon DevOps Guru para RDS é projetado 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.

Por que devo usar o DevOps Guru para RDS?

O Amazon DevOps Guru para RDS foi projetado para eliminar 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 para RDS para cada banco de dados do 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 solucioná-los.
O DevOps Guru para RDS ajuda a tornar a administração de banco de dados mais acessível para usuários comuns e auxilia especialistas em banco de dados para que possam gerenciar ainda mais bancos de dados.

Como funciona o Amazon DevOps Guru para RDS?

O Amazon DevOps Guru para RDS usa ML para analisar dados de telemetria coletados pelo recurso Insights de Performance do Amazon RDS (PI). O DevOps Guru para RDS não usa nenhum dos seus dados armazenados no banco de dados em sua 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.

Como posso começar a usar o Amazon DevOps Guru para RDS?

Para começar a usar o DevOps Guru para RDS, certifique-se de que o recurso Insights de Performance esteja habilitado no console do RDS. Em seguida, basta habilitar o DevOps Guru para os seus 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.

Que tipos de problema o Amazon DevOps Guru para RDS detecta?

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

Qual é a diferença entre o DevOps Guru para RDS e o Insights de Performance do Amazon RDS?

O Insights de Performance do Amazon RDS é um recurso de ajuste e monitoramento de performance que coleta e visualiza métricas de performance de bancos de dados do Amazon RDS, ajudando você a avaliar rapidamente a carga do seu banco de dados, além de determinar quando e onde agir. O Amazon DevOps Guru para 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 o preço do Amazon Aurora

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