Replicação Master-Slave no Redis
Antes de implementar a alta disponibilidade no Redis, é fundamental compreender como a replicação master-slave funciona. Essa tecnologia permite que um nó master possua múltiplos nós slaves, e cada slave pode também atuar como master para outros slaves, semelhante à replicação em cascata do MySQL.
O mecanismo de replicação do Redis utiliza seus arquivos de persistência RDB. O processo consiste em primeiro gerar um arquivo RDB, transmiti-lo para o(s) slave(s) e, em seguida, sincronizar as operações realizadas após o dump em tempo real. Dessa forma, o servidor escravo se torna uma cópia fiel do servidor master.
Implementando a Replicação Master-Slave
Para esta configuração, serão necessários dois servidores com Redis instalado.
Servidor master: 192.168.1.100
Servidor slave: 192.168.1.101
Primeiro passo: Enstalar o Redis
A instalação deve ser realizada em ambos os servidores.
[root@servidor ~]# yum install redis -y
Segundo passo: Adaptar o arquivo de configuração
Em ambos os servidores, é preciso modificar oparamêtro bind para o endereço IP local do equipamento. Esta modificação encontra-se aproximadamente na linha 61 do arquivo de configuração.
Configuração do master (192.168.1.100):
47 # bind 192.168.1.100 10.0.0.1
48 # bind 127.0.0.1 ::1
49 #
50 # ~~~ WARNING ~~~ If the computer running Redis is directly exposed to the
51 # internet, binding to all the interfaces is dangerous and will expose the
52 # instance to everybody on the internet. So by default we uncomment the
53 # following bind directive, that will force Redis to listen only into
54 # the IPv4 lookback interface address (this means Redis will be able to
55 # accept connections only from clients running into the same computer it
56 # is running).
57 #
58 # IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES
59 # JUST COMMENT THE FOLLOWING LINE.
60 # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
61 bind 192.168.1.100
Configuração do slave (192.168.1.101):
47 # bind 192.168.1.100 10.0.0.1
48 # bind 127.0.0.1 ::1
49 #
50 # ~~~ WARNING ~~~ If the computer running Redis is directly exposed to the
51 # internet, binding to all the interfaces is dangerous and will expose the
52 # instance to everybody on the internet. So by default we uncomment the
53 # following bind directive, that will force Redis to listen only into
54 # the IPv4 lookback interface address (this means Redis will be able to
55 # accept connections only from clients running into the same computer it
56 # is running).
57 #
58 # IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES
59 # JUST COMMENT THE FOLLOWING LINE.
60 # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
61 bind 192.168.1.101
Terceiro passo: Reiniciar o serviço Redis
[root@servidor ~]# systemctl restart redis
Quarto passo: Acessar o Redis
Após modificar o endereço debind, o acesso deve ser feito especificando o endereço IP local.
[root@servidor ~]# redis-cli -h 192.168.1.101
Quinto passo: Estabelecer a replicação master-slave
A replicação é configurada através do comando SLAVEOF, seguido pelo endereço IP e porta do servidor master.
192.168.1.101:6379> SLAVEOF 192.168.1.100 6379
OK
Sexto passo: Verificar a replicação
No master, listar todas as chaves:
192.168.1.100:6379> keys *
1) "gender"
2) "usuario"
3) "telefone"
4) "anuncio"
5) "produto"
6) "nome"
7) "sistema"
8) "endereco"
No slave, verificar se as chaves foram replicadas:
192.168.1.101:6379> keys *
1) "nome"
2) "usuario"
3) "produto"
4) "endereco"
5) "sistema"
6) "anuncio"
7) "telefone"
8) "gender"
Para desativar a replicação, basta executar o comando slaveof no one no nó slave.
Múltiplas Instâncias do Redis
Múltiplas instâncias referem-se à execução de vários servidores Redis em um único equipamento. Esta abordagem maximiza a utilização dos recursos disponíveis e é recomendada para ambientes de testes, pois reduz o consumo de memória.
A inicialização de múltiplas instâncias requer o uso do comando redis-server seguido do arquivo de configuração específico. O acesso a cada instância deve ser feito especificando o endereço IP e a porta correspondiente.
Configurando Múltiplas Instâncias
Primeiro passo: Criar diretórios
No servidor 192.168.1.100, serão criadas três instâncias nas portas 6379, 6380 e 6381. Cada diretório armazenará os dados respectivos, incluindo arquivos de configuração, logs, PID e snapshots RDB.
[root@servidor ~]# mkdir /redis/{6379,6380,6381} -p
Segundo passo: Copiar arquivos de configuração
[root@servidor ~]# cp /etc/redis.conf /redis/6379/
[root@servidor ~]# cp /etc/redis.conf /redis/6380/
[root@servidor ~]# cp /etc/redis.conf /redis/6381/
Terceiro passo: Ajustar cada arquivo de configuração
Para a instância na porta 6379, os seguintes parâmetros devem ser modificados:
- bind - Endereço de escuta
- port - Número da porta
- daemonize - Execução em segundo plano
- pidfile - Local do arquivo PID
- logfile - Local do arquivo de log
- dbfilename - Nome do arquivo RDB
- dir - Diretório de dados
[root@servidor ~]# egrep -v '^#|^$' /redis/6379/redis.conf
bind 192.168.1.100
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile /redis/6379/redis_6379.pid
loglevel notice
logfile /redis/6379/redis.log
dir /redis/6379
databases 16
save 900 1
save 300 10
save 60 10000
...
Para a instância na porta 6380:
[root@servidor ~]# egrep -v '^#|^$' /redis/6380/redis.conf
bind 192.168.1.100
protected-mode yes
port 6380
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile /redis/6380/redis_6380.pid
loglevel notice
logfile /redis/6380/redis.log
dir /redis/6380
databases 16
save 900 1
save 300 10
save 60 10000
...
Para a instância na porta 6381:
[root@servidor ~]# egrep -v '^#|^$' /redis/6381/redis.conf
bind 192.168.1.100
protected-mode yes
port 6381
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile /redis/6381/redis_6381.pid
loglevel notice
logfile /redis/6381/redis.log
dir /redis/6381
databases 16
save 900 1
save 300 10
save 60 10000
...
Quarto passo: Habilitar execução em segundo plano
Localizar aproximadamente a linha 128 e alterar para daemonize yes em todos os arquivos de configuração.
...
# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
daemonize yes
...
Quinto passo: Iniciar as instâncias
Cada instância é iniciada com seu arquivo de configuração específico:
[root@servidor ~]# redis-server /redis/6379/redis.conf
[root@servidor ~]# redis-server /redis/6380/redis.conf
[root@servidor ~]# redis-server /redis/6381/redis.conf
[root@servidor ~]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:10050 *:*
LISTEN 0 128 192.168.1.100:6379 *:*
LISTEN 0 128 192.168.1.100:6380 *:*
LISTEN 0 128 192.168.1.100:6381 *:*
LISTEN 0 128 *:111 *:*
LISTEN 0 128 *:22 *:*
LISTEN 0 128 :::10050 :::*
LISTEN 0 128 :::111 :::*
LISTEN 0 128 :::80 :::*
LISTEN 0 128 :::22 :::*
As múltiplas instâncias foram configuradas com sucesso.
Alta Disponibilidade no Redis
A alta disponibilidade no Redis é implementada através do modo Sentinel, que oferece monitoramento contínuo dos nós master e slaves. Quando uma falha é detectada, o Sentinel pode realizar failover automático, promoting um slave paramaster e notificando os clientes sobre a mudança.
Caso o servidor master original seja recuperado e reconectado, ele assumirá o papel de slave automaticamente.
Utilizando a configuração de múltiplas instâncias criada anteriormente, os nós ficarão distribuídos assim:
- Master: 192.168.1.100:6379
- Slave 1: 192.168.1.100:6380
- Slave 2: 192.168.1.101:6381
- Sentinel: 192.168.1.101
Primeiro passo: Estabelecer a replicação
Configurar o Slave 1 como escravo do master:
[root@servidor ~]# redis-cli -h 192.168.1.100 -p 6380
192.168.1.100:6380> SLAVEOF 192.168.1.100 6379
OK
192.168.1.100:6380> exit
Configurar o Slave 2 como escravo do master:
[root@servidor ~]# redis-cli -h 192.168.1.101 -p 6381
192.168.1.101:6381> SLAVEOF 192.168.1.100 6379
OK
192.168.1.101:6381> exit
Segundo passo: Verificar o status da replicação
No nó master, executar info replication para visualizar informações sobre a replicação. O resultado deve mostrar que existem 2 slaves conectados.
[root@servidor ~]# redis-cli -h 192.168.1.100 -p 6379
192.168.1.100:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.100,port=6380,state=online,offset=365,lag=0
slave1:ip=192.168.1.101,port=6381,state=online,offset=365,lag=1
master_repl_offset:365
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:364
Terceiro passo: Configurar o Sentinel
Editar o arquivo /etc/redis-sentinel.conf. Desabilitar o modo protegido (linha 17) e especificar as informações do master (linha 69).
O parâmetro sentinel monitor segue o formato: sentinel monitor nome-do-master ip porta quorum
O valor de quorum determina quantos Sentinels devem concordar para executar o failover. Neste caso,定义为1 significa que apenas um Sentinel precisa confirmar a falha para iniciar a transição.
[root@servidor ~]# vim /etc/redis-sentinel.conf
15 # bind 127.0.0.1 192.168.1.1
16 #
17 protected-mode no
18
19 # port <sentinel-port>
20 # The port that this sentinel instance will run on
21 port 26379
...
67 # Note: master name should not include special characters or spaces.
68 # The valid charset is A-z 0-9 and the three characters ".-_".
69 sentinel monitor meumaster 192.168.1.100 6379 1
Quarto passo: Iniciar o Sentinel
[root@servidor ~]# systemctl restart redis-sentinel
[root@servidor ~]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *:10050 *:*
LISTEN 0 128 *:26379 *:*
LISTEN 0 128 192.168.1.101:6379 *:*
LISTEN 0 128 *:111 *:*
LISTEN 0 128 *:22 *:*
LISTEN 0 128 :::10050 :::*
LISTEN 0 128 :::26379 :::*
LISTEN 0 128 :::111 :::*
LISTEN 0 128 :::80 :::*
LISTEN 0 128 :::22 :::*
Quinto passo: Conectar ao Sentinel
[root@servidor ~]# redis-cli -h 192.168.1.101 -p 26379
Sexto passo: Informações do master
192.168.1.101:26379> sentinel masters
1) 1) "name"
2) "meumaster"
3) "ip"
4) "192.168.1.100"
5) "port"
6) "6379"
7) "runid"
8) "1096f9bef5606124ddd437f93e3c7d5027061abf"
9) "flags"
10) "master"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
...
Sétimo passo: Informações dos slaves
192.168.1.101:26379> sentinel slaves meumaster
1) 1) "name"
2) "192.168.1.100:6380"
3) "ip"
4) "192.168.1.100"
5) "port"
6) "6380"
7) "runid"
8) "bc8524006a66bfee2aaa15d3b5615fb0cdb50cb1"
9) "flags"
10) "slave"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "521"
19) "last-ping-reply"
20) "521"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "8370"
25) "role-reported"
...
Testando a Alta Disponibilidade
Primerio passo: Interromper o nó master
Identificar o processo do master através do comando ps aux e encerrá-lo com kill -9.
[root@servidor ~]# ps aux | grep redis
root 4403 0.2 0.4 142952 2240 ? Rsl 20:50 0:01 redis-server 192.168.1.100:6379
root 4408 0.1 0.4 142952 2248 ? Ssl 20:50 0:01 redis-server 192.168.1.100:6380
root 4413 0.1 0.4 142952 2248 ? Ssl 20:50 0:01 redis-server 192.168.1.100:6381
root 4457 0.0 0.1 112704 968 pts/0 S+ 21:04 0:00 grep --color=auto redis
[root@servidor ~]# kill -9 4403
[root@servidor ~]# ps aux | grep redis
root 4408 0.1 0.4 142952 2264 ? Ssl 20:50 0:01 redis-server 192.168.1.100:6380
root 4413 0.1 0.4 142952 2264 ? Ssl 20:50 0:01 redis-server 192.168.1.100:6381
root 4459 0.0 0.1 112704 964 pts/0 R+ 21:04 0:00 grep --color=auto redis
Segundo passo: Verificar o failover
Consultar o Sentinel para confirmar que o novo master foipromovido. Agora o nó operando na porta 6380 tornou-se o master.
192.168.1.101:26379> sentinel masters
1) 1) "name"
2) "meumaster"
3) "ip"
4) "192.168.1.100"
5) "port"
6) "6380"
7) "runid"
8) "bc8524006a66bfee2aaa15d3b5615fb0cdb50cb1"
9) "flags"
10) "master"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "777"
19) "last-ping-reply"
20) "777"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
...