Compartilhar via


Configurar a persistência de dados para uma instância do Redis Gerenciado do Azure (versão prévia)

A persistência do Redis permite persistir os dados armazenados na instância de cache. Se houver uma falha de hardware, a instância de cache será reidratada com dados do arquivo de persistência quando ela voltar a ficar online. A capacidade de persistir dados é uma maneira importante de aumentar a durabilidade de uma instância de cache porque todos os dados de cache são armazenados na memória. A perda de dados é possível se ocorrer uma falha quando os nós de cache estiverem inativos. A persistência deve ser uma parte fundamental da sua estratégia de alta disponibilidade e recuperação de desastre com o Redis Gerenciado do Azure (versão prévia).

Importante

A persistência de dados destina-se a fornecer resiliência para falhas inesperadas de nó do Redis, mas não é um recurso de PITR (backup de dados ou de recuperação pontual). Se os dados corrompidos forem gravados na instância do Redis, esses dados também serão persistidos. Para fazer backups da instância do Redis, use o recurso de exportação.

Escopo de disponibilidade

Camada Otimizada para Memória, Balanceada, Computação Otimizada Otimizada para Flash
Disponível Sim Sim

Tipos de persistência de dados no Redis

Você tem duas opções de persistência com o Redis Gerenciado do Azure: o formato Banco de dados do Redis (RDB) e o formato Acrescentar somente arquivo (AOF):

  • Persistência RDB: ao usar a persistência RDB, o Redis Gerenciado do Azure persiste um instantâneo do seu cache em um formato binário. O instantâneo é salvo em um disco gerenciado montado na instância do Redis. A frequência de backup configurável determina a frequência de persistência do instantâneo. Se ocorrer um evento catastrófico que desabilite o primário e a réplica, o cache será reconstruído automaticamente usando o instantâneo mais recente. Saiba mais sobre as vantagens e as desvantagens de persistência de RDB.
  • Persistência de AOF: ao usar a persistência AOF, o Redis Gerenciado do Azure salva cada operação de gravação em um log. O log é salvo uma vez por segundo em um disco gerenciado montado na instância do Redis. Se ocorrer um evento catastrófico que desative os caches primário e de réplica, o cache será reconstruído automaticamente usando as operações de gravação armazenadas. Saiba mais sobre as vantagens e as desvantagens da persistência de AOF.

Importante

Os recursos de persistência do Redis Gerenciado do Azure devem ser utilizados para restaurar dados automaticamente no mesmo cache após a perda de dados. Os arquivos de dados persistentes RDB/AOF não podem ser acessados pelos usuários nem importados para um cache novo ou existente. Para mover dados entre caches, use o recurso Importar/Exportar. Para obter mais informações, confira Importar e exportar dados no Redis Gerenciado do Azure.

Para gerar backups de dados que podem ser adicionados a um novo cache, grave scripts automatizados usando o PowerShell ou a CLI do Azure para exportar dados periodicamente.

Pré-requisitos e limitações

Os recursos de persistência devem ser usados para restaurar dados no mesmo cache após a perda de dados.

  • Os arquivos de dados persistentes RDB/AOF não podem ser importados para um novo cache ou cache existente. Em vez disso, use o recurso Importação/Exportação.
  • Não há suporte para persistência com caches usando replicação geográfica ativa.
  • O disco gerenciado que contém arquivos de dados persistentes é criptografado usando MMK (chaves gerenciadas da Microsoft) por padrão, mas as CMK (chaves gerenciadas pelo cliente) também podem ser usadas. Para obter mais informações, confira gerenciamento de criptografia de dados.

Como configurar a persistência de dados usando o portal do Azure

  1. Entre no portal do Azure e comece a seguir as instruções no Guia de início rápido do Redis Gerenciado do Azure.

  2. Ao acessar o guia Avançado, selecione as opções RDB ou AOF na seção Persistência de Dados.

    Captura de tela que mostra a guia Avançado da camada Enterprise e a persistência de dados realçada com uma caixa vermelha.

  3. Para habilitar a persistência de RDB, clique em RDB e defina as configurações.

    Configuração Valor sugerido Descrição
    Frequência de backup Use a lista suspensa e selecione um intervalo de backup. As opções incluem 60 minutos, 6 horas e 12 horas. Esse intervalo inicia a contagem regressiva depois que a operação de backup anterior for concluída com êxito. Quando ele é iniciado, um novo backup é iniciado.
  4. Para habilitar a persistência do AOF, selecione AOF. Apenas uma opção de frequência de backup está disponível.

  5. Conclua a criação do cache seguindo o restante das instruções no Guia de início rápido do Redis Gerenciado do Azure.

Observação

Adicione persistência a uma instância do Redis Gerenciado do Azure criada anteriormente a qualquer momento navegando até as Configurações avançadas no menu Recurso.

Como configurar a persistência de dados usando o PowerShell e a CLI do Azure

Usando o PowerShell

O comando New-AzRedisEnterpriseCache pode ser usado para criar uma nova instância do Redis Gerenciado do Azure usando persistência de dados. Use os parâmetros RdbPersistenceEnabled, RdbPersistenceFrequency, AofPersistenceEnabled e AofPersistenceFrequency para configurar a persistência. Este exemplo cria uma nova instância balanceada B10 usando a persistência RDB com frequência de uma hora:

New-AzRedisEnterpriseCache -Name "MyCache" -ResourceGroupName "MyGroup" -Location "West US" -Sku "Balanced_B10" -RdbPersistenceEnabled -RdbPersistenceFrequency "1h"

Os caches existentes podem ser atualizados usando o comando Update-AzRedisEnterpriseCacheDatabase. Este exemplo adiciona persistência RDB com frequência de 12 horas a uma instância existente:

Update-AzRedisEnterpriseCacheDatabase -Name "MyCache" -ResourceGroupName "MyGroup" -RdbPersistenceEnabled -RdbPersistenceFrequency "12h"

Usando a CLI do Azure

O comando az redisenterprise create pode ser usado para criar uma nova instância do Redis Gerenciado do Azure usando persistência de dados. Use os parâmetros rdb-enabled, rdb-frequency, aof-enabled e aof-frequency para configurar a persistência. Este exemplo cria uma nova instância balanceada B10 usando a persistência RDB com frequência de uma hora:

az redisenterprise create --cluster-name "cache1" --resource-group "rg1" --location "East US" --sku "Balanced_B10" --persistence rdb-enabled=true rdb-frequency="1h" 

Os caches existentes podem ser atualizados usando o comando az redisenterprise database update. Este exemplo adiciona persistência RDB com frequência de 12 horas a uma instância de cache existente:

az redisenterprise database update --cluster-name "cache1" --resource-group "rg1" --persistence rdb-enabled=true rdb-frequency="12h" 

Gerenciando a criptografia de dados

Como a persistência do Redis cria dados inativos, criptografar esses dados é uma preocupação importante para muitos usuários. No Redis Gerenciado do Azure, os dados são armazenados em um disco gerenciado montado na instância de cache. Por padrão, o disco que contém os dados de persistência e o disco do sistema operacional são criptografados usando chaves gerenciadas pela Microsoft. Uma chave gerenciada pelo cliente (CMK) também pode ser usada para controlar a criptografia de dados. Consulte Criptografia no Redis Gerenciado do Azure para obter instruções.

Perguntas frequentes sobre persistência

A lista a seguir contém respostas para perguntas frequentes sobre a persistência do Redis Gerenciado do Azure.

Persistência de RDB

Persistência de AOF

Posso habilitar a persistência em um cache criado anteriormente?

Sim, a persistência pode ser configurada tanto na criação de cache quanto em instâncias existentes do Redis Gerenciado do Azure.

Posso habilitar a persistência de AOF e RDB ao mesmo tempo?

Não, você pode habilitar apenas RDB ou AOF, mas não ambas ao mesmo tempo.

Como a persistência funciona com a replicação geográfica?

Se você habilitar a persistência de dados, a replicação geográfica não poderá ser habilitada para seu cache. Isso ocorre porque a replicação geográfica ativa fornece melhor resiliência do que a persistência de dados no caso de uma interrupção regional. Caso precise exportar uma cópia de seus dados como um backup, use o recurso de exportação.

Qual modelo de persistência eu devo escolher?

A persistência AOF salva todas as gravações em um log, o que pode ter um efeito significativo na taxa de transferência. A persistência de RDB salva backups com base no intervalo de backup configurado com efeito mínimo no desempenho. Escolha a persistência de AOF se o seu principal objetivo for minimizar a perda de dados, e se você pode manipular uma diminuição na taxa de transferência de seu cache. Escolha a persistência de RDB se você quiser manter a taxa de transferência ideal em seu cache, mas ainda quiser um mecanismo para recuperação de dados.

Para saber mais sobre o desempenho ao usar a persistência AOF, veja A persistência AOF afeta a taxa de transferência, latência ou desempenho de meu cache?

A persistência AOF afeta a taxa de transferência, latência ou desempenho de meu cache?

O uso da persistência do AOF afeta a taxa de transferência. O AOF em todos os processos primários, portanto, você visualiza maior carga de servidor e CPU para um cache com persistência AOF do que para um cache idêntico sem persistência AOF. O AOF oferece a melhor consistência com os dados na memória porque cada gravação e exclusão é persistida com apenas alguns segundos de atraso. A desvantagem é que o AOF é mais intensivo em computação.

O que acontecerá se eu tiver dimensionado para um tamanho diferente e um backup que foi feito antes da operação de escala for restaurado?

Para a persistência de RDB e AOF:

  • Se você tiver escalado para um tamanho maior, não haverá nenhum efeito.
  • Se você tiver dimensionado para um tamanho menor e não houver espaço suficiente no menor tamanho para conter todos os dados do último backup, as chaves serão removidas durante o processo de restauração. Geralmente, as chaves são removidas usando a política de remoção allkeys-lru.

Serei cobrado pelo disco gerenciado usado na persistência de dados?

Você não é cobrado pelo armazenamento em disco gerenciado. Está incluso no preço.

Posso alterar a frequência de backup de RDB depois de criar o cache?

Sim, você pode alterar a frequência de backup para persistência RDB usando o portal do Azure, a CLI ou o PowerShell.

Por que quando eu tenho uma frequência de backup de RDB de 60 minutos há mais de 60 minutos entre os backups?

O intervalo da frequência de backup da persistência de RDB não é iniciado até que o processo de backup anterior seja concluído com êxito. Se a frequência de backup for de 60 minutos e usar um processo de backup de 15 minutos para concluir com êxito, o próximo backup não será iniciado até 75 minutos após a hora de início do backup anterior.

O que acontece com os backups de RDB antigos quando um backup novo é realizado?

Todos os backups da persistência de RDB, exceto pelo mais recente, serão excluídos automaticamente. Essa exclusão pode não acontecer imediatamente, mas os backups mais antigos não são persistidos por tempo indeterminado.

O que é uma regravação e como ela afeta meu cache?

Quando o arquivo AOF fica muito grande, uma regeneração é automaticamente enfileirada no cache. A regeneração redimensiona o arquivo AOF com o conjunto mínimo de operações necessárias para criar o conjunto de dados atual. Durante as regravações, você pode esperar atingir os limites de desempenho mais cedo, especialmente ao lidar com grandes conjuntos de dados. As regravações ocorrem com menos frequência à medida que o arquivo de AOF fica maior, mas demoram muito mais quando acontecem.

O que devo esperar ao dimensionar um cache com o AOF habilitado?

Se o arquivo de AOF no momento da colocação em escala for grande, espere que a operação de dimensionamento demore mais do que o normal, pois ela recarrega o arquivo após a conclusão do dimensionamento.

Para saber mais sobre dimensionamento, confira O que acontecerá se eu tiver dimensionado para um tamanho diferente e um backup que foi feito antes da operação de escala for restaurado?

Próximas etapas