Eventos
31 de mar., 23 - 2 de abr., 23
O maior evento de aprendizado de SQL, Fabric e Power BI. 31 de março a 2 de abril. Use o código FABINSIDER para economizar $ 400.
Registre-se hoje mesmoNão há mais suporte para esse navegador.
Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.
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.
Camada | Otimizada para Memória, Balanceada, Computação Otimizada | Otimizada para Flash |
---|---|---|
Disponível | Sim | Sim |
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):
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.
Os recursos de persistência devem ser usados para restaurar dados no mesmo cache após a perda de dados.
Entre no portal do Azure e comece a seguir as instruções no Guia de início rápido do Redis Gerenciado do Azure.
Ao acessar o guia Avançado, selecione as opções RDB ou AOF na seção Persistência de Dados.
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. |
Para habilitar a persistência do AOF, selecione AOF. Apenas uma opção de frequência de backup está disponível.
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.
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"
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"
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.
A lista a seguir contém respostas para perguntas frequentes sobre a persistência do Redis Gerenciado do Azure.
Sim, a persistência pode ser configurada tanto na criação de cache quanto em instâncias existentes do Redis Gerenciado do Azure.
Não, você pode habilitar apenas RDB ou AOF, mas não ambas ao mesmo tempo.
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.
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?
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.
Para a persistência de RDB e AOF:
Você não é cobrado pelo armazenamento em disco gerenciado. Está incluso no preço.
Sim, você pode alterar a frequência de backup para persistência RDB usando o portal do Azure, a CLI ou o PowerShell.
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.
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.
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.
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?
Eventos
31 de mar., 23 - 2 de abr., 23
O maior evento de aprendizado de SQL, Fabric e Power BI. 31 de março a 2 de abril. Use o código FABINSIDER para economizar $ 400.
Registre-se hoje mesmoTreinamento
Módulo
Introdução ao Cache do Azure para Redis - Training
Avalie como o Cache do Azure para Redis pode melhorar o desempenho e a escalabilidade de seus aplicativos. Descreva como o Redis oferece uma solução de armazenamento de dados crítica de baixa latência e alta taxa de transferência para aplicativos modernos.
Certificação
Microsoft Certified: Azure Database Administrator Associate - Certifications
Administrar uma infraestrutura de banco de dados do SQL Server para bancos de dados relacionais de nuvem, locais e híbridos usando as ofertas de banco de dados relacional do Microsoft PaaS.