Partilhar via


Configurar a persistência de dados para uma instância do Azure Managed Redis (pré-visualização)

A persistência do Redis permite-lhe manter os dados armazenados instância de cache. Se existir uma falha de hardware, a instância de cache é reidratada com dados do ficheiro de persistência quando voltar a ficar online. A capacidade de persistir os dados é uma forma importante de aumentar a durabilidade de uma instância de cache uma vez que todos os dados da cache são armazenados na memória. A perda de dados será possível se ocorrer quando os nós da cache ficam inativos. A persistência deve ser uma parte essencial da sua estratégia de elevada disponibilidade e recuperação após desastres com o Azure Managed Redis (pré-visualização).

Importante

A persistência de dados destina-se a fornecer resiliência para falhas inesperadas de nó Redis, mas não é uma funcionalidade de cópia de segurança dos dados nem recuperação pontual (PITR). Se os dados corrompidos forem gravados na instância do Redis, esses dados também serão mantidos. Para fazer cópias de segurança da sua instância Redis, utilize a funcionalidade de exportação.

Âmbito da disponibilidade

Escalão de serviço Otimizada para memória, Equilibrada, Otimizada para computação Otimizada para Flash
Disponível Sim Sim

Tipos de persistência de dados no Redis

Você tem duas opções para persistência com o Azure Managed Redis: o formato de banco de dados Redis (RDB) e o formato AOF (Append only File):

  • Persistência RDB - Quando você usa a persistência RDB, o Azure Managed Redis persiste um instantâneo do cache em um formato binário. O snapshot é salvo em um disco gerenciado montado na instância do Redis. A frequência de backup configurável determina a frequência com que o snapshot deve ser persistido. Se ocorrer um evento catastrófico que desative 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 desvantagens da persistência do RDB.
  • Persistência do AOF - Quando utiliza a persistência o AOF, o Azure Managed Redis guarda todas as operações de escrita num registo. O registo é guardado uma vez por segundo num disco gerido montado na instância Redis. Se ocorrer um evento catastrófico que desative as caches principal e de réplica, a cache é reconstruída automaticamente utilizando as operações de escrita armazenadas. Saiba mais sobre as vantagens e desvantagens da persistência do AOF.

Importante

As funcionalidades de persistência do Azure Managed Redis destinam-se a ser utilizadas para restaurar automaticamente os dados para a mesma cache após a perda de dados. Os ficheiros de dados persistentes RDB/AOF não podem ser acedidos pelos utilizadores nem importados para uma cache nova ou existente. Para mover dados entre caches, utilize a funcionalidade Importar e Exportar. Para obter mais informações, consulte Importar e Exportar dados no Azure Managed Redis.

Para gerar backups de dados que podem ser adicionados a um novo cache, você pode escrever scripts automatizados usando o PowerShell ou a CLI do Azure que exportam dados periodicamente.

Pré-requisitos e limitações

As funcionalidades de persistência destinam-se a ser utilizadas para restaurar dados na mesma cache após a perda de dados.

  • Os ficheiros de dados persistentes RDB/AOF não podem ser importados para uma nova cache nem para a cache existente. Em vez disso, utilize a funcionalidade Importar/Exportar.
  • A persistência não é suportada com caches que utilizam a georreplicação ativa.
  • O disco gerido que contém ficheiros de dados persistentes é encriptado utilizando chaves geridas pela Microsoft (MMK) por predefinição, mas também podem ser utilizadas chaves geridas pelo cliente (CMK). Para obter mais informações, consulte gerir a encriptação 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 Azure Managed Redis.

  2. Quando chegar à 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 RDB, selecione RDB e defina as configurações.

    Definição Valor sugerido Description
    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 começa a contagem regressiva após a conclusão bem-sucedida da operação de backup anterior. Quando ele expira, 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 Azure Managed Redis.

Nota

Você pode adicionar persistência a uma instância do Azure Managed Redis 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

Através do PowerShell

O comando New-AzRedisEnterpriseCache pode ser usado para criar uma nova instância do Azure Managed Redis usando persistência de dados. Use os RdbPersistenceEnabledparâmetros , RdbPersistenceFrequency, AofPersistenceEnablede para AofPersistenceFrequency configurar a configuração de persistência. Este exemplo cria uma nova instância B10 balanceada usando 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"

Utilizar a CLI do Azure

O comando az redisenterprise create pode ser usado para criar uma nova instância do Azure Managed Redis usando persistência de dados. Use os rdb-enabledparâmetros , rdb-frequency, aof-enablede para aof-frequency configurar a configuração de persistência. Este exemplo cria uma nova instância B10 balanceada usando 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 em repouso, criptografar esses dados é uma preocupação importante para muitos usuários. No Azure Managed Redis, 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 Azure Managed Redis para obter instruções.

FAQ sobre a Persistência

A lista seguinte contém respostas a perguntas frequentes sobre a persistência do Azure Managed Redis.

Persistência do RDB

Persistência do AOF

Posso ativar a persistência numa cache criada anteriormente?

Sim, a persistência pode ser configurada na criação da cache e nas instâncias do Azure Managed Redis existentes.

Posso ativar a persistência do AOF e RDB ao mesmo tempo?

Não, pode ativar o RDB ou o AOF, mas não os dois ao mesmo tempo.

Como é que a persistência funciona com a georreplicação?

Se ativar a persistência de dados, a georreplicação não pode ser ativada para a a sua cache. Isto deve-se ao facto de a georreplicação ativa proporcionar uma melhor resiliência do que a persistência de dados no caso de uma indisponibilidade regional. Se precisar de exportar uma cópia dos seus dados como cópia de segurança, utilize a funcionalidade de exportação.

Que modelo de persistência devo escolher?

A persistência do AOF guarda todas as escritas num registo, o que pode ter um efeito significativo na transferência. A persistência do RDB guarda cópias de segurança com base no intervalo de cópia de segurança configurado com um efeito mínimo no desempenho. Escolha a persistência do AOF se o seu objetivo principal for minimizar a perda de dados e se conseguir suportar uma transferência inferior para a cache. Escolha a persistência do RDB se pretender manter uma transferência ideal na cache, mas ainda assim pretender um mecanismo de recuperação de dados.

Para obter mais informações sobre o desempenho ao utilizar a persistência do AOF, consulte A persistência do AOF afeta a taxa de transferência, a latência ou o desempenho da minha cache?

A persistência do AOF afeta a taxa de transferência, a latência ou o desempenho da minha cache?

A utilização da persistência do AOF tem impacto na transferência. O AOF é executado em todos os processos principais, pelo que observa uma maior Carga da CPU e do Servidor para uma cache com persistência do AOF do que para uma cache idêntica sem persistência do AOF. O AOF oferece a melhor consistência com os dados em memória porque cada escrita e eliminação é persistida com apenas alguns segundos de atraso. A contrapartida é o facto de o AOF ser mais intensivo em termos de computação.

O que acontece se tiver dimensionado para um tamanho diferente e for restaurada uma cópia de segurança realizada antes da operação de dimensionamento?

Para a persistência do RDB e AOF:

  • Se tiver dimensionado para um tamanho maior, não há qualquer efeito.
  • Se tiver dimensionado para um tamanho mais pequeno e não houver espaço suficiente no tamanho mais pequeno para guardar todos os dados da última cópia de segurança, as chaves são expulsas durante o processo de restauro. Normalmente, as chaves são expulsas utilizando a política de expulsão allkeys-lru.

Serei cobrado pelo disco gerido que está a ser utilizado na persistência de dados?

Não lhe é cobrado o armazenamento em disco gerido. Está incluído no preço.

Posso alterar a frequência da cópia de segurança do RDB depois de criar a cache?

Sim, pode alterar a frequência de cópia de segurança para a persistência do RDB utilizando o portal do Azure, a CLI ou o PowerShell.

Porque é que existe um intervalo de mais de 60 minutos entre as cópias de segurança quando tenho uma frequência de cópia de segurança do RDB de 60 minutos?

O intervalo de frequência de cópia de segurança da persistência do RDB não é iniciado até que o processo de cópia de segurança anterior tenha sido concluído com êxito. Se a frequência de cópia de segurança for de 60 minutos e um processo de cópia de segurança demorar 15 minutos a ser concluído, a próxima cópia de segurança não será iniciada até 75 minutos após a hora de início da cópia de segurança anterior.

O que acontece às cópias de segurança antigas do RDB quando é realizada uma nova cópia de segurança?

Todas as cópias de segurança da persistência do RDB, exceto a mais recente, são eliminadas automaticamente. Esta eliminação pode não ocorrer imediatamente, mas as cópias de segurança mais antigas não são mantidas indefinidamente.

O que é uma reescrita e como afecta a minha cache?

Quando o ficheiro do AOF se torna suficientemente grande, uma reescrita é colocada automaticamente em fila na cache. A reescrita redimensiona o ficheiro do AOF com o conjunto mínimo de operações necessárias para criar o conjunto de dados atual. Durante as reescritas, é expetável que os limites de desempenho sejam atingidos mais cedo, especialmente quando se lida com grandes conjuntos de dados. As reescritas ocorrem com menos frequência à medida que o ficheiro do AOF se torna maior, mas demoram uma quantidade significativa de tempo quando tal acontece.

O que devo esperar ao dimensionar uma cache com o AOF ativado?

Se, no momento do dimensionamento, o ficheiro do AOF for grande, a operação de dimensionamento deve demorar mais tempo do que o normal, porque o ficheiro é recarregado após o fim do dimensionamento.

Para obter mais informações sobre dimensionamento, consulte O que acontece se tiver dimensionado para um tamanho diferente e for restaurada uma cópia de segurança realizada antes da operação de dimensionamento?

Próximos passos