# 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. **Topics** + [Reparo automático de armazenamento](#Aurora.Overview.AutoRepair) + [Cache de página perdurável](#Aurora.Overview.CacheWarming) + [Recuperação após reinicializações não planejadas](#Aurora.Overview.RestartRecovery) ## 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](AuroraPostgreSQL.cluster-cache-mgmt.md). ## 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](Concepts.AuroraHighAvailability.md#Aurora.Managing.FaultTolerance) e [Otimizações para reduzir o tempo de reinicialização do banco de dados](AuroraMySQL.MySQL80.md#ReducedRestartTime). 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 ter mais informações, consulte [Configurar o log binário avançado para Aurora MySQL](AuroraMySQL.Enhanced.binlog.md). + 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](Aurora.Replication.md). 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](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) na documentação do MySQL.