Redis主从复制及哨兵模式
- 主从复制
- 概述
- 主从同步方式
- 全量同步
- 增量同步
- Redis主从同步策略
- 主从配置
- 步骤
- 验证
- 哨兵模式
- 哨兵模式原理
- 哨兵模式的作用
- 哨兵模式的实现场景
- 哨兵配置
- 验证
- 故障
主从复制
概述
Redis虽然读取写入的速度都特别快,但是也会产生读压力特别大的情况。为了分担读压力,Redis支持主从复制,保证主数据库的数据内容和从数据库的内容完全一致。
主从复制架构只能用来解决数据的冗余备份,只有master节点可以接受客户端的请求并执行写入操作,而slave节点仅仅做数据的同步,客户端无法将数据写入到从节点中。主从复制架构无法保证主节点宕机时的自动故障转移即高可用(因此需要哨兵模式)。
主从同步方式
Redis的主从结构可以采用一主多从或者级联结构,Redis主从复制可以根据是否是全量分为全量同步和增量同步。
全量同步
Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下:
从服务器连接主服务器,发送SYNC命令
主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令
主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令
从服务器收到快照文件后丢弃所有旧数据,载入收到的快照
主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令
从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令
增量同步
Redis增量复制是指Slave 初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。
Redis主从同步策略
主从刚刚连接的时候,进行全量同步;全同步结束后,进行增量同步。当然,如果有需要,slave在任何时候都可以发起全量同步。redis策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步。
主从配置
步骤
主机名 | IP |
master | 192.168.1.15 |
slave1 | 192.168.1.20 |
slave2 | 192.168.1.30 |
安装环境
输入到所有会话。
tar zxvf redis-5.0.4.tar.gz
cd redis-5.0.4/
make
make PREFIX=/usr/local/redis install
ln -s /usr/local/redis/bin/* /usr/local/bin
cd utils/
./install_server.sh
master、slave节点都需要,修改配置文件
vi /etc/redis/6379.conf #master、slave节点都需要修改
bind 0.0.0.0 #70行 修改监听地址为0.0.0.0(在实验环境使用),现网环境建议绑定从服务器IP地址
daemonize yes #137行 开启守护进程
logfile /var/log/redis_6379.log #172行 修改日志文件目录
dir /var/lib/redis/6379 #264行 修改工作目录
appendonly yes #700行 开启AOF持久化功能
从服务器
多修改一个同步master节点IP和端口
vi /etc/redis/6379.conf
replicaof 192.168.1.15 6379 #287行,去掉注释,添加
master和slave,关闭所有的防火墙。
/etc/init.d/redis_6379 restart #重启服务
验证
查看日志
tail -f /var/log/redis_6379.log
redis-cli -h 192.168.1.15
192.168.1.15:6379> info replication
哨兵模式
哨兵模式原理
哨兵(sentinel)是一个分布式系统,用于对主从结构中的每台服务器进行监控,当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。所以整个运行哨兵的集群的数量不得少于3个节点。
哨兵模式的作用
- 监控
不断的检查master和slave是否正常运行。
master存活检测、master 与slave运行情况检测 - 通知(提醒)
当被监控的服务器出现问题时,向其他(哨兵间,客户端)发送通知。 - 自动故障转移
断开master与slave连接,选取一个slave作为master,将其他slave连接到新的master,并告知客户端新的服务器地址
PS:
哨兵也是一台redis服务器,只是不提供数据服务。
哨兵的启动依赖于主从模式,所以须把主从模式安装好的情况下再去做哨兵模式,所有节点上都需要部署哨兵模式,哨兵模式会监控所有的redis工作节点是否正常,当master出现问题的时候,因为其他节点与主节点失去联系,因此会投票,投票过半就认为这个master的确出现问题,然后会通知哨兵间,然后从slaves中选取一个作为新的master。
哨兵模式的实现场景
在主从模式的Redis系统中,从数据库在整个系统中起到了数据 冗余备份和 读写分离的作用,但是当数据库遇到异常中断服务后,我们只能通过手动的方式选择一个从数据库来升格为主数据库,显然这种方式很麻烦需要人工介入,这时通过哨兵模式可以实现自动化的系统监控和故障恢复。
哨兵配置
所有节点都需要修改
vi redis-5.0.4/sentinel.conf
protected-mode no #17关闭保护模式
daemonize yes #26指定sentinel为后台启动
logfile "/var/log/sentinel.log" #36指定日志存放路径
dir "/var/lib/redis/6379" #65/指定数据库存放路径
sentinel monitor mymaster 192.168.1.15 6379 2 #84至少几个哨兵检测到主服务器故障了,才会进行故障迁移
sentinel down-after-milliseconds mymaster 3000 #113判定服务器down掉的时间周期,默认30000毫秒(30秒)
sentinel failover-timeout mymaster 180000 #146/故障节的的最大超时时间为180000(180秒)
先启master,再启slave
redis-sentinel redis-5.0.4/sentinel.conf &
验证
查看日志
tail -f /var/log/sentinel.log
查看服务情况及端口号
ps aux | grep sentinel
查看哨兵信息
redis-cli -h 192.168.1.15 -p 26379
192.168.1.15:26379> info sentinel
故障
ps -ef | grep redis
kill -9 63146 #杀死进程
验证
tail -f /var/log/sentinel.log
或者
redis-cli -h 192.168.1.15 -p 26379
192.168.1.15:26379> info sentinel