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
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:
-
É possível 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 ter 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 ter 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_formatresultam 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 ter mais informações, consulte Configurar o log binário avançado para Aurora MySQL.
-
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_formatcomoOFFpara 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
