Sobre os snapshots do RDB

Esta página oferece uma visão geral dos snapshots RDB para o Memorystore para Redis. Esta página pressupõe que você conhece os snapshots 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 a Memorystore como um cache, o aplicativo pode tolerar a perda de dados do cache ou repovoar o cache com muita facilidade de um armazenamento permanente. 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 usar o nível Standard como o mecanismo principal para alta disponibilidade (HA). O nível Standard oferece uma instância de alta disponibilidade com várias réplicas e permite recuperação rápida usando failover automático se a primária falhar. Além disso, ativar snapshots de RDB em instâncias do nível Standard oferece proteção extra contra falhas de nós.

Em alguns casos, talvez você também queira garantir que é possível recuperar dados de backups de instantâneos. Nesses cenários, os backups e a capacidade de restaurar dados de snapshots do RDB podem oferecer proteção adicional contra perda de dados.

Se você ativar os snapshots do RDB e precisar recuperar seus dados, o Memorystore para Redis poderá fazer isso com base no snapshot mais recente. Esses snapshots são apenas para recuperação interna do sistema e não podem ser acessados. Também é possível usar os snapshots 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 pontuais completos em intervalos especificados pelo usuário no armazenamento persistente.

  • Você escolhe a frequência e a programação dos snapshots de rotina. O intervalo mínimo entre 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 de versão.

  • Por padrão, as instâncias do nível Standard recuperam dados da réplica, não de um snapshot. No entanto, as instâncias do nível Standard recuperam dados de um snapshot se uma réplica não estiver disponível e a instância primária e a réplica forem reiniciadas.

  • Não adiciona 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 fica disponível para recuperação. Além dos snapshots do RDB, é possível usar a exportação e importação para fazer backup e restaurar seus dados manualmente.

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

Restrições

  • Disponível em 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 principal, o próprio servidor Redis pode ser o gargalo que diminui a velocidade dos snapshots e das recuperações.

Como programar snapshots do RDB

Ao ativar snapshots do RDB durante a criação da instância, especifique um intervalo de snapshots. Você também pode 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 forem ativados e continuarão a cada hora depois disso.

Se um horário de início não for especificado, o primeiro snapshot será feito assim que 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 demorarem mais do que o intervalo de backup especificado.

No entanto, o acionamento do snapshot com base na programação diária é feito conforme o possível. O cronograma pode divergir do inicialmente determinado por vários motivos:

  • Se um snapshot falhar ou levar mais tempo 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 instantâneo seja executado continuamente e sobrecarregue a instância, recomendamos definir um intervalo longo o suficiente para que o instantâneo 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 próximo horário de snapshot será calculado apenas com base no intervalo desde o início do último snapshot bem-sucedido.

Ajustar a programação

Pode haver situações em que você queira 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 para desativar temporariamente os snapshots e 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 que você ajusta o horário de início para uma data futura, o próximo snapshot não começa até essa data. Se você fizer isso, o último snapshot será retido por pelo menos 7 dias e 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 Redis de nível Básico acionam uma recuperação sempre que são reiniciadas. 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.

As instâncias do Redis no nível Standard fazem failover para uma réplica como o mecanismo principal de recuperação, em vez de carregar de um snapshot. Uma instância do nível Standard é 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 do RDB estão ativados.

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

A perda de dados no pior caso 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. Em caso de 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 nos snapshots programados e tome medidas corretivas. Para saber mais sobre como definir alertas, consulte 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 entre em ação para reconectar o aplicativo ao Redis o mais rápido possível.

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

Falha de snapshot e falha de recuperação

Falha no snapshot

Qualquer snapshot com falha é informado ao Cloud Monitoring, e uma nova tentativa é feita imediatamente. Falhas consecutivas de snapshot aumentam a quantidade de dados perdidos em caso de recuperação, porque os dados recuperados ficam cada vez mais desatualizados. Para saber como detectar e resolver problemas de falha de snapshot, consulte Monitorar snapshots.

Falha na recuperação

Falhas de recuperação são raras, mas podem acontecer. Se ocorrer uma falha na 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 RDB, siga as práticas recomendadas descritas abaixo:

Gerenciamento de memória

Os snapshots do RDB usam um fork de processo e um mecanismo de cópia na gravação para criar 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 afetadas pelas gravações forem copiadas. No pior caso, 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 para que 20% sejam reservados para sobrecarga. Consulte Práticas recomendadas de gerenciamento de memória para saber mais. Essa sobrecarga de memória, além dos snapshots de monitoramento, ajuda você 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á muito desatualizado ou que a instância passou por outras mudanças importantes que são difíceis de conciliar com o snapshot, desative e reative os snapshots do RDB. Isso exclui snapshots atuais, permitindo que você evite a recuperação de um snapshot desatualizado.

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

Recuperação prolongada de um snapshot

Recomendamos definir um alerta para a métrica redis.googleapis.com/server/uptime e receber uma notificação se a instância ficar indisponível.

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

Impacto na performance 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ível perda de dados que seu aplicativo pode tolerar, é possível minimizar o impacto na performance dos snapshots do RDB programando a execução deles durante períodos de baixo tráfego de instâncias.

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 para 3h e o intervalo para 24 horas.

Se o sistema tiver uma carga constante e exigir snapshots frequentes, avalie com cuidado o impacto na performance e pondere os benefícios de usar snapshots de 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 pode continuar com dificuldade de recuperação.

Para uma lista de métricas disponíveis para monitorar snapshots, consulte Métricas de snapshot do RDB. Para receber uma notificação de falha no snapshot, 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 falhas.

Monitorar o impacto na performance

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

A seguir