Para o modelo de persistência do redis slave, existe uma maneira melhor diferente do rsync rdb de slave para master?

Question

O tamanho do rdb do meu dispositivo redis é de cerca de 1 GB. Meu aplicativo usa muito redis e não pode deixar o mestre manipular bgsave ou então, ele irá desacelerar todo o sistema na máquina do master. Então, eu tenho que evitar que o mestre faça o bgsave e só deixe o escravo fazer o trabalho de persistência.

O problema surge quando o mestre precisa ser reiniciado. Tem que copiar o rdb do escravo para carregar dados iniciais na memória. Esse processo levou cerca de 30 a 60 segundos. Se meus redis crescerem, o tempo para o processo será aumentado.

Eu tentei o NFS para permitir que o mestre e o escravo usem o mesmo rdb para ler / gravar mas o mestre da força do processo de replicação faça o bgsave na primeira vez que o escravo se conecta ao mestre e ele não pode fazer este trabalho porque o rdb de origem (mestre) e destino rdb (escravo) está no mesmo lugar.

A pergunta é "Existe uma maneira melhor de fazer esse carregamento inicial do rdb no trabalho de memória?".

    

Answer 1

A resposta curta é que não há nenhuma maneira inerentemente "mais rápida" de acelerar o carregamento de dados no Redis a partir do AOF ou do RDB. Talvez um pequeno aumento de discos mais rápidos, mas, como você observou, é uma operação de tempo linear.

A resposta longa é que você está atingindo os limites de sua arquitetura atual e seria bem repensado. Existem algumas opções neste cenário, abordadas na Web com algum detalhe (sua própria experiência terá que determinar qual solução funciona melhor para você.)

Algumas opções, mais complexas primeiro:

• 2-3 escravos e amp; failover automático, coordenado pelo ZooKeeper
• use o Redis Sentinel
• twemproxy

O particionamento de seus dados não ajudará você neste momento, IMO, já que seu conjunto de dados ainda é relativamente pequeno. No geral, é a disponibilidade e a coordenação do mestre que você precisa resolver, mantendo a persistência.

Finalmente, a resposta mais complexa acima envolve escalonamento horizontal. Você está passando por estresse sob BGSAVE com um único host & Um pequeno conjunto de dados: você deve considerar escalar verticalmente para resolver seu problema imediato (isto é, uma máquina mais potente para o mestre). Dessa forma você ignora completamente o problema de BGSAVE no slave / restart master / load do escravo, pelo menos por enquanto. Provavelmente também será mais rentável a curto prazo.