Armazenamento e confiabilidade do Amazon Aurora

A seguir, saiba mais sobre o subsistema de armazenamento do Aurora. O Aurora usa uma arquitetura de armazenamento distribuído e compartilhado que é um fator importante em termos de performance, escalabilidade e confiabilidade para clusters do Aurora.

Visão geral do armazenamento do Amazon Aurora

Os dados do Aurora são armazenados no volume de cluster, que é um volume virtual único que usa Solid State Drives (SSDs – Unidades de estado sólido). Um volume de cluster consiste em cópias dos dados em várias zonas de disponibilidade em uma única região da AWS. Como os dados são replicados automaticamente nas Zonas de disponibilidade, seus dados são resilientes, havendo menos possibilidade de perda de dados. Essa replicação também garante que o banco de dados esteja disponível durante um failover. Ele faz isso porque as cópias de dados já existem nas outras zonas de disponibilidade e continuam atendendo a solicitações de dados para as instâncias de banco de dados no cluster de banco de dados. A quantidade de replicação independe do número de instâncias de banco de dados no cluster.

O Aurora usa armazenamento local separado para arquivos temporários não persistentes. Isso inclui arquivos que são usados para fins como classificar grandes conjuntos de dados durante o processamento de consultas e criação de índices. Para obter mais informações, consulte Limites de armazenamento temporário para o Aurora MySQL e Limites de armazenamento temporário para o Aurora PostgreSQL.

O que o volume de cluster contém

O volume de cluster do Aurora contém todos os dados do usuário, os objetos de esquema e os metadados internos como as tabelas do sistema e o log binário. Por exemplo, o Aurora armazena todas as tabelas, os índices, os Binary Large Objects (BLOBs – Grandes objetos binários), os procedimentos armazenados etc. para um cluster do Aurora no volume do cluster.

A arquitetura de armazenamento compartilhado do Aurora torna os dados independentes das instâncias de banco de dados no cluster. Por exemplo, adicione uma instância de banco de dados rapidamente porque o Aurora não cria uma nova cópia dos dados da tabela. Em vez disso, a instância de banco de dados se conecta ao volume compartilhado que já contém todos os dados. Remova uma instância de banco de dados de um cluster sem remover dados subjacentes do cluster. O Aurora só remove os dados quando você exclui todo o cluster.

Configurações de armazenamento para clusters de banco de dados do Amazon Aurora

O Amazon Aurora tem duas configurações de armazenamento do cluster de banco de dados:

• Aurora I/O-Optimized: melhor preço/performance e previsibilidade para aplicações com uso intenso de E/S. Você paga somente pelo uso e armazenamento de seus clusters de banco de dados, sem custos adicionais pelas operações de E/S de leitura e gravação.

  O Aurora I/O-Optimized é a melhor opção quando seus gastos com E/S são 25% ou mais do gasto total com o banco de dados do Aurora.

  Você pode escolher Aurora I/O-Optimized ao criar ou modificar um cluster de banco de dados com uma versão de mecanismo de banco de dados compatível com a configuração do cluster do Aurora I/O-Optimized. É possível mudar do Aurora I/O-Optimized para o Aurora Standard a qualquer momento.

• Aurora Standard: preços econômicos para muitas aplicações com uso moderado de E/S. Além do uso e do armazenamento dos clusters de banco de dados, você também paga uma taxa padrão por um milhão de solicitações para operações de E/S.

  O Aurora Standard é a melhor opção quando seus gastos com E/S são inferiores a 25% dos gastos totais com o banco de dados do Aurora.

  Você pode mudar de Aurora Standard para Aurora I/O-Optimized uma vez a cada 30 dias. Não há tempo de inatividade ao mudar de Aurora Standard para Aurora I/O-Optimized ou de Aurora I/O-Optimized para Aurora Standard.

Para obter mais informações sobre Região da AWS e compatibilidade de versão, consulte Configurações de armazenamento do cluster do Aurora.

Para obter mais informações sobre o preço referente às configurações de armazenamento do Amazon Aurora, consulte Preços do Amazon Aurora.

Para receber informações sobre como escolher a configuração de armazenamento ao criar um cluster de banco de dados, consulte Criar um cluster de banco de dados. Para receber informações sobre como modificar a configuração de armazenamento de um cluster de banco de dados, consulte Configurações do Amazon Aurora.

Como o armazenamento do Aurora redimensiona automaticamente

Os volumes de cluster do Aurora crescem automaticamente à medida em que aumenta a quantidade de dados em seu banco de dados. O tamanho máximo de um volume de cluster do Aurora é de 128 tebibytes (TiB) ou 64 TiB, dependendo da versão do mecanismo de banco de dados. Para obter detalhes sobre o tamanho máximo de uma versão específica, consulte Limites de tamanho do Amazon Aurora. Essa escalabilidade automática de armazenamento é combinada com um subsistema de armazenamento altamente distribuído e de alta performance. Isso faz do Aurora uma boa escolha para seus dados corporativos importantes quando seus principais objetivos são confiabilidade e alta disponibilidade.

Para exibir o status do volume, consulte Exibir o status do volume para um cluster de banco de dados Aurora MySQL ou Exibir o status do volume para um cluster de bancos de dados Aurora PostgreSQL. Para formas de equilibrar os custos de armazenamento com outras prioridades, Escalabilidade de armazenamento descreve como monitorar as métricas do Amazon Aurora AuroraVolumeBytesLeftTotal e VolumeBytesUsed em CloudWatch.

Quando os dados do Aurora são removidos, o espaço alocado para esses dados é liberado. Exemplos de remoção de dados incluem descartar ou truncar uma tabela. Essa redução automática no uso do armazenamento ajuda a minimizar as cobranças de armazenamento.

nota

Os limites de armazenamento e o comportamento de redimensionamento dinâmico discutidos aqui se aplicam a tabelas persistentes e outros dados armazenados no volume do cluster.

Para Aurora PostgreSQL, os dados das tabelas temporárias são armazenados na instância de banco de dados local.

Para Aurora MySQL versão 2, os dados da tabela temporária são armazenados por padrão no volume do cluster para instâncias gravadoras e no armazenamento local para instâncias leitoras. Para obter mais informações, consulte Mecanismo de armazenamento para tabelas temporárias em disco.

Para Aurora MySQL versão 3, os dados da tabela temporária são armazenados na instância de banco de dados local ou no volume do cluster. Para obter mais informações, consulte Novo comportamento de tabela temporária no Aurora MySQL versão 3.

O tamanho máximo das tabelas temporárias que residem no armazenamento local é limitado pelo tamanho máximo do armazenamento local da instância de banco de dados. O tamanho do armazenamento local depende da classe de instância usada. Para obter mais informações, consulte Limites de armazenamento temporário para o Aurora MySQL e Limites de armazenamento temporário para o Aurora PostgreSQL.

Alguns recursos de armazenamento, como o tamanho máximo de um volume de cluster e o redimensionamento automático quando os dados são removidos, dependem da versão do Aurora do cluster. Para obter mais informações, consulte Escalabilidade de armazenamento. Também é possível aprender como evitar problemas de armazenamento e como monitorar o armazenamento alocado e o espaço livre no cluster.

Como o armazenamento de dados do Aurora é faturado

Embora um volume de cluster do Aurora possa aumentar até 128 tebibytes (TiB), você só é cobrado pelo espaço que usa em um volume de cluster do Aurora. Em versões anteriores do Aurora, o volume do cluster podia reutilizar o espaço liberado quando você removia dados, mas o espaço de armazenamento alocado nunca diminuía. Agora, quando os dados do Aurora são removidos, como ao excluir uma tabela ou banco de dados, o espaço total alocado diminui em uma quantidade equivalente. Assim, é possível reduzir as cobranças de armazenamento excluindo tabelas, índices, bancos de dados etc., que não são mais necessários.

dica

Para versões anteriores sem o recurso de redimensionamento dinâmico, redefinir o uso de armazenamento para um cluster envolvia fazer um despejo lógico e restaurar para um novo cluster. Essa operação pode levar muito tempo para um volume substancial de dados. Se você encontrar essa situação, considere atualizar seu cluster para uma versão que ofereça suporte ao redimensionamento dinâmico de volume.

Para obter informações sobre quais versões do Aurora oferecem suporte ao redimensionamento dinâmico e sobre como minimizar as cobranças de armazenamento monitorando o uso do armazenamento para seu cluster, consulte Escalabilidade de armazenamento. Para obter informações sobre faturamento de armazenamento de backup do Aurora, consulte Noções básicas do uso do armazenamento de backup do Amazon Aurora. Para obter informações da definição de preço sobre o armazenamento de dados do Aurora, consulte Preços do Amazon RDS para Aurora.

Confiabilidade do Amazon Aurora

O Aurora foi projetado para ser confiável, durável e tolerante a falhas. É possível arquitetar o cluster de banco de dados do Aurora para aumentar a disponibilidade por meio de ações, como adicionar réplicas do Aurora e instalá-las em zonas de disponibilidade diferentes. Além disso, o Aurora inclui vários recursos automáticos que fazem dele uma solução de banco de dados confiável.

Tópicos

• Reparo automático de armazenamento
• Cache de página perdurável
• Recuperação após reinicializações não planejadas

Reparo automático de armazenamento

Como o Aurora mantém várias cópias de seus dados em três zonas de disponibilidade, a chance de perder dados devido a uma falha no disco é muito baixa. O Aurora detecta automaticamente as falhas nos volumes de disco que compõem o volume do cluster. Quando um segmento de um volume de disco falha, o Aurora repara imediatamente o segmento. Quando o Aurora repara o segmento do disco, ele usa os dados nos outros volumes que compõem o volume do cluster para garantir que os dados no segmento reparado sejam atuais. Como resultado, o Aurora evita a perda de dados e reduz a necessidade de executar uma restauração pontual para recuperação de uma falha de disco.

Cache de página perdurável

No Aurora, o cache de página de cada instância de banco de dados é gerenciado em um processo separado do banco de dados, permitindo que o cache de página perdure independentemente do banco de dados. (O cache de página também é chamado de grupo de buffer do InnoDB no Aurora MySQL e cache de buffer no Aurora PostgreSQL.)

No evento improvável de uma falha no banco de dados, o cache de página permanece na memória, o que mantém as páginas de dados atuais “em atividade” no cache de página quando o banco de dados é reiniciado. Isso gera um ganho de performance, evitando a necessidade de executar operações de E/S de leitura para “ativar” o cache de página.

No caso do Aurora MySQL, o comportamento do cache de página na reinicialização e no failover é o seguinte:

• Versões anteriores a 2.10: quando a instância de banco de dados do gravador é reinicializada, o cache de página na instância do gravador perdura, mas as instâncias de banco de dados do leitor perdem seus caches de página.

• Versão 2.10 e posteriores: você pode reinicializar a instância do gravador sem reinicializar as instâncias do leitor.

  • Se as instâncias do leitor não forem reinicializadas simultaneamente com a instância do gravador, elas não perderão os caches de página.

  • Se as instâncias do leitor não forem reinicializadas simultaneamente com a instância do gravador, elas perderão os caches de página.

• Quando uma instância do leitor é reinicializada, os caches de página no gravador e as instâncias do leitor perduram.

• Quando ocorre uma falha no cluster de banco de dados, o efeito é semelhante a quando uma instância do gravador é reinicializada. Na nova instância do gravador (anteriormente, a instância do leitor), o cache de página perdura, mas não ocorre o mesmo na instância do leitor (anteriormente, a instância do gravador).

No caso do Aurora PostgreSQL, é possível usar o gerenciamento de cache de cluster para preservar o cache de página de uma instância de leitor designada que se torna a instância do gravador após o failover. Para obter mais informações, consulte Recuperação rápida após failover com o gerenciamento de cache do cluster para o Aurora PostgreSQL.

Recuperação após reinicializações não planejadas

O Aurora é projetado para se recuperar de uma reinicialização não planejada quase instantaneamente e continuar a fornecer os dados de sua aplicação sem o log binário. O Aurora se recupera de forma assíncrona em threads paralelos, de maneira que o banco de dados seja aberto e fique disponível imediatamente após a reinicialização não planejada.

Para obter mais informações, consulte Tolerância a falhas para um cluster de banco de dados do Aurora e Otimizações para reduzir o tempo de reinicialização do banco de dados.

Veja a seguir, considerações para log binário e recuperação após reinicializações não planejadas no Aurora MySQL:

• Ativar o log binário no Aurora afeta diretamente o tempo de recuperação após uma reinicialização não planejada, porque isso força a instância de banco de dados a executar uma recuperação de log binário.

• O tipo de log binário usado afeta o tamanho e a eficiência dele. Para a mesma quantidade de atividade do banco de dados, alguns formatos oferecem mais informações que outros nos logs binários. As seguintes configurações para o parâmetro binlog_format resultam em diferentes quantidades de dados de log:

  • ROW – a maior quantidade de dados de log

  • STATEMENT – a menor quantidade de dados de log

  • MIXED – uma quantidade moderada de dados de log, que geralmente fornece a melhor combinação de integridade e performance dos dados

  A quantidade de dados do log binário afeta o tempo de recuperação. Se houver mais dados registrados nos logs binários, a instância de banco de dados processará mais dados durante a recuperação, aumentando o tempo necessário.

• Para reduzir a sobrecarga computacional e melhorar os tempos de recuperação com o registro em log binário, é possível usar o log binário aprimorado. O log binário aprimorado melhora o tempo de recuperação do banco de dados em até 99%. Para obter mais informações, consulte Configurar o log binário avançado.

• O Aurora não precisa dos logs binários para replicar dados dentro de um cluster de banco de dados nem para executar a restauração de point-in-time (PITR).

• Se o log binário não for necessário para replicação externa (ou um fluxo de log binário externo), recomendamos que você defina o parâmetro binlog_format como OFF para desativá-lo. Isso reduz o tempo de recuperação.

Para obter mais informações sobre o registro em log binário e a replicação no Aurora, consulte Replicação com o Amazon Aurora. Para obter mais informações sobre as implicações dos diferentes tipos de replicação do MySQL, consulte Vantagens e desvantagens da replicação baseada em instrução e baseada em linha na documentação do MySQL.