Sobre os snapshots do RDB

Nesta página, você terá uma visão geral dos snapshots do RDB para Memorystore para Redis. Nesta página, presumimos que você conhece os snapshots do RDB do Redis de código aberto e o recurso de import/exportação do Memorystore.

Para saber como ativar, desativar e monitorar snapshots do RDB, consulte Como gerenciar snapshots do RDB.

O Memorystore para Redis é usado principalmente como cache na memória. Ao usar o Memorystore como cache, o aplicativo pode tolerar a perda de dados de cache ou preencher novamente o cache com facilidade usando um armazenamento persistente. No entanto, há alguns casos de uso em que a inatividade de uma instância do Memorystore ou a perda completa dos dados da instância podem causar longos períodos de inatividade do aplicativo.

Recomendamos o uso do nível Standard como o mecanismo principal de alta disponibilidade. Além disso, a ativação de snapshots do RDB em instâncias do nível Standard oferece proteção extra contra falhas que podem causar limpezas no cache. O nível Standard fornece uma instância altamente disponível com várias réplicas e permite a recuperação rápida usando o failover automático se a primária falhar.

Em alguns cenários, também convém garantir que os dados possam ser recuperados de backups de snapshot em caso de falha catastrófica de instâncias do nível padrão. Nesses cenários, os backups automatizados e a capacidade de restaurar dados de snapshots do RDB podem fornecer proteção adicional contra perda de dados. Com os snapshots do RDB ativados, se necessário, é feita uma recuperação do snapshot mais recente do RDB.

Os snapshots do RDB são adequados para casos de uso que podem tolerar uma quantidade de inatividade de dados após a recuperação. Também é possível usar snapshots do RDB para automatizar o backup e a recuperação de instâncias do nível Básico.

Visão geral dos snapshots do RDB

O recurso de snapshots do RDB tem o seguinte comportamento:

  • Armazena snapshots completos pontuais em intervalos especificados pelo usuário no armazenamento permanente.

  • Você escolhe a frequência e a programação dos resumos de rotina. O intervalo mínimo de snapshot é 1h, e o máximo é 24h.

  • As instâncias do nível básico recuperam dados do snapshot mais recente sempre que uma instância é reiniciada devido a uma falha, passa por uma operação de escalonamento ou por um upgrade da versão do OSS Redis da sua instância.

  • Por padrão, as instâncias do nível padrão recuperam dados da réplica, não de um snapshot. No entanto, as instâncias do nível padrão recuperam dados de um snapshot se uma réplica não estiver disponível e as instâncias primária e réplica passarem por uma reinicialização.

  • não adiciona nenhum custo extra ao faturamento da instância;

Comportamento adicional

  • Os snapshots são usados para recuperação de instâncias e não estão disponíveis para restaurações manuais. A qualquer momento, apenas o último snapshot bem-sucedido está disponível para recuperação. Além dos snapshots do RDB, é possível usar Export e Import para fazer backup e restaurar manualmente seus dados.

  • Em uma instância de nível padrão, o snapshot é capturado na réplica para minimizar o uso de memória e CPU na instância principal. Os snapshots nunca são extraídos do nó principal.

Restrições

  • Disponível em instâncias do Memorystore para Redis usando a versão 5.0 ou mais recente do Redis.

  • Se a instância tiver muitas chaves (cerca de 200 milhões ou mais), as recuperações e os snapshots do RDB podem ser lentos. Nesse volume, o próprio servidor Redis pode ser o gargalo que atrasa os snapshots e as recuperações.

Como programar snapshots do RDB

Ao ativar snapshots do RDB durante a criação da instância, especifique um intervalo de snapshot. Você também tem a opção de especificar um horário de início. Juntos, eles definem a programação diária dos snapshots. Os intervalos que podem ser definidos são 1h, 6h, 12h e 24h. Por exemplo, se você definir o horário de início como 4h e o intervalo como 1 hora, os snapshots vão começar às 4h do dia em que foram ativados e continuarão a cada hora depois disso.

Se um horário de início não for especificado, o primeiro snapshot será capturado assim que possível, e o intervalo será mantido. Por exemplo, com um horário de início não especificado e um intervalo de uma hora, o snapshot pode começar às 6h13 e continuar às 7h13, 8h13 etc.

Se um horário de início for especificado, a programação diária será honrada de maneira consistente se os snapshots sempre forem bem-sucedidos e não demorarem mais do que o intervalo de backup especificado.

No entanto, acionar o snapshot com base na programação diária é o melhor esforço. O cronograma pode ser diferente do programado inicialmente por vários motivos:

  • Se um snapshot falhar ou demorar mais do que o intervalo especificado para ser concluído, o próximo snapshot vai começar imediatamente após a conclusão do snapshot atual.

    • Para evitar que o snapshot seja executado continuamente e sobrecarregue a instância, recomendamos definir um intervalo longo o suficiente para permitir que o snapshot seja concluído.

  • Se um snapshot já estiver em andamento em um horário alinhado à programação diária, ele será concluído, e o horário do próximo snapshot será calculado exclusivamente no intervalo entre o início do último snapshot bem-sucedido.

Como ajustar a programação atual

Você pode se deparar com cenários em que queira pausar temporariamente a captura de snapshots do RDB por um determinado período. Isso pode garantir que não haja impactos no desempenho durante eventos críticos ou desativar temporariamente os snapshots para solucionar problemas de desempenho.

Para interromper a criação de snapshots temporariamente por um curto período, é possível ajustar o horário de início para uma data futura. Depois de ajustar o horário de início para uma data futura, o próximo snapshot não será iniciado até essa data. Se você fizer isso, o último snapshot será mantido por pelo menos sete dias e será usado em caso de recuperação.

Para saber mais, consulte Como ajustar a programação de snapshots.

Comportamento de recuperação

As instâncias do Redis de nível básico acionam uma recuperação sempre que a instância é reiniciada. As operações comuns que acionam reinicializações são escalonamento e upgrade da versão da instância. Os snapshots do RDB preservam os dados da instância do nível Básico durante essas operações que causam reinicializações, manutenção planejada e falhas inesperadas do sistema.

O failover das instâncias do Redis de nível padrão para uma réplica é o mecanismo de recuperação principal, em vez de ser carregado de um snapshot. Uma instância de nível padrão é recuperada do snapshot quando a restauração de uma réplica falha.

Consistência de dados na recuperação

Quando ativados, os snapshots do RDB fazem o possível para garantir que os backups ocorram no intervalo especificado, mas isso não pode ser garantido. Os snapshots podem falhar por vários motivos. Consulte as práticas recomendadas para configurar e monitorar instâncias quando snapshots do RDB estão ativados.

Se o snapshot falhar consecutivamente em vários intervalos, o último backup disponível poderá ficar arbitrariamente desatualizado.

O pior caso de perda de dados de uma recuperação de um snapshot é a soma do intervalo especificado desde o início do último snapshot válido e o tempo para salvar o próximo snapshot no armazenamento. No caso de um incidente de recuperação, use a métrica last_success_age para visualizar o prazo para a perda de dados.

Recomendamos que você defina alertas para detectar falhas em snapshots programados e tomar as medidas corretivas. Para saber mais sobre como definir alertas, consulte Como monitorar snapshots.

Tempo de recuperação

A instância fica indisponível enquanto se recupera de um snapshot. O tempo de recuperação depende do tamanho do snapshot. Para entender o tempo de recuperação previsto, verifique a métrica RDB recovery remaining time usando o Cloud Monitoring no console do Google Cloud.

Como reduzir a recuperação lenta

Às vezes, a recuperação de um snapshot pode levar mais tempo do que o esperado. Talvez seja necessário tomar medidas para que seu aplicativo seja reconectado ao Redis o mais rápido possível.

Nessa circunstância, é possível criar uma nova instância do Redis e direcionar o tráfego do aplicativo para ela. Em seguida, será possível transferir os dados restaurados para a nova instância após a recuperação da instância original.

Falha no snapshot e na recuperação

Falha no snapshot

Qualquer snapshot com falha é informado ao Cloud Monitoring, e uma nova tentativa é feita imediatamente. As falhas consecutivas de snapshot aumentam a quantidade de dados perdidos no caso de uma recuperação, porque os dados recuperados ficam cada vez mais desatualizados. Para informações sobre como detectar e solucionar problemas de falha em snapshots, consulte Como monitorar snapshots.

Falha na recuperação

As falhas de recuperação são raras, mas podem acontecer. Se ocorrer uma falha de recuperação, a instância será recuperada sem dados.

Práticas recomendadas

Para ter os melhores resultados ao fazer backup da sua instância com snapshots do RDB, siga as práticas recomendadas descritas abaixo:

Gerenciamento de memória

Os snapshots do RDB usam uma bifurcação de processo e um mecanismo "copy-on-write" para capturar um snapshot da instância. Dependendo do padrão de gravações na instância, a memória usada da instância cresce à medida que as páginas tocadas pelas gravações são copiadas. No pior dos casos, o consumo de memória pode ser o dobro do tamanho dos dados na instância.

Para garantir que a instância tenha memória suficiente para concluir o snapshot, defina maxmemory-gb como 80% da capacidade da instância. Assim, 20% são reservados para sobrecarga. Consulte Práticas recomendadas de gerenciamento de memória para saber mais. Essa sobrecarga de memória, além dos snapshots do Monitoring, ajuda a gerenciar a carga de trabalho para ter snapshots bem-sucedidos.

Snapshots desatualizados

A recuperação da instância de um snapshot desatualizado pode causar problemas de desempenho para o aplicativo, porque ele tenta reconciliar uma quantidade significativa de chaves desatualizadas ou outras mudanças no banco de dados, como uma alteração de esquema.

Se você achar que o snapshot está muito desatualizado ou se a instância tiver sofrido outras alterações importantes que são difíceis de reconciliar com o snapshot, desative e reative os snapshots do RDB. Isso exclui os snapshots atuais. Assim, você evita a recuperação de um snapshot desatualizado.

Para monitorar snapshots desatualizados, defina um alerta no snapshot do RDB last_status e nas last_success_age metrics do snapshot do RDB.

Recuperação prolongada de um snapshot

Recomendamos definir um alerta para a métrica redis.googleapis.com/server/uptime para notificar você se a instância ficar indisponível.

Se a instância não estiver disponível e a recuperação de um snapshot estiver demorando muito, crie uma nova instância do Redis e direcione o tráfego para ela. Depois que a instância original do Redis for recuperada, transfira os dados restaurados para a nova instância.

Impacto no desempenho dos snapshots do RDB

Dependendo do padrão da carga de trabalho, os snapshots do RDB podem afetar o desempenho da instância e aumentar a latência dos aplicativos.

Dependendo da quantidade de possíveis perdas de dados que o aplicativo pode tolerar, é possível minimizar o impacto no desempenho dos snapshots do RDB, programando-os para ser executados durante períodos de baixo tráfego da instância.

Use o horário de início e o intervalo para programar os snapshots para os horários necessários. Por exemplo, se a carga estiver muito baixa da 1h às 4h, defina o horário de início como 3h e o intervalo como 24 horas.

Se o sistema tiver uma carga constante e precisar de snapshots frequentes, avalie cuidadosamente o impacto no desempenho e pondere os benefícios do uso de snapshots RDB para a carga de trabalho.

Como monitorar snapshots

É importante monitorar snapshots e definir alertas para snapshots com falha. Snapshots com falha podem indicar uma instância sobrecarregada que talvez continue com dificuldade para se recuperar do snapshot.

Para uma lista de métricas disponíveis para snapshots de monitoramento, consulte Métricas de snapshot do RDB. Para receber o aviso de um snapshot com falha, defina um alerta para a métrica last_status do snapshot do RDB. Também é possível usar o console do Google Cloud para verificar se há falhas.

Como monitorar o impacto no desempenho

É possível monitorar o impacto no desempenho de um snapshot na instância do Memorystore visualizando as métricas disponíveis no Cloud Monitoring, como uso de CPU, uso de memória etc. Se você notar uma redução no desempenho, use a métrica de snapshot do RDB in_progress para determinar se um snapshot estava em andamento quando problemas de desempenho foram detectados.

A seguir