01，主从复制
1.快速部署第⼆台Redis服务器
ssh-keygen
ssh-copy-id 10.0.0.51
rsync -avz 10.0.0.51:/opt/redis_cluster/redis_6379 /opt/redis_cluster/
rsync -avz 10.0.0.51:/usr/local/bin/redis* /usr/local/bin/
rsync -avz 10.0.0.51:/usr/lib/systemd/system/redis.service
/usr/lib/systemd/system/
sed -i 's#51#52#g' /opt/redis_cluster/redis_6379/conf/redis_6379.conf
mkdir -p /data/redis_cluster/redis_6379
groupadd redis -g 1000
useradd redis -u 1000 -g 1000 -M -s /sbin/nologin
chown -R redis:redis /opt/redis_cluster/redis*
chown -R redis:redis /data/redis_cluster/redis*
systemctl daemon-reload
systemctl start redis
报错总结：
1.在db01上执⾏了命令
2.配置⽂件⾥的密码没删掉
3.配置⽂件⾥的重命名参数没删掉
4.⽤户id和组id冲突
5.没有rsync
6.拷⻉过来的配置⽂件没有修改IP地址
2.db01插⼊测试命令
for i in {1..1000};do redis-cli set key_${i} v_${i} && echo "${i} is
ok";done
3.配置主从复制
⽅法1:临时⽣效
redis-cli -h 10.0.0.52 SLAVEOF 10.0.0.51 6379
⽅法2:写进配置⽂件永久⽣效
SLAVEOF 10.0.0.51 6379
4.检查复制进度
INFO replication
ROLE
5.主从复制流程
1.从节点发送同步请求到主节点
2.主节点接收到从节点的请求之后,做了如下操作
- ⽴即执⾏bgsave将当前内存⾥的数据持久化到磁盘上
- 持久化完成之后,将rdb⽂件发送给从节点
3.从节点从主节点接收到rdb⽂件之后,做了如下操作
- 清空⾃⼰的数据
- 载⼊从主节点接收的rdb⽂件到⾃⼰的内存⾥
4.后⾯的操作就是和主节点实时的了
6.取消复制
SLAVEOF no one
7.主从复制注意
1.从节点只读不可写
2.从节点不会⾃动故障转移，他会⼀直尝试同步主节点，并且依然不可写
3.主从复制故障转移需要介⼊的地⽅
- 修改代码指向新主的IP
- 从节点需要执⾏slaveof no one
4.从库建⽴同步时会清空⾃⼰的数据，如果同步对象写错了，就清空了
5.从库也可以正常的RDB持久化
8.安全的操作
定要做好数据备份，⽆论是主节点还是从节点，操作前最好做下备份
9.主从复制密码
masterauth 123456
02，Redis Sentinel(哨兵)
1.哨兵的作⽤
1.解决主从复制需要⼈为⼲预的问题
2.提供了⾃动的⾼可⽤⽅案
图片.png
2.⽬录和端⼝规划
redis节点 6379
哨兵节点 26379
3.部署3台redis单节点主从关系
db01操作
pkill redis
cat >/opt/redis_cluster/redis_6379/conf/redis_6379.conf <<EOF
daemonize yes
bind 127.0.0.1 10.0.0.51
port 6379
pidfile "/opt/redis_cluster/redis_6379/pid/redis_6379.pid"
logfile "/opt/redis_cluster/redis_6379/logs/redis_6379.log"
dbfilename "redis.rdb"
dir "/data/redis_cluster/redis_6379"
appendonly yes
appendfilename "redis.aof"
appendfsync everysec
EOF
systemctl start redis
redis-cli
db02和db03操作
ssh-keygen
ssh-copy-id 10.0.0.51
pkill redis
rm -rf /opt/redis*
rsync -avz 10.0.0.51:/usr/local/bin/redis-* /usr/local/bin
rsync -avz 10.0.0.51:/usr/lib/systemd/system/redis.service
/usr/lib/systemd/system/
mkdir /opt/redis_cluster/redis_6379/{conf,logs,pid} -p
mkdir /data/redis_cluster/redis_6379 -p
cat >/redis_cluster/opt/redis_6379/conf/redis_6379.conf <<EOF
daemonize yes
bind 127.0.0.1 $(ifconfig eth0|awk 'NR==2{print $2}')
port 6379
pidfile "/opt/redis_cluster/redis_6379/pid/redis_6379.pid"
logfile "/opt/redis_cluster/redis_6379/logs/redis_6379.log"
dbfilename "redis.rdb"
dir "/data/redis_cluster/redis_6379"
appendonly yes
appendfilename "redis.aof"
appendfsync everysec
EOF
useradd redis -M -s /sbin/nologin
chown -R redis:redis /opt/redis*
chown -R redis:redis /data/redis*
systemctl daemon-reload
systemctl start redis
redis-cli
4.配置主从复制
redis-cli -h 10.0.0.52 slaveof 10.0.0.51 6379
redis-cli -h 10.0.0.53 slaveof 10.0.0.51 6379
redis-cli -h 10.0.0.51 info replication
5.部署哨兵节点-3台机器都操作
mkdir -p /data/redis_26379
mkdir -p /opt/redis_26379/{conf,pid,logs}
cat >/opt/redis_26379/conf/redis_26379.conf << EOF
bind $(ifconfig eth0|awk 'NR==2{print $2}')
port 26379
daemonize yes
logfile /opt/redis_26379/logs/redis_26379.log
dir /data/redis_26379
sentinel monitor myredis 10.0.0.51 6379 2
sentinel down-after-milliseconds myredis 3000
sentinel parallel-syncs myredis 1
sentinel failover-timeout myredis 18000
EOF
chown -R redis:redis /data/redis*
chown -R redis:redis /opt/redis*
cat >/usr/lib/systemd/system/redis-sentinel.service<<EOF
[Unit]
Description=Redis persistent key-value database
After=network.target
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/usr/local/bin/redis-sentinel /opt/redis_26379/conf/redis_26379.conf --supervised systemd
ExecStop=/usr/local/bin/redis-cli -h $(ifconfig eth0|awk 'NR==2{print$2}') -p 26379 shutdown
Type=notify
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl start redis-sentinel
redis-cli -h $(ifconfig eth0|awk 'NR==2{print $2}') -p 26379
关键配置解释:
sentinel monitor myredis 10.0.0.51 6379 2
# myredis主节点别名 主节点IP 端⼝ 需要2个哨兵节点同意
sentinel down-after-milliseconds myredis 3000
# 认定服务器已经断线所需要的毫秒数
sentinel parallel-syncs myredis 1
# 向主节点发给复制操作的从节点个数，1表示轮训发起复制
sentinel failover-timeout myredis 18000
# 故障转移超时时间
6.哨兵注意
1.哨兵发起故障转移的条件是master节点失去联系，从节点挂掉不会发起故障转移
2.哨兵会⾃⼰维护配置⽂件，不需要⼿动修改
3.如果主从的结构发⽣变化，哨兵之间会⾃动同步最新的消息并且⾃动更新配置⽂件
4.哨兵启动完成之后，以后不要再⾃⼰去设置主从关系
7.验证主机点
redis-cli -h 10.0.0.51 -p 26379 SENTINEL get-master-addr-by-name myredis
8.哨兵的常⽤命令
redis-cli -h 10.0.0.51 -p 26379 SENTINEL get-master-addr-by-name myredis
redis-cli -h 10.0.0.51 -p 26379 SENTINEL master myredis
redis-cli -h 10.0.0.51 -p 26379 SENTINEL slaves myredis
redis-cli -h 10.0.0.51 -p 26379 SENTINEL ckquorum myredis
9.模拟故障转移
模拟⽅法：
关闭redis当前的主节点
观察其他2个节点会不会发⽣选举
查看哨兵配置⽂件会不会更新
查看从节点配置⽂件会不会更新
查看主节点能不能写⼊
查看从节点是否同步正常
流程：
1）在从节点列表中选出⼀个节点作为新的主节点，选择⽅法如下：
a）过滤：“不健康”（主观下线、断线）、5秒内没有回复过Sentinel节点ping响应、与主节点
失联超过down-after-milliseconds*10秒。
b）选择slave-priority（从节点优先级）最⾼的从节点列表，如果存在则返回，不存在则继
续。
c）选择复制偏移量最⼤的从节点（复制的最完整），如果存在则返回，不存在则继续。
d）选择runid最⼩的从节点
流程图：
图片.png
结论：
主节点挂掉，哨兵会选举新的主节点
在新主节点上执⾏slaveof no one
在从节点执⾏slave of 新主节点
⾃动更新哨兵配置
⾃动更新从节点配置
10.故障修复重新上线
启动单节点
检查是否变成从库
11.哨兵加权选举
查看权重
redis-cli -h 10.0.0.51 -p 6379 CONFIG GET slave-priority
redis-cli -h 10.0.0.52 -p 6379 CONFIG GET slave-priority
redis-cli -h 10.0.0.53 -p 6379 CONFIG GET slave-priority
暗箱操作：假如选中53作为最新的master
redis-cli -h 10.0.0.51 -p 6379 CONFIG SET slave-priority 0
redis-cli -h 10.0.0.52 -p 6379 CONFIG SET slave-priority 0
检查：
redis-cli -h 10.0.0.51 -p 6379 CONFIG GET slave-priority
redis-cli -h 10.0.0.52 -p 6379 CONFIG GET slave-priority
redis-cli -h 10.0.0.51 -p 26379 sentinel get-master-addr-by-name myredis
主动发⽣选举
redis-cli -h 10.0.0.51 -p 26379 sentinel failover myredis
redis-cli -h 10.0.0.51 -p 26379 sentinel get-master-addr-by-name myredi
网友评论