Sobre os snapshots do RDB

Esta página oferece uma visão geral dos snapshots de RDB para o Memorystore para Redis. Esta página pressupõe que você saiba sobre os instantâneos do RDB do Redis de código aberto e o recurso de importação/exportação do Memorystore.

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

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

Recomendamos o uso do nível padrão como o mecanismo principal para alta disponibilidade. Além disso, ativar os snapshots do RDB em instâncias do nível padrão oferece proteção extra contra falhas que podem causar o flush do cache. O nível padrão 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 principal falhar.

Em alguns casos, talvez você também queira garantir que os dados possam ser recuperados de backups de snapshots no 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 de RDB podem oferecer proteção adicional contra perda de dados. Com os snapshots do RDB ativados, se necessário, uma recuperação é feita a partir do snapshot mais recente do RDB.

Os snapshots do RDB são adequados para casos de uso que podem tolerar uma certa quantidade de dados desatualizados 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 de RDB tem o seguinte comportamento:

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

  • Você escolhe a frequência e a programação dos snapshots de rotina. O intervalo mínimo de snapshots é 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 passa por um upgrade para a 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 a principal e a réplica forem reiniciadas.

  • Não adiciona custos extras 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. Em qualquer momento, apenas o último snapshot bem-sucedido está disponível para recuperação. Além dos snapshots de RDB, você pode usar Exportar e importar para fazer backup e restaurar dados manualmente.

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

Restrições

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

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

Como programar snapshots do RDB

Ao ativar os snapshots do RDB durante a criação de instâncias, é necessário especificar 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 você pode definir 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 no dia em que forem ativados e continuar a cada hora depois disso.

Se um horário de início não for especificado, o primeiro instantâneo será feito o mais rápido possível, e o intervalo será respeitado. 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á respeitada de forma consistente se os snapshots sempre forem bem-sucedidos e não levarem mais tempo do que o intervalo de backup especificado.

No entanto, acionar o snapshot com base na programação diária é o melhor esforço. A programação pode se desviar da programação determinada 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 será iniciado imediatamente após a conclusão do snapshot atual.

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

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

Ajustar a programação

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

Para interromper temporariamente a criação de snapshots por um curto período, ajuste 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 só vai começar nessa data. Se você fizer isso, o último snapshot será retido por pelo menos sete dias e será usado em caso de recuperação.

Para saber mais sobre como ajustar programações de snapshots, consulte Ajustar a programação de snapshots.

Comportamento de recuperação

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

As instâncias do nível padrão do Redis fazem failover para uma réplica como o mecanismo de recuperação principal em vez de carregar de um snapshot. Uma instância do 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 saber como configurar e monitorar instâncias quando os snapshots de RDB estão ativados.

Se o snapshot falhar consecutivamente em vários intervalos, o último backup disponível poderá ficar obsoleto de forma arbitrária.

A pior perda de dados para 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 conferir o período de perda de dados.

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

Tempo de recuperação

A instância fica indisponível enquanto é recuperada 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 evitar a recuperação lenta

Às vezes, a recuperação de um snapshot pode demorar mais do que o esperado. Talvez seja necessário realizar uma ação para que o aplicativo seja conectado novamente ao Redis o mais rápido possível.

Nessa circunstância, você pode criar uma nova instância do Redis e direcionar o tráfego do aplicativo para ela. Depois, você pode transferir os dados restaurados para a nova instância assim que a instância original for recuperada.

Falha no snapshot e na recuperação

Falha no snapshot

Qualquer snapshot com falha é informado ao Cloud Monitoring, e o snapshot é tentado novamente imediatamente. As falhas consecutivas de snapshots 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 resolver problemas de falhas de snapshots, consulte Monitorar snapshots.

Falha na recuperação

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 melhores resultados ao fazer backup da sua instância com snapshots de RDB, siga as práticas recomendadas descritas abaixo:

Gerenciamento de memória

Os snapshots de RDB usam um fork de processo e o mecanismo copy-on-write para fazer um snapshot da instância. Dependendo do padrão de gravações na instância, a memória usada da instância vai aumentar à medida que as páginas tocadas pelas gravações forem copiadas. Na pior das hipóteses, a pegada 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 para que 20% seja reservado para sobrecarga. Consulte as Práticas recomendadas de gerenciamento de memória para saber mais. Essa sobrecarga de memória, além de monitorar snapshots, ajuda a gerenciar sua 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 no aplicativo, já que ele tenta reconciliar uma quantidade significativa de chaves desatualizadas ou outras mudanças no banco de dados, como uma mudança de esquema.

Se você achar que o snapshot está desatualizado ou que sua instância passou por outras mudanças importantes difíceis de reconciliar com o snapshot, desative e reative os snapshots do RDB. Isso exclui os snapshots atuais, permitindo que você evite a recuperação de um snapshot desatualizado.

Para monitorar snapshots desatualizados, defina um alerta nas métricas last_status e last_success_age do snapshot do RDB.

Recuperação prolongada de um snapshot

Recomendamos definir um alerta para a métrica redis.googleapis.com/server/uptime para receber uma notificação caso sua instância fique 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, você poderá transferir os dados restaurados para a nova instância.

Impacto no desempenho dos snapshots do RDB

Dependendo do padrão de 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 perda 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 de instância.

Use o horário de início e o intervalo para programar os snapshots nos horários necessários. Por exemplo, se a carga for muito baixa das 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 exigir snapshots frequentes, avalie com cuidado o impacto no desempenho e avalie os benefícios do uso de snapshots de RDB para a carga de trabalho.

Monitorar snapshots

É importante monitorar os snapshots e definir alertas para snapshots com falhas. Os snapshots com falha podem indicar uma instância sobrecarregada que pode continuar a ter dificuldade para se recuperar do snapshot.

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

Monitorar o impacto no desempenho

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

A seguir