Armazenamento e confiabilidade do Amazon Aurora - Amazon Aurora

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

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. Um volume do cluster do Aurora pode aumentar até o tamanho máximo de 128 tebibytes (TiB). 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 do Aurora MySQL ou Exibir o status do volume para um cluster de banco de dados do 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. Os dados para tabelas temporárias são armazenados na instância de banco de dados local, e seu tamanho máximo depende da classe de instância usada.

Alguns recursos de armazenamento, como o tamanho máximo de um volume de cluster e o redimensionamento automático quando os dados são excluídos, 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ê excluía dados, mas o espaço de armazenamento alocado nunca diminuía. A partir do Aurora MySQL 2.09.0 e 1.23.0 e Aurora PostgreSQL 3.3.0 e 2.6.0, quando os dados do Aurora são removidos, como descartando uma tabela ou banco de dados, o espaço alocado global diminui em uma quantidade comparável. 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 à redução de volume.

Para obter informações da definição de preço sobre o armazenamento de dados do Aurora, consulte Preços do Amazon RDS for Aurora.

Para obter informações sobre como minimizar as cobranças de armazenamento monitorando o uso do armazenamento para seu cluster, consulte Escalabilidade de armazenamento. Para obter informações da definição de preço sobre o armazenamento de dados do Aurora, consulte Preços do Amazon RDS for 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.

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.

Aquecimento de cache possível de recuperar

O Aurora "aquece" o cache do grupo de buffer quando um banco de dados é iniciado após ter sido desligado ou reiniciado mediante uma falha. Ou seja, o Aurora pré-carrega o grupo de buffer com as páginas para consultas comuns conhecidas que são armazenadas em um cache de páginas na memória. Isso gera um ganho de desempenho, eliminando a necessidade de "aquecer" o grupo de buffer do uso normal do banco de dados.

O cache de página do Aurora é gerenciado em um processo separado do banco de dados, permitindo que o cache da página sobreviva independentemente do banco de dados. No caso improvável de uma falha no banco de dados, o cache de página permanece na memória, o que garante que o grupo de buffer seja aquecido com o estado mais recente quando o banco de dados for reiniciado.

Recuperação de falha

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

Para obter mais informações sobre a recuperação de falhas, consulte Tolerância a falhas para um cluster de banco de dados do Aurora.

Veja a seguir, considerações para log binário e recuperação de falhas no Aurora MySQL:

  • Ativar o log binário no Aurora afeta diretamente o tempo de recuperação após uma falha, 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 desempenho 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.

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