Nesta página, explicamos como o Memorystore para Valkey realiza a manutenção das instâncias. Ele também fornece informações e recomendações de configuração que os aplicativos cliente precisam conhecer para aproveitar o design de manutenção sem tempo de inatividade do Memorystore para Valkey. Essas recomendações se aplicam a instâncias altamente disponíveis e a instâncias sem réplicas. No entanto, para todos os casos de uso de produção, recomendamos que você use a configuração de alta disponibilidade.
O Memorystore para Valkey atualiza as instâncias rotineiramente para garantir que o serviço seja confiável, seguro, atualizado e tenha um bom desempenho. Essas atualizações são chamadas de manutenção. A manutenção é totalmente gerenciada pelo serviço e foi projetada para não ter impacto no tempo de inatividade.
A manutenção geralmente se enquadra nas seguintes categorias:
- Recursos do Memorystore. Para lançar alguns recursos, a Memorystore exige uma atualização de manutenção.
- Patches do sistema operacional. Monitoramos continuamente as vulnerabilidades de segurança recém-identificadas no sistema operacional. Após a descoberta, aplicamos um patch ao sistema operacional para proteger você contra novos riscos.
- Patches do banco de dados. A manutenção pode incluir uma atualização do Valkey para melhorar a segurança, o desempenho e a confiabilidade de uma instância. Isso vai além do que o Valkey OSS oferece.
Configurar o aplicativo cliente
Para configurar o aplicativo cliente e ter o melhor desempenho e disponibilidade durante a manutenção, siga estas etapas:
- Use e configure seu cliente de terceiros de acordo com as orientações em Práticas recomendadas para clientes do Valkey para garantir que nenhuma manutenção programada afete o aplicativo cliente. As configurações de cliente recomendadas evitam redefinições de conexão com atualizações periódicas de topologia inline e rotações de conexão em segundo plano.
- Teste o aplicativo cliente com uma série de operações de atualização (como reduzir escalonamento horizontal ou horizontal, ou mudanças na contagem de réplicas) enquanto executa uma carga de trabalho representativa nos nós primários e de réplica, monitorando o impacto no cliente. Essas atualizações testam a lógica de atualização da topologia inline em clientes, o impacto da sincronização completa, a descoberta de novos nós e a capacidade de remoção de nós atuais. Os testes ajudam a garantir que o cliente de terceiros esteja configurado corretamente para evitar qualquer impacto negativo no seu aplicativo.
Manutenção programada
O Memorystore para Valkey usa uma implantação gradual e uma estratégia de ciclo de vida criar antes de destruir para evitar qualquer impacto de tempo de inatividade da manutenção programada do Memorystore nas suas instâncias do Valkey. O Memorystore para Valkey realiza a manutenção sem tempo de inatividade usando os recursos de redirecionamento de solicitações do protocolo de instância do Valkey OSS com os seguintes mecanismos do Memorystore:
- Um failover coordenado sem perda de dados.
- Uma remoção normal do nó para permitir que os clientes acompanhem as atualizações da topologia do nó sem impacto na disponibilidade.
- Os endpoints do Private Service Connect da instância, que não são afetados pela manutenção. Para mais informações sobre esses endpoints, consulte Endpoints de instância.
O comportamento do serviço descrito nas seções a seguir se aplica apenas à manutenção programada. Para mais informações sobre o impacto de eventos não planejados, como falhas de hardware, consulte Comportamento do cliente durante um failover não planejado.
Janelas de manutenção padrão
Por padrão, o Memorystore atualiza a instância nas seguintes janelas de acordo com o fuso horário dela:
- Período da semana (de segunda a sexta-feira): das 22h às 6h
- Janela de fim de semana: sexta-feira, das 22h à segunda-feira, às 6h
Estratégia de implantação gradual
O Memorystore para Valkey realiza implantações com um escopo progressivamente crescente e a uma taxa que permite a detecção de falhas com antecedência suficiente para reduzir qualquer impacto e estabelecer confiança na estabilidade. Os tempos de espera (o período em que a atualização é aplicada e monitorada antes de ser considerada um sucesso e seguir em frente) são integrados em toda a frota de instâncias do Memorystore na escala do serviço. Além disso, os tempos de espera são integrados às instâncias em todas as zonas de uma região (vários domínios de falha) para reduzir o escopo do impacto, se houver.
Para sua instância configurada para alta disponibilidade, no máximo, o Memorystore para Valkey atualiza um domínio de falha ou uma zona por vez para garantir que um fragmento de instância, incluindo réplicas primárias e secundárias, tenha alta disponibilidade durante toda a atualização. Além disso, o Memorystore para Valkey atualiza apenas alguns nós por vez. As atualizações usam um mecanismo de ciclo de vida criar antes de destruir para maximizar a estabilidade de uma instância. Essa estratégia oferece mais benefícios ao atualizar uma instância com muitos shards. Aplicar as atualizações a uma pequena parte do espaço de chaves do usuário a qualquer momento maximiza a disponibilidade de dados.
Estratégia de ciclo de vida "create-before-destroy"
Uma instância do Valkey tem vários fragmentos. Cada fragmento tem um nó principal e zero ou mais nós de réplica. O Memorystore usa o seguinte processo para atualizar qualquer nó principal ou de réplica do Valkey em um fragmento:
- O Memorystore para Valkey adiciona uma nova réplica com a atualização de software mais recente ao fragmento. O Memorystore cria um novo nó, em vez de atualizar um nó existente, para garantir que a capacidade provisionada seja mantida se ocorrer uma falha inesperada de bootstrap.
- Se um nó no fragmento a ser atualizado for um nó principal, ele será convertido em uma réplica antes de ser removido usando um failover coordenado.
- O Memorystore remove a réplica que usa o software anterior.
- Para cada nó na instância, o Memorystore repete esse processo.
A estratégia de criação antes da destruição ajuda a manter a capacidade provisionada da instância, em comparação com uma implantação rotativa típica que atualiza no local, mas resulta em uma interrupção de disponibilidade (e às vezes perda de dados) para o aplicativo cliente. Para fragmentos sem réplicas, o Memorystore para Valkey ainda provisiona uma nova réplica primeiro, coordena o failover e, por fim, substitui o nó principal atual do fragmento.
Etapa 1: adicionar uma réplica
A primeira etapa do mecanismo de criação antes da destruição é adicionar um nó de réplica com o software mais recente usando o mecanismo OSS Valkey de sincronização completa para copiar os dados do nó primário para o de réplica. Isso é feito ramificando um processo filho e aproveitando a replicação sem disco para inicializar a réplica. O Memorystore para Valkey é compatível com a replicação sem disco. A menos que você ative a persistência, o Memorystore para Valkey não usa discos durante a replicação.
Para aproveitar ao máximo a arquitetura de escalonamento horizontal da instância, provisione um número maior de fragmentos para reduzir o tamanho do espaço de chaves em um nó. Ter um conjunto de dados menor por nó ajuda a reduzir o impacto da latência de fork de uma operação de sincronização completa. Ele também acelera a cópia de dados entre os nós.
Etapa 2: executar um failover primário coordenado
Se o nó do Valkey que precisa ser atualizado for um nó principal, o Memorystore vai executar um failover coordenado para o nó de réplica recém-adicionado. Em seguida, o Memorystore remove o nó. Durante o failover coordenado, o cliente e os nós do Valkey trabalham juntos e usam as seguintes estratégias para evitar tempo de inatividade do aplicativo:
- As solicitações de clientes recebidas são bloqueadas temporariamente no nó principal, oferecendo uma janela para garantir que a réplica atual esteja 100% sincronizada com o nó principal.
- A réplica conclui o processo de eleição para assumir a função principal.
- O nó principal anterior, agora um nó de réplica, desbloqueia as solicitações atuais e as redireciona para o novo nó principal usando o protocolo de instância do Valkey OSS. Todas as novas solicitações enviadas ao nó de réplica anterior continuam sendo redirecionadas para o novo nó principal.
- Seu cliente compatível com o Valkey atualiza a topologia na memória. Ele aprende o endereço do novo endpoint principal e não exige mais redirecionamentos.
Os failovers coordenados geralmente levam dezenas de milissegundos. No entanto, os dados em trânsito pendentes de serem liberados para réplicas e o tamanho total da instância podem aumentar a latência de failover. O tamanho da instância pode afetar a convergência entre os nós principais, o que afeta a tomada de decisões sobre a eleição do novo nó principal.
Etapa 3: remover a réplica
A última etapa do mecanismo de criação antes da destruição é remover o nó de réplica no software anterior. Uma remoção abrupta de nós teria impacto nos aplicativos clientes, porque eles armazenam em cache as informações do endpoint e a topologia da instância. A Memorystore para Valkey foi projetada para remover uma réplica do Valkey de forma gradual, permitindo que os aplicativos cliente atualizem a topologia antes de sofrerem um desligamento forçado do nó. A topologia é personalizada para permitir que os clientes conheçam a nova réplica, mas também esqueçam a que será removida com antecedência.
O nó de réplica que executa o software anterior é mantido por um determinado período de drenagem, geralmente da ordem de minutos, durante o qual ele começa a redirecionar as solicitações de leitura recebidas para o nó principal do shard. Ele permite que o cliente de terceiros atualize a topologia do nó e saiba mais sobre os novos endpoints de réplica. Se o cliente tentar acessar um nó removido após o período de drenagem, a tentativa vai falhar. Isso aciona uma atualização da topologia de nós no cliente de conexão para que ele saiba sobre a mudança de réplica. Novas atualizações da topologia de nós não mostram o nó de réplica a ser removido.
Configurações de manutenção
Com o Memorystore para Valkey, é possível personalizar os programações de manutenção para alinhar com as necessidades do aplicativo e minimizar as interrupções. Para personalizar uma programação de manutenção, configure uma janela de manutenção para sua instância.
Você define janelas de manutenção para cada instância do Memorystore para Valkey e tem as seguintes opções de configuração:
- Dia da semana: o dia em que a manutenção ocorre
- Hora de início: a hora em que a manutenção começa
A janela de manutenção dura uma hora. Em alguns casos, a manutenção pode durar mais do que o período selecionado.
Depois de configurar uma janela de manutenção para uma instância, o Memorystore para Valkey agenda a manutenção automática no futuro de acordo com as preferências definidas para as janelas de manutenção.
Janelas de manutenção padrão
Se você não definir uma janela de manutenção, o Memorystore for Valkey vai atualizar a instância em uma das seguintes janelas, de acordo com o fuso horário da instância:
- Período da semana (de segunda a sexta-feira): das 22h às 6h
- Janela de fim de semana: sexta-feira, das 22h à segunda-feira, às 6h
Exemplo de manutenção
Como desenvolvedor que gerencia um serviço de carrinho de compras em um varejista, você supervisiona um ambiente de produção que inclui uma instância do Memorystore para Valkey. Para garantir o desempenho ideal durante a manutenção, programe-a para quando a instância tiver o mínimo de tráfego. Isso geralmente acontece por volta da meia-noite aos domingos.
Nesse caso, defina a janela de manutenção da instância de produção para o seguinte dia e horário:
- Dia da semana: domingo
- Hora de início: 1h
Notificações de manutenções futuras
Para ficar por dentro dos eventos de manutenção na sua instância, configure
notificações por e-mail sobre a manutenção futura pelo menos uma semana antes
da data programada. Essas notificações têm a linha de assunto "Upcoming
maintenance for your Cloud Memorystore instance [your-instance-name]".
O Memorystore para Valkey também envia uma notificação quando a manutenção da sua instância começa. O assunto do e-mail é "Maintenance
is undergoing for your Cloud Memorystore instance [your-instance-name]".
Depois que a manutenção do Memorystore para Valkey é concluída, ele envia uma notificação de conclusão. O assunto do e-mail é "Completed Maintenance
for your Cloud Memorystore instance [your-instance-name]".
Se o Memorystore para Valkey reagendar a manutenção, você vai receber um e-mail informando sobre o cancelamento. O assunto deste e-mail é "Canceled maintenance for your Cloud Memorystore instance [your-instance-name]".
Para receber notificações de manutenção, é necessário ativar essa opção. Para se inscrever nas notificações de manutenção, faça o seguinte:
Para receber notificações de manutenção da Memorystore para Valkey, conclua estas etapas pelo menos uma semana antes da atualização de manutenção programada para sua instância. Caso contrário, o Memorystore para Valkey não terá tempo suficiente para notificar você sobre a manutenção.
O Memorystore para Valkey envia notificações para o endereço de e-mail associado à sua Conta do Google. Não é possível configurar um alias de e-mail personalizado (por exemplo, um alias de e-mail de equipe). Além disso, não é possível enviar notificações para um endereço de e-mail diferente.
Ao se inscrever nas notificações de manutenção, você recebe alertas para todas as instâncias do Memorystore para Valkey que têm manutenção programada em um projeto Google Cloud . Para cada instância, você recebe uma notificação separada.
Para mais informações sobre como encontrar uma manutenção programada, consulte Encontrar uma manutenção programada.
Reprogramar manutenção
Nesta seção, fornecemos diretrizes sobre como reagendar a manutenção. Por exemplo, se um novo serviço estiver programado para ser lançado durante sua janela de manutenção atual, convém adiar a janela de manutenção para alguns dias após o lançamento.
É possível reprogramar a manutenção em até 14 dias após o horário programado originalmente. Como parte do reagendamento da manutenção, escolha uma das seguintes opções:
- Atualizar agora: em vez de esperar a janela de manutenção programada, é possível aplicar as atualizações à instância imediatamente.
- Dia e horário personalizados: escolha qualquer horário em até duas semanas após o horário de manutenção programado originalmente.
Ao reagendar a manutenção, as seguintes restrições são aplicadas:
- Se houver menos de uma hora antes do horário programado para a manutenção, não será possível reprogramá-la.
- Depois de reagendar a manutenção, o Memorystore para Valkey envia uma notificação por e-mail confirmando o cancelamento da manutenção anterior. Além disso, você vai receber uma nova notificação de manutenção com a programação atualizada.
Para mais informações sobre como reprogramar a manutenção, consulte Reprogramar a manutenção.
Perguntas frequentes
Esta seção contém perguntas frequentes sobre a manutenção do Memorystore para Valkey.
Como saber quando a manutenção está programada para sua instância?
Para saber quando a manutenção está programada para sua instância, recomendamos que você
se inscreva nas notificações e configure uma janela de manutenção. Você também pode verificar sua instância manualmente para saber se o parâmetro maintenanceSchedule aparece na resposta.
Quando o Memorystore para Valkey notifica você sobre as próximas manutenções?
Se você se inscrever para receber notificações de manutenção e definir uma janela de manutenção, o Memorystore para Valkey vai enviar um e-mail pelo menos uma semana antes de um evento de manutenção.
Por quanto tempo posso adiar a manutenção?
Depois de programar a manutenção para a instância, você pode iniciar a atualização imediatamente ou adiá-la por até duas semanas a partir da data e hora de manutenção programadas originalmente.
Por exemplo, se você programar a manutenção para 11 de outubro às 23h15, será possível adiar até 25 de outubro às 23h15. Se você não fizer nada, a manutenção será executada na data e hora programadas.
Para mais informações, consulte Reprogramar manutenção.
Quais práticas recomendadas resultam em uma experiência de atualização de manutenção tranquila?
Para garantir uma experiência de atualização de manutenção sem problemas, recomendamos que você faça o seguinte:
- Siga as instruções para configurar seu aplicativo cliente.
- Defina a janela de manutenção para um dia e horário em que a instância tenha o mínimo de tráfego (por exemplo, domingos à meia-noite).
- Ative o recebimento de notificações de manutenção. Por isso, o Memorystore para Valkey envia uma notificação por e-mail pelo menos sete dias antes de uma atualização de manutenção ser programada para sua instância.
- Se você não tiver um horário de baixo ou nenhum impacto para o uso do aplicativo, use o padrão de serviço dos lançamentos graduais. Esse padrão contém práticas recomendadas para atualizações de manutenção. Para mais informações, consulte Manutenção programada.
Quando posso aplicar a manutenção imediatamente?
É possível aplicar uma atualização de manutenção imediatamente em uma instância de teste para ver como ela afeta seu aplicativo. Você pode observar o impacto dessa atualização. Se houver problemas com a atualização, adie a manutenção nas instâncias de produção até que eles sejam resolvidos.
Se o dia e a hora atuais forem adequados para sua instância e você esperar uma carga alta nela no futuro, execute a atualização de manutenção imediatamente.
As atualizações de manutenção sempre são concluídas dentro da janela de manutenção?
O Memorystore para Valkey inicia uma atualização de manutenção dentro da janela de manutenção especificada. O Memorystore for Valkey geralmente conclui a atualização dentro da janela, mas isso nem sempre acontece.
Posso desativar a manutenção ou programar a manutenção em determinadas instâncias primeiro?
Não é possível desativar a manutenção nem controlar a ordem dela para suas instâncias. No entanto, depois de receber a notificação inicial, é possível reprogramar a manutenção para adiar por até duas semanas.
A seguir
- Confira as permissões necessárias para gerenciar janelas de manutenção da sua instância.