Compreender o backlog de replicação do Redis: PSYNC, tamanho e limites de alta disponibilidade

O Atraso na replicação do Redis determina, entre outros fatores, se, após uma interrupção da ligação, uma réplica deve apenas recuperar as alterações em falta ou se deve receber novamente todo o conjunto de dados. Quem dimensionar o buffer de acordo com o volume real de replicação pode evitar sincronizações completas desnecessárias. Para tal, porém, o histórico de replicação, o orçamento de armazenamento e os processos operacionais têm de estar em sintonia: um grande atraso não substitui nem a persistência nem um conceito de failover robusto.

O que o backlog realmente armazena

Em Replicação do Redis O servidor primário processa as alterações na base de dados e transmite um fluxo contínuo de comandos às suas réplicas. Isto não inclui apenas os valores gravados diretamente pelos clientes. Também as chaves expiradas ou substituídas podem desencadear alterações que têm de ser transmitidas. O backlog mantém na memória uma amostra limitada e recente desse fluxo de replicação. Por isso, não contém nenhuma cópia completa adicional da base de dados, nem constitui um arquivo de operações de gravação de qualquer idade.

Em condições normais de funcionamento, as réplicas acompanham o fluxo de dados. Se uma ligação for interrompida, o histórico continua a crescer no primário. Após o restabelecimento da ligação, a réplica tenta retomar a partir do ponto em que se encontrava. O fator decisivo é, então, se os bytes necessários ainda se encontram armazenados. Se for esse o caso e o histórico de replicação corresponder, o Redis pode preencher a lacuna. Para tal, não é necessário substituir na totalidade os dados já existentes na réplica.

A vantagem reside especialmente em pequenas falhas de rede, mudanças de ligação e trabalhos de manutenção programados. Uma sincronização completa de um grande conjunto de dados exige capacidade de transmissão e potência de computação; dependendo da configuração, acrescentam-se ainda outras cargas sobre a memória e os suportes de dados. O backlog pode reduzir este esforço, mas não consegue compensar todos os tipos de interrupção. Um reinício do processo ou uma alteração no histórico requer uma abordagem diferente daquela aplicada a uma ligação TCP que tenha estado temporariamente interrompida.

Quando basta o PSYNC e quando é necessária uma ressincronização completa

A ressincronização parcial com PSYNC requer dois dados interligados: o ID de replicação e o deslocamento. O ID identifica um determinado histórico de dados. O deslocamento descreve uma posição em bytes dentro do fluxo de replicação. Por isso, dois offsets de igual tamanho, provenientes de históricos diferentes, não são automaticamente comparáveis. Por outro lado, um pequeno atraso no mesmo histórico pode já estar fora do backlog disponível, caso a capacidade deste seja limitada.

Em termos simples, quando se restabelece a ligação, a réplica indica até que ponto chegou. O primário verifica se consegue fornecer os dados necessários a seguir. Se o histórico for desconhecido ou se faltar a secção necessária, é gerado um Sincronização completa necessário. Nesse processo, a réplica recebe um conjunto completo de dados e, posteriormente, as alterações ocorridas durante a sincronização. A transferência pode ser efetuada, dependendo da configuração, com uma etapa intermédia no RDB para um suporte de dados ou sem essa etapa intermédia.

Após um failover, uma ressincronização completa não é inevitável em todos os casos. Uma réplica promovida pode, além disso, memorizar o ID de replicação anterior e o seu intervalo de deslocamento válido. Desta forma, outras réplicas podem, sob condições adequadas, ligar-se ao histórico conhecido. No entanto, isto não constitui qualquer garantia para efeitos de planeamento: o intervalo relevante tem de continuar disponível e a reconexão concreta tem de corresponder aos IDs guardados.

Medir a taxa de replicação em vez de estimar o tamanho da base de dados

A mera dimensão do conjunto de dados é suficiente para Dimensionamento da carteira de trabalhos não é suficiente. Uma base de dados grande, na qual predominam as operações de leitura, pode gerar pouco tráfego de replicação. Por outro lado, uma cache pequena com valores que mudam frequentemente e muitos eventos de expiração pode transmitir continuamente volumes consideráveis de dados. Mesmo um número fixo de operações por segundo descreve de forma insuficiente a memória necessária: pequenas alterações de chaves e grandes substituições de valores não resultam no mesmo volume de bytes.

Uma aproximação útil na prática resulta do aumento ao longo do tempo de master_repl_offset. Regista o valor duas vezes no mesmo servidor primário e divide a diferença pelos segundos decorridos. Verifica também o ID de replicação. Após uma troca de funções ou um reinício, não deves simplesmente subtrair dois pontos de medição não relacionados entre si. Além disso, um único intervalo de medição fornece apenas uma taxa média dentro desse intervalo, e não um limite máximo garantido de forma permanente.

A consulta seguinte lê informações de diagnóstico. Não altera a configuração do Redis. Execute-a com as opções de ligação e autenticação necessárias no seu ambiente. A chamada apresentada abaixo utiliza a ligação padrão de redis-cli; é necessário definir expressamente outro servidor, porta ou acesso TLS.

redis-cli INFO replication

Faça medições ao longo de diferentes fases de carga, por exemplo, durante o funcionamento normal do dia-a-dia, nas importações e durante renovações de cache de grande dimensão. Registe tanto as taxas típicas como os picos de curta duração. Se ocorrerem muitas alterações devido ao vencimento de chaves, o artigo interno pode servir como aprofundamento do tema Analisar a expiração das chaves do Redis. Esta relação é importante para o planeamento, porque nem todos os impulsos de escrita relevantes resultam diretamente de um novo pedido do utilizador.

Calcular de forma compreensível a dimensão da carteira de encomendas

Como Abordagem de planeamento podes multiplicar a taxa de replicação relevante pela duração da interrupção a contornar e, em seguida, acrescentar uma reserva justificada. A duração não deve ter em conta apenas a interrupção da rede propriamente dita. A deteção, as tentativas de restabelecimento da ligação e a recuperação do caminho de ligação também podem demorar algum tempo. A reserva adequada depende das flutuações observadas e do objetivo operacional pretendido, e não de uma percentagem universal.

Um exemplo de cálculo deliberadamente simplificado: para uma fase de carga em análise, considera-se 12 MiB por segundo. A ligação poderá estar indisponível durante 90 segundos; prevêem-se mais 30 segundos como reserva de tempo. Daí resulta que 12 MiB/s × 120 s = 1.440 MiB, ou seja, cerca de 1,41 GiB. Estes números são valores estimados para fins ilustrativos e não constituem um teste de desempenho do Redis. Antes de uma implementação em produção, devem ser substituídos por valores medidos na tua aplicação.

O cálculo inverso ajuda a avaliar um buffer existente. Um backlog totalmente preenchido com 256 MiB corresponde, matematicamente, a cerca de 21 segundos de histórico, mantendo-se uma taxa constante de 12 MiB por segundo. A uma taxa de 2 MiB por segundo, seriam cerca de 128 segundos. No entanto, numa aplicação real, as taxas variam. Por isso, tal estimativa é apenas um instantâneo e não constitui uma garantia de que qualquer falha com essa duração possa ser parcialmente sincronizada.

Verifica também se, após restabelecer a ligação, a réplica consegue recuperar o atraso mais rapidamente do que as novas alterações surgem. A eliminação de mais histórico não resolve nem o problema de uma rede permanentemente lenta nem o de um destinatário permanentemente sobrecarregado. Se o atraso persistir ou continuar a aumentar, é necessário investigar a causa. Caso contrário, prever cada vez mais espaço de armazenamento apenas adia o problema e pode colocar todo o sistema sob pressão de espaço de armazenamento.

Alterar a configuração do Redis de forma compreensível e controlada

Os parâmetros repl-backlog-size e repl-backlog-ttl controlam aspetos diferentes. O primeiro descreve o tamanho previsto do backlog. O segundo determina, no servidor primário, após quanto tempo sem réplicas ligadas é que o backlog pode ser libertado. É Não existe um tempo máximo de interrupção para o PSYNC. Enquanto o buffer for sobrescrito ou faltar outro pré-requisito, um TTL longo, por si só, não resolve o problema.

As linhas seguintes são definições comentadas retiradas do modelo de configuração do Redis 7.2.0. Os símbolos de comentário foram mantidos intencionalmente. A simples cópia destas linhas não ativa quaisquer definições; além disso, os valores mencionados não constituem uma recomendação geral de capacidade para sistemas em produção.

# Redis 7.2.0: auskommentierte Vorgaben aus redis.conf
# repl-backlog-size 1mb
# repl-backlog-ttl 3600

Com repl-backlog-ttl 0 A libertação temporizada é desativada após a desconexão de todas as réplicas. Isto não conserva um histórico ilimitado: o buffer existente pode continuar a ser substituído por novos dados de replicação. Além disso, isto não garante a persistência após quaisquer reinícios do processo. Por isso, avalie cuidadosamente se o consumo adicional de memória se adequa ao comportamento de reconexão esperado.

Antes de efetuar qualquer alteração, deve verificar os valores efetivamente em vigor e esclarecer o procedimento de implementação. Uma variável de ambiente do contentor, um ficheiro de configuração gerido e uma definição alterada em tempo de execução não são a mesma coisa. Se uma instância for recriada posteriormente, apenas as alterações efetuadas em tempo de execução poderão ser perdidas. As consultas seguintes são de leitura; no entanto, requerem os direitos de acesso adequados.

redis-cli CONFIG GET repl-backlog-size
redis-cli CONFIG GET repl-backlog-ttl

No caso do Managed Redis, o fornecedor pode restringir o acesso a CONFIG limitar ou gerir as definições através de uma interface própria. Isso não é motivo para contornar os mecanismos de proteção. Nesse caso, utilize os canais de gestão autorizados e documente o tamanho selecionado, juntamente com o volume de replicação subjacente. No plano de alteração, devem também ser registados os valores atuais e um plano de reversão realista.

Monitorização: Que valores estão relacionados entre si

Para a Monitorização da replicação do Redis Um único estado de ligação verde não é suficiente. Uma ligação pode estar restabelecida enquanto a réplica ainda está a recuperar o atraso ou a carregar um conjunto completo de dados. Por outro lado, uma breve interrupção da ligação não tem de ser imediatamente crítica, se o histórico e a capacidade de recuperação forem suficientes. Por isso, avalie em conjunto a ligação, o estado de sincronização, a evolução do desfasamento e o histórico disponível.

Os campos de uma INFO-As respostas podem variar entre versões do Redis e entre o servidor principal e a réplica. Por isso, uma análise deve tratar explicitamente os campos em falta, em vez de os interpretar tacitamente como nulos ou como um estado sem erros. Também as designações master e slave continuam a aparecer nos nomes dos campos por motivos de compatibilidade; não devem ser traduzidos livremente no código executável.

Para a interpretação do atraso, deve consultar-se o guia interno Analisar o deslocamento de replicação do Redis um complemento adequado. No acompanhamento contínuo, deves ter em conta os padrões históricos, e não apenas dois valores lidos manualmente. Uma distância crescente exige uma reação diferente daquela necessária quando a diferença vai diminuindo constantemente após uma breve interrupção.

Os alarmes úteis orientam-se pelos teus objetivos operacionais: durante quanto tempo é que uma réplica pode ficar inacessível? Com que rapidez é que ela tem de recuperar o atraso? Que frequência de sincronizações completas é considerada invulgar? Limites rígidos, sem ter em conta o perfil de carga e o volume de dados, conduzem frequentemente a notificações desnecessárias ou fazem com que se ignorem deteriorações reais. Além das métricas de replicação, mantém também sob vigilância a utilização da RAM, a utilização da rede e os indícios de reinícios de processos.

Como avaliar corretamente o orçamento de armazenamento e as réplicas lentas

A carteira de encomendas é apenas uma parte do total Necessidades de memória do Redis. A isto acrescentam-se o conjunto de dados, as estruturas administrativas, os buffers do cliente e, dependendo do estado de funcionamento, memória adicional durante os processos de persistência ou sincronização. Por isso, não reserve toda a memória de trabalho disponível para dados úteis e para um backlog calculado com exatidão. A reserva necessária deve ser determinada com base no ambiente específico e nos picos de carga que aí ocorrem.

Desde o Redis 7.0 que o Replica Buffer e o Replication Backlog partilham memória. Por isso, a documentação INFO refere, entre outras coisas, que mem_clients_slaves pode ser nulo se os buffers de réplica não excederem a ocupação do backlog. Isso não significa, contudo, que a replicação não ocupe memória. Considere os valores previstos para esse efeito, tais como mem_replication_backlog e mem_total_replication_buffers no contexto e não some cegamente valores que se sobrepõem.

Um erro de diagnóstico frequente consiste em atribuir cada sincronização interrompida a um atraso acumulado significativo. Réplicas lentas, largura de banda de rede limitada ou limites do buffer de saída excedidos podem ter outras causas. O parâmetro client-output-buffer-limit replica refere-se à classe de cliente em questão e não deve ser confundida com repl-backlog-size ser equiparados. Antes de alterar os limites, verifica os registos, a documentação da versão e os impactos previsíveis noutras ligações.

Por que razão um grande volume de trabalho em atraso ainda não garante uma elevada disponibilidade

O backlog melhora a reconexão, mas não torna a replicação, que é assíncrona por predefinição, isenta de perdas. Um servidor primário pode já ter confirmado uma operação de gravação ao cliente antes de uma réplica a ter processado. Se o servidor primário falhar durante esse período, é possível que a operação em questão não esteja presente no sistema substituto selecionado posteriormente. O tamanho do buffer, por si só, não resolve este problema Risco de perda de dados durante o failover não.

Também WAIT não transforma uma topologia Redis num sistema com consistência forte garantida. O comando pode aguardar confirmações das réplicas; a segurança efetiva dos dados continua a depender de outras circunstâncias, nomeadamente do comportamento de persistência e de failover. Da mesma forma, limitam min-replicas-to-write e min-replicas-max-lag aceitar novas operações de gravação, de acordo com as respetivas condições, sem guardar automaticamente e de forma permanente cada operação individual em várias instâncias.

Para Alta disponibilidade Por isso, é necessária uma decisão coerente: perda de dados tolerável, tempo de inatividade admissível, persistência, deteção de falhas, seleção do novo primário e recuperação. O Sentinel ou o Redis Cluster podem assumir outras tarefas além do backlog. Quem se limita a aumentar o tamanho de um buffer e mantém todas as restantes premissas inalteradas ainda não dispõe de um plano de reinício fiável.

Testar alterações e identificar problemas recorrentes

Inicie um teste controlado num ambiente isolado com uma versão comparável do Redis e uma carga de escrita previsível. Registe os IDs de replicação, os offsets, o volume de trabalho em atraso e o consumo de memória antes da interrupção. Em seguida, simule uma interrupção limitada da ligação, sem alterar firewalls ou processos de produção sem verificação prévia. Após o restabelecimento da ligação, observe se ocorre uma sincronização parcial ou total e quanto tempo demora a recuperação.

Altere, sempre que possível, apenas uma variável relevante por teste. Se o backlog, a carga de escrita e as condições da rede mudarem simultaneamente, será difícil determinar a causa do efeito. Repita o teste com diferentes durações de interrupção e diferentes fases de carga. Desta forma, uma única reconexão bem-sucedida transforma-se numa avaliação compreensível do comportamento. Os limites observados devem ser documentados, sem que se deduza disso uma garantia para qualquer falha futura.

Em caso de ressincronizações completas repetidas, verifica-se primeiro se o histórico é, de todo, compatível. Em seguida, analisam-se os bytes ainda pendentes, o tempo sem réplica, as indicações de reinícios e a velocidade real de recuperação. Um buffer demasiado pequeno é uma causa possível, mas não a única. É particularmente importante distinguir entre uma lacuna pontual demasiado longa e uma réplica que fica permanentemente atrasada, mesmo com ligação ativa.

A configuração correta é, em última análise, aquela que cobre a janela de falha que definiste com uma carga realista e deixa memória suficiente para o restante funcionamento. Regista em conjunto a base de medição, a fonte de configuração e a data da verificação. Após alterações significativas no comportamento de escrita, na topologia ou na versão do Redis, o dimensionamento deve ser novamente revisto. Desta forma, o backlog continua a ser uma decisão operacional fundamentada, em vez de um valor simplesmente adotado.