

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

# Garantir que você tem memória suficiente para criar um snapshot do Valkey ou Redis OSS
<a name="BestPractices.BGSAVE"></a>

**Snapshots e sincronizações no Valkey 7.2 e posterior e no Redis OSS versão 2.8.22 e posterior**  
O Valkey tem suporte padrão para snapshots e sincronizações. O Redis OSS 2.8.22 apresenta um processo de salvamento sem bifurcação que permite alocar mais da sua memória ao uso do seu aplicativo sem incorrer em um maior uso de permuta durante sincronizações e salvamentos. Para obter mais informações, consulte [Como a sincronização e o backup são implementados](Replication.Redis.Versions.md).

**Snapshots e sincronizações do Redis OSS antes da versão 2.8.22**

Quando você trabalha com ElastiCache o Redis OSS, o Redis OSS chama um comando de gravação em segundo plano em vários casos:
+ Ao criar um snapshot para um backup.
+ Ao sincronizar réplicas com o primário em um grupo de replicação.
+ Ao habilitar o atributo de arquivo somente de acréscimo (AOF) para o Redis OSS.
+ Ao promover uma réplica para primária (o que causa uma primary/replica sincronização).

Sempre que o Redis OSS executa um processo de gravação em segundo plano, você deve ter memória disponível suficiente para acomodar a sobrecarga de processos. A falta de memória suficiente disponível faz com que o processo falhe. Por isso, é importante escolher um tipo de instância de nó que tenha memória suficiente ao criar seu cluster do Redis OSS.

## Processo de gravação em segundo plano e uso de memória com o Valkey e Redis OSS
<a name="BestPractices.BGSAVE.Process"></a>

Sempre que um processo de gravação em segundo plano é chamado, o Valkey e Redis OSS bifurcam seu processo (lembre-se, esses mecanismos são single-threaded). Uma bifurcação persiste seus dados no disco em um arquivo de snapshot .rdb do Redis OSS. A outra bifurcação atende a todas as operações de leitura e gravação. Para garantir que seu snapshot seja um snapshot de ponto no tempo, todas as atualizações e adições de dados são gravadas em uma área de memória disponível separada da área de dados.

Enquanto você tiver memória suficiente disponível para registrar todas as operações de gravação durante a manutenção dos dados no disco, não haverá problemas de memória insuficiente. É provável que você experimente problemas de memória insuficiente se uma das seguintes condições for verdadeira:
+ Seu aplicativo realiza muitas operações de gravação, exigindo assim uma grande quantidade de memória disponível para aceitar os dados novos ou atualizados.
+ Você tem pouca memória disponível para gravar dados novos ou atualizados.
+ Você tem um grande conjunto de dados que demora muito para persistir no disco, exigindo um grande número de operações de gravação.

O diagrama a seguir ilustra o uso da memória ao executar um processo de gravação em segundo plano.

![Imagem: diagrama de uso de memória durante uma gravação em segundo plano.](http://docs.aws.amazon.com/pt_br/AmazonElastiCache/latest/dg/images/ElastiCache-bgsaveMemoryUseage.png)


Para obter informações sobre o impacto de fazer um backup sobre o desempenho, consulte [Impacto sobre o desempenho dos backups de clusters baseados em nós](backups.md#backups-performance).

Para obter mais informações sobre como o Valkey e o Redis OSS realizam instantâneos, consulte. [http://valkey.io](http://valkey.io)

Para obter mais informações sobre regiões e zonas de disponibilidade, consulte [Escolhendo regiões e zonas de disponibilidade para ElastiCache](RegionsAndAZs.md). 

## Evitando memória insuficiente ao executar uma gravação em segundo plano
<a name="BestPractices.BGSAVE.memoryFix"></a>

Sempre que um processo de gravação em segundo plano, como `BGSAVE` ou `BGREWRITEAOF`, é chamado, para evitar que o processo falhe, você deve ter mais memória disponível do que será consumida por operações de gravação durante o processo. O cenário de pior caso é aquele em que, durante a operação de gravação em segundo plano, cada registro é atualizado e alguns novos registros são adicionados ao cache. Por conta disso, recomendamos que você defina `reserved-memory-percent` como 50 (50 por cento) para versões do Redis OSS anteriores à 2.8.22 ou como 25 (25 por cento) para o Valkey e todas as versões do Redis OSS 2.8.22 e posteriores. 

O valor `maxmemory` indica a memória disponível para dados e sobrecargas operacionais. Como você não pode modificar o parâmetro `reserved-memory` no parameter group padrão, deve criar um parameter group personalizado para o cluster. O valor padrão para `reserved-memory` é 0, o que permite que o Redis OSS consuma todo o *maxmemory* com dados, potencialmente deixando pouca memória para outros usos, como um processo de gravação em segundo plano. Para valores `maxmemory` por tipo de instância de nó, consulte [Parâmetros específicos de node-type do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis.NodeSpecific).

Você também pode usar o parâmetro `reserved-memory` para reduzir a quantidade de memória usada na caixa.

Para obter mais informações sobre o Valkey e Redis-specific os parâmetros em ElastiCache, consulte[Parâmetros do Valkey e do Redis OSS](ParameterGroups.Engine.md#ParameterGroups.Redis).

Para obter informações sobre como criar e modificar parameter groups, consulte [Criação de um grupo de ElastiCache parâmetros](ParameterGroups.Creating.md) e [Modificando um grupo de ElastiCache parâmetros](ParameterGroups.Modifying.md).