Princípio de replicação mestre-escravo preliminar de alta disponibilidade do Redis

Princípio de replicação mestre-escravo preliminar de alta disponibilidade do Redis

(1) O que é replicação mestre-escravo

A replicação mestre-escravo refere-se à cópia dos dados de um servidor redis para outros servidores redis. O primeiro é chamado de mestre e o último é chamado de escravo. A replicação de dados é unilateral, apenas do nó mestre para o nó escravo. O nó mestre é responsável pelas operações de gravação e o nó escravo é responsável pelas operações de leitura. A replicação mestre-escravo implanta várias cópias de dados em outros nós, alcançando assim alta disponibilidade de redis, alcançando backup redundante de dados e garantindo alta confiabilidade de dados e serviços.

Simplificando, a função principal da replicação mestre-escravo é garantir a confiabilidade dos dados. No caso de tempo de inatividade do servidor devido a falha de energia ou danos ao disco rígido, o backup de dados de vários nós da replicação mestre-escravo pode ser muito conveniente e rápido para recuperação de dados. Além de garantir a confiabilidade, a replicação mestre-escravo tem outras funções:

1. Redundância de dados: a replicação mestre-escravo realiza backup a quente de dados, que é um método de redundância de dados além da persistência.
2. Recuperação de falha: Quando o nó mestre tem um problema, o nó escravo pode fornecer serviços para obter uma recuperação rápida de falha.
3. Balanceamento de carga: Com base na replicação mestre-escravo, com a separação de leituras e gravações, o nó mestre pode fornecer serviços de gravação e os nós escravos fornecem serviços de leitura para compartilhar a carga do servidor, especialmente no cenário de menos gravações e mais leituras. Um nó escravo compartilha a carga de leitura, o que pode aumentar muito a simultaneidade do servidor Redis.
4. A pedra angular da alta disponibilidade: a replicação mestre-escravo é a base para a implementação de sentinelas e clusters, portanto, a replicação mestre-escravo é a base para a alta disponibilidade do Redis.

(2) Três estágios de replicação mestre-escravo

O fluxo de trabalho completo da replicação mestre-escravo é dividido nos três estágios a seguir, cada um com seu próprio fluxo de trabalho interno. Em seguida, estudaremos esses três processos.

1. O processo de estabelecer uma conexão: o processo de conectar o escravo ao mestre
2. Processo de sincronização de dados: o processo de sincronização de dados do mestre para o escravo
3. Processo de propagação do comando: o mestre sincroniza repetidamente os dados com o escravo

1. Estabelecendo o processo de conexão

Estabelecer uma conexão é a primeira etapa da replicação mestre-escravo. Fale brevemente sobre o fluxo de trabalho da fase de estabelecimento da conexão:

1. O escravo define o endereço e a porta do mestre e salva as informações do mestre
2. Estabeleça uma conexão de soquete
3. Envie comandos de ping continuamente
4. Autenticação
5. Envie informações da porta escrava para o mestre

Obviamente, no processo de estabelecimento de uma conexão, o nó escravo salva o endereço e a porta do mestre, e o nó mestre mestre salva a porta do nó escravo. Aqui está o fluxograma:

2. Processo de sincronização de dados

Quando o nó escravo se conecta ao nó mestre pela primeira vez, ele executa uma cópia completa primeiro.Esta cópia completa é inevitável, embora a cópia completa exija muitos recursos. Depois que a cópia completa for executada, o nó mestre enviará os dados do buffer de cópia para o nó escravo e, em seguida, o nó escravo executará o comando bgrewriteaof para restaurar os dados, que também é uma cópia parcial. Aqui está o fluxograma:

3. Fase de propagação do comando

Quando o banco de dados mestre é modificado e os dados dos servidores mestre e escravo são inconsistentes, os dados mestre e escravo são sincronizados para serem consistentes neste momento.Este processo é chamado de propagação de comando. O mestre enviará o comando de mudança de dados recebido ao escravo, e o escravo executará o comando após receber o comando para tornar os dados mestre-escravo consistentes.

(3) Cópia integral e cópia parcial

Vamos falar sobre cópia completa e cópia parcial em detalhes abaixo:

1. O nó escravo envia o comando psync? 1 psync runid offset para encontrar o nó do runid correspondente para solicitar dados, mas há um problema aqui. Quando o nó escravo se conecta pela primeira vez, o runid e o deslocamento do nó mestre não são conhecidos. Então, o primeiro comando enviado é psync? 1. Isso significa que todos os dados do nó mestre precisam ser sincronizados.
2. O nó mestre começa a executar o bgsave para gerar um arquivo RDB e registra o deslocamento da cópia atual.
3. O nó mestre envia seu runid e deslocamento para o nó escravo por meio do comando + FULLRESYNC runid deslocamento e, em seguida, envia o arquivo RDB por meio do soquete para o nó escravo. Nesse estágio, o nó mestre pode receber instruções do cliente e o deslocamento foi alterado.
4. O nó escravo recebe o runid e o deslocamento do nó mestre e os salva, depois limpa todos os dados atuais do banco de dados, recebe o arquivo RDB pelo soquete e começa a restaurar os dados RDB (cópia completa).
5. Após a replicação completa, o nó escravo obteve o runid e o deslocamento do nó mestre e começa a enviar o comando psync runid deslocamento.
6. O nó mestre recebe o comando, avalia se o runid é compatível e se o deslocamento está no buffer de cópia.
7. O nó mestre avalia o runid e o deslocamento e, se um deles não estiver satisfeito, ele retornará à etapa 2 para continuar executando a replicação completa. A razão para a incompatibilidade de runid aqui pode ser uma reinicialização inesperada do nó escravo, e a incompatibilidade de deslocamento (deslocamento) é causada pelo estouro do buffer de cópia. Se a verificação de runid ou deslocamento for aprovada, se o deslocamento do nó escravo for igual ao deslocamento do nó mestre, ele será ignorado. Se o deslocamento do nó escravo não for igual ao deslocamento do nó mestre, o nó mestre enviará + CONTINUAR deslocamento (este deslocamento do nó mestre ) Comando para enviar as operações do deslocamento do nó para o deslocamento do nó mestre no buffer de cópia por meio do soquete (na verdade, o nó escravo executa menos operações do que o nó mestre).
8. Depois que o nó escravo recebe o deslocamento enviado pelo nó mestre e recebe as informações por meio do soquete, ele executa bgrewriteaof para restaurar os dados.

Obviamente, descobrimos que a cópia parcial é muito mais complicada do que a cópia completa, então vamos dar uma olhada em alguns detalhes da cópia parcial:

1. Runid

Este runid é mencionado várias vezes acima. Na verdade, o runid é um id aleatório que o redis irá gerar automaticamente quando for iniciado (deve-se notar que o id será diferente a cada vez que for iniciado), que é composto por 40 hexadecimais aleatórios É composto por uma string de sistema para identificar exclusivamente um nó redis.

Quando a replicação mestre-escravo é iniciada pela primeira vez, o mestre enviará seu runid para o escravo, e o escravo salvará o id do mestre. Quando o escravo é desconectado e reconectado, o escravo envia este id ao mestre. Se o runid salvo pelo escravo for o mesmo que o runid atual do mestre, o mestre tentará usar a replicação parcial (o outro fator para a replicação bem-sucedida é compensado, como mencionado acima) . Se o runid salvo pelo escravo for diferente do runid atual do mestre, a cópia completa será realizada diretamente.

2. Copiar buffer

O buffer de cópia é uma fila de primeiro a entrar, primeiro a sair, usada para armazenar os registros de comando do mestre para coletar dados. O espaço de armazenamento padrão do buffer de cópia é 1M. Você pode modificar o repl-backlog-size 1mb no arquivo de configuração para controlar o tamanho do buffer.

Na verdade, o buffer de cópia são os dados persistentes AOF armazenados (aof registros persistentes do comando emitido pelo cliente) e são separados por bytes, e cada byte tem seu próprio deslocamento, este deslocamento O valor é o deslocamento da cópia que mencionamos anteriormente (deslocamento).

Como mencionamos anteriormente, se o espaço do buffer de cópia for insuficiente, isso pode levar a uma cópia completa. Qual é o motivo? Na fase de propagação do comando, o nó mestre armazenará os comandos coletados no buffer de cópia e os enviará ao nó escravo. É aqui que surge o problema. Quando o número de comandos recebidos pelo nó mestre do cliente é extremamente grande em um instante, e a memória do buffer de cópia é excedida, alguns dados serão comprimidos, resultando em comandos do nó mestre e do nó escravo Cópia inconsistente, tão completa. Se o tamanho do buffer for definido de forma irracional, é muito provável que cause um loop infinito, e o nó escravo sempre copiará totalmente, esvaziará os dados e copiará totalmente.

3. Copie o deslocamento

O deslocamento da cópia do nó mestre é enviar um registro uma vez para o nó escravo, e o nó escravo recebe um registro uma vez. Usado para sincronizar informações, comparar a diferença entre o nó mestre e o nó escravo e restaurar o uso de dados quando o escravo é desconectado. Este valor também vem do deslocamento na área de backlog do buffer de cópia.

(4) Mecanismo de batimento cardíaco

Podemos pensar em um problema. No processo de replicação mestre-escravo, devemos saber se o nó mestre e o nó escravo estão online e operando normalmente. Se um determinado nó tiver alta latência ou nenhuma resposta, medidas correspondentes devem ser tomadas, como Pare a replicação mestre-escravo etc., então como cada nó sabe se os outros nós estão online?

Na fase de propagação do comando, o nó mestre e o nó escravo sempre precisam trocar informações.Esta troca de informações usa um mecanismo de pulsação para manutenção para perceber a consciência mútua da conexão entre o nó mestre e o nó escravo. Vamos dar uma olhada na função da pulsação do nó mestre e da pulsação do nó escravo:

1. batimento cardíaco mestre

Instrução: o ping é
executado a cada 10 segundos por padrão. É determinado pelo parâmetro repl-ping-slave-period. É o
principal responsável por julgar se o nó escravo está online.
Você pode usar a replicação de informações para visualizar o intervalo de tempo de conexão após o nó escravo ser alugado. Se o atraso for 0 ou 1, é estado normal.

2. batimento cardíaco escravo

Instrução: replconf ack {offset}
é executado uma vez por segundo. A
principal coisa a fazer é enviar seu próprio offset de replicação para o nó mestre, obter o último comando de mudança de dados do nó mestre e determinar se o nó mestre está online.

Nota: Para garantir a estabilidade dos dados, o nó mestre se recusará a sincronizar todas as informações quando o número de nós escravos pendurados exceder um valor definido ou o atraso for muito alto. Existem dois parâmetros que podem ser configurados e ajustados:

• min-slaves-to-write 2
• min-slaves-max-lag 8

Esses dois parâmetros indicam que existem apenas 2 nós escravos restantes, ou quando o atraso do nó escravo é maior que 8 segundos, o nó mestre forçará o fechamento da função maste e interromperá a sincronização de dados. Então, como o nó mestre sabe o número de nós escravos e o tempo de atraso? Como mencionado acima, no mecanismo de pulsação, o escravo envia o comando perlconf ack a cada segundo.Este comando pode levar o deslocamento, o tempo de atraso do nó escravo e o número de nós escravos.

15 de setembro de 2020