As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Atenuar falhas
Ao planejar sua implementação do MemoryDB, você deve planejar para que as falhas tenham um impacto mínimo sobre a aplicação e os dados. Os tópicos nesta seção discutem as abordagens que você pode tomar para proteger seu aplicativo e dados contra falhas.
## Mitigando falhas: clusters do MemoryDB
Um cluster do MemoryDB é composto por um único nó primário no/do qual seu aplicativo pode ler e gravar e de 0 a 5 nós de réplica somente para leitura. No entanto, é altamente recomendável usar pelo menos uma réplica para alta disponibilidade. Sempre que os dados são gravados no nó primário, eles são mantidos no log de transações e atualizados de forma assíncrona nos nós de réplica.
**Quando uma réplica de leitura falha**
1. O MemoryDB detecta a réplica com falha.
1. O MemoryDB coloca o nó com falha offline.
1. O MemoryDB inicia e provisiona um nó de substituição na mesma zona de disponibilidade (Available Zone, AZ).
1. O novo nó é sincronizado com o log de transações.
Durante esse período, seu aplicativo pode continuar lendo e gravando usando os outros nós.
**Multi-AZ do MemoryDB**
Se o Multi-AZ for ativado em seus clusters do MemoryDB, uma falha primária será detectada e substituída automaticamente.
****
1. O MemoryDB detecta a falha do nó primário.
1. O MemoryDB faz o failover para uma réplica depois de garantir que ela seja consistente com o primário que falhou.
1. O MemoryDB gira uma réplica na AZ do primário com falha.
1. O novo nó é sincronizado com o log de transações.
O failover em um nó de réplica geralmente é mais rápido do que criar e provisionar um novo nó primário. Isso significa que seu aplicativo pode retomar a gravação no nó primário mais cedo.
Para obter mais informações, consulte [Minimização do tempo de inatividade no MemoryDB com Multi-AZ](autofailover.md).