Nesta página, explicamos como o Memorystore para Valkey realiza a manutenção em instâncias. Ele também fornece informações e recomendações de configuração que seus aplicativos cliente devem conhecer para aproveitar O design do Memorystore para Valkey, que tem manutenção com inatividade zero. Essas recomendações se aplicam a instâncias altamente disponíveis e a instâncias sem réplicas. No entanto, recomendamos a configuração de alta disponibilidade para todos os casos de uso de produção.
O Memorystore para Valkey atualiza as instâncias regularmente para garantir que o serviço seja confiável, seguro, atualizado e tenha alto desempenho. Essas atualizações são chamadas de manutenção. A manutenção é totalmente gerenciada pelo serviço e foi projetada para não causar inatividade.
A manutenção normalmente se enquadra nas seguintes categorias:
- Recursos do Memorystore. Para lançar alguns recursos, o Memorystore exige uma atualização de manutenção.
- Patches do sistema operacional. Estamos sempre monitorando 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 de banco de dados. A manutenção pode incluir uma atualização do Valkey para melhorar as características de segurança, desempenho e confiabilidade da instância além do que o Valkey do OSS oferece.
Configurar seu aplicativo cliente
Para configurar o aplicativo cliente para ter o melhor desempenho e disponibilidade possível durante a manutenção, siga estas etapas:
- Use e configure seu cliente de terceiros de acordo com as orientações em Práticas recomendadas do cliente para garantir que a manutenção programada não afete o aplicativo cliente. Nossas configurações recomendadas de cliente podem evitar 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 escalonamento vertical, mudanças na contagem de réplicas) enquanto executa uma carga de trabalho representativa nos nós principais e de réplica e monitora o impacto no cliente. Essas atualizações testam a lógica de atualização da topologia inline nos clientes, o impacto da sincronização total, a descoberta de novos nós e o recurso de remoção de nós atuais. Os testes ajudam a garantir que o cliente de terceiros esteja configurado corretamente para evitar impactos negativos no aplicativo.
Manutenção programada
O Memorystore para Valkey aproveita uma estratégia de ciclo de vida de implantação gradual e criação antes da destruição para evitar impactos na inatividade da manutenção programada do Memorystore em suas instâncias Valkey. A manutenção sem inatividade é alcançada usando os recursos de redirecionamento de solicitação do protocolo de cluster OSS Valkey em conjunto com os seguintes mecanismos do Memorystore:
- Failover coordenado sem perda de dados
- Remoção de nós otimizada para permitir que os clientes acompanhem as atualizações da topologia de nós sem qualquer impacto na disponibilidade
- Os endpoints do PSC da instância não são afetados pela manutenção. Para mais informações sobre endpoints do PSC, consulte Endpoints de instância.
O comportamento do serviço descrito nas seções a seguir se aplica apenas à manutenção programada. Para 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 sua instância nas seguintes 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
Estratégia de implantações graduais
As implantações do Memorystore para Valkey são realizadas com um escopo progressivamente maior e em uma taxa que permite a detecção de falhas com antecedência suficiente para reduzir o impacto e estabelecer a confiança na estabilidade. Os tempos de cozimento (tempo durante o qual a atualização é aplicada e monitorada antes de ser considerada um sucesso e seguir em frente) são integrados à frota de instâncias do Memorystore na escala do serviço. Além disso, os tempos de preparação 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.
Na instância configurada para alta disponibilidade, no máximo um domínio/zona de falha é atualizado a qualquer momento para garantir que um fragmento de instância, incluindo o primário e as réplicas, tenha alta disponibilidade durante a atualização. Além disso, apenas alguns nós da Valkey são atualizados a qualquer momento. As atualizações usam um mecanismo de ciclo de vida de criação antes da destruição para maximizar a estabilidade da instância. Essa estratégia oferece mais benefícios ao atualizar uma instância com muitos fragmentos. Aplicar as atualizações apenas a uma pequena parte do keyspace geral do usuário em um determinado momento maximiza a disponibilidade dos dados.
Estratégia de ciclo de vida criar antes da destruição
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 réplica Valkey em um fragmento:
- O Memorystore para Valkey primeiro adiciona uma réplica completamente nova com a atualização mais recente do software ao fragmento. O Memorystore cria um nó totalmente novo, em vez de atualizar um já existente, para garantir que a capacidade provisionada seja mantida no caso de uma falha inesperada de inicialização.
- Se um nó dentro do fragmento a ser atualizado for um nó principal, ele será convertido em uma réplica antes da remoção usando um failover coordenado.
- O Memorystore remove a réplica que usa o software anterior.
- O processo é repetido para cada nó da instância.
A estratégia criar antes da destruição ajuda a manter a capacidade provisionada da instância, em comparação com uma implantação contínua típica que é atualizada no local, mas resulta em uma interrupção de disponibilidade (e às vezes em perda de dados) para o aplicativo cliente. No caso de 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 do fragmento.
Etapa 1: adicionar a réplica do Valkey
A primeira etapa do mecanismo criar antes da destruição é adicionar um nó de réplica com o software mais recente usando o mecanismo de sincronização completa OSS Valkey para copiar os dados do nó primário para o nó de réplica. Isso é feito bifurcando um processo filho e aproveitando a replicação sem disco para inicializar a réplica.
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 keyspace em um nó. Ter um conjunto de dados menor por nó ajuda a reduzir o impacto na latência da bifurcação de uma operação de sincronização completa. Ela também acelera a cópia de dados entre os nós.
Etapa 2: failover primário coordenado
Quando o nó Valkey que precisa ser atualizado é primário, o Memorystore primeiro executa um failover coordenado no nó de réplica recém-adicionado e, em seguida, realiza a remoção do nó. Durante o failover coordenado, o cliente e os nós Valkey trabalham juntos e usam as seguintes estratégias para evitar a inatividade do aplicativo:
- As solicitações recebidas do cliente são bloqueadas temporariamente no nó principal, fornecendo uma janela para garantir que a réplica atual seja 100% sincronizada com o nó principal.
- A réplica conclui o processo de eleição para assumir o papel principal.
- O nó principal anterior, agora uma réplica, desbloqueia as solicitações existentes e as redireciona para o primário recém-eleito usando o protocolo de cluster OSS Valkey. Todas as novas solicitações enviadas para o 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 precisa mais de redirecionamentos.
As failovers coordenadas geralmente levam dezenas de milissegundos. No entanto, os dados em trânsito pendentes de transmissão 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ão na eleição do novo primário.
Etapa 3: remover a réplica da Valkey
A última etapa do mecanismo criar antes da destruição é remover o nó da réplica no software anterior. A remoção abrupta de um nó afetaria os aplicativos clientes porque eles armazenam em cache as informações do endpoint e a topologia da instância. O Memorystore para Valkey projetou a remoção de uma réplica da Valkey para que fosse simples, a fim de permitir que os aplicativos clientes atualizem a topologia antes de sofrerem um encerramento forçado do nó. A topologia é personalizada para permitir que os clientes conheçam a nova réplica, mas também se esqueçam da que será removida com antecedência.
O nó réplica que executa o software anterior é mantido por um determinado período de drenagem, normalmente na ordem de minutos, durante o qual começa a redirecionar as solicitações de leitura recebidas para o nó principal do fragmento. Ela permite que o cliente de terceiros atualize a topologia do nó e aprenda sobre os novos endpoints da réplica. Se o cliente tentar alcançar um nó removido após o período de drenagem, a tentativa falhará, o que, por sua vez, acionará uma atualização da topologia do nó no cliente conectado para que ele aprenda sobre a alteração da réplica. As novas atualizações da topologia de nó não mostram o nó de réplica a ser removido.