Redis配置主从服务器【转】

本文详细介绍如何在一台服务器上配置Redis主从服务,并通过调整配置实现高效内存操作及数据备份。通过设置从服务器,可轻松实现数据同步,提高Redis服务的可用性和灵活性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

redis配置主从服务器

Redis主从服务器的搭建很简单,只要少许配置即可,为了演示的方便,我们就在一台服务器上配置:

前提是你已经有了一台Redis服务器,如果没有可以参考我以前的文章安装。下面看看如何配置从服务器:

假设主服务器的配置文件是:/etc/redis.conf,我们复制一份作为从服务器的配置文件:

cp /etc/redis.conf /etc/redis_slave.conf

并作修改:

# vi /etc/redis_slave.conf
port 6380
dbfilename dump_slave.rdb
slaveof 127.0.0.1 6379

主服务器的端口使用的是缺省的6379,从服务器的端口我们设置成6380。

然后插入一些测试数据:

redis-benchmark

由于我们没有设定任何参数,所以使用的是缺省端口(6379),在本例中就是主服务器。

然后启动从服务器:

redis-server /etc/redis_slave.conf

确认一下是否都正常启动了:

ps -ef | grep redis

进入数据目录,查一下数据文件的散列:

md5sum *.rdb

你会发现数据文件散列都一样,自动同步了。

然后我们关闭一下从服务器(不关也行,我就是为了告诉你如何正确关闭redis服务器):

redis-cli -p 6380 shutdown

接着再往主服务器上写入测试数据:

redis-benchmark -l

这会循环插入测试数据,数据量的大小取决于时间的长短,你可以在适当的时候按ctrl+c停止。

如果从服务器没有启动的话,接着再重新启动从服务器:

redis-server /etc/redis_slave.conf

通过观察文件大小你会发现数据会自动同步,如果没有重启动从服务器,那么数据文件的md5sum散列值可能不同,这是正常的,不要紧。

在操作过程中,有时候你会发现主从服务器的数据文件大小不一样,一般来说也不是问题,因为redis是异步写入磁盘的,此时可能有部分数据还在内存中,没有同步到磁盘,所以文件大小略显不同,可以分别在主从服务器上执行:

redis-cli save(redis-cli -p 6380 save)

这条命令强制同步到磁盘,再看大小就应该一样了。

配置文件redis.conf里有一部分和save相关的参数,缺省如下:

# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
save 900 1
save 300 10
save 60 10000

在主服务器上,我们可以去掉上面的设置,改成类似下面的设置(只要参数值够大即可):

save 10000000000 10000000000

如此一来主服务器变成一个完全的内存服务器,所有的操作都在内存里完成,“永远”不会再往磁盘上持久化保存数据,异步的也没有。持久化则通过从服务器来完 成,这样在操作主服务器的时候效率会更高。不过要注意的一点是此方法不适合保存关键数据,否则一旦主服务器挂掉,如果你头脑一热简单的重启服务,那么从服 务器的数据也会跟着消失,此时,必须拷贝一份备份数据到主服务器,然后再重启服务才可以,数据的恢复稍显麻烦。

从服务器也可以通过设置这个参数来调整从内存同步到磁盘的频率。

利用主从服务器备份

可以利用主从服务器的方便性来备份,专门做一台从服务器用于备份功能,当需要备份的时候,在从服务器上执行下列命令:

redis-cli save
redis-cli shutdown

然后拷贝数据目录下的rdb文件即可。

另:官方文档介绍不使用主从,直接在服务器上cp就可以,不过感觉利用从服务器备份对线上服务器影响更小些。

总结

如果你以前做过MySQL主从服务器的话,两相对比,你会发现Redis主从服务器不用做前期的数据同步,设置好了从服务器,简单启动就OK了。至于Redis主从怎么用,是备份也好,读写分离也好,就看你的想象力了。

转至:http://hi.baidu.com/thinkinginlamp/blog/item/e78f9c82403d01b56c8119a5.html

### Redis 从复制与哨兵模式配置及运行机制 #### 配置从复制 为了实现高可用性和数据冗余,在Redis环境中通常设置一个或多个从服务器来备份服务器的数据。可以通过两种方式完成这一过程: - **通过配置文件配置** 修改`redis.conf`中的`slaveof`参数指向服务器地址和端口,从而让该实例成为指定服务器的副本[^1]。 - **通过命令配置** 使用`SLAVEOF host port`指令动态地使当前节点作为另一台机器上的特定Redis实例的从属设备;输入`SLAVEOF NO ONE`可取消这种关系并恢复独立运作状态。 对于具体的环境部署而言,比如构建由一台服务器(Master)加两台从服务器组成的架构,则需要相应调整各节点间的连接属性以确保正常同步操作能够顺利执行。 #### 哨兵模式概述及其配置方法 哨兵系统用于监控管理一组Redis服务器的状态变化情况,并能在检测到故障发生时自动实施修复措施——最常见的是触发一次Failover流程即重新选定一个新的Leader角色承担起原有Primary职责继续对外提供服务而不影响业务连续性[^3]。 针对上述提到的一二丛结构加上三个Sentinel进程共同构成完整的HA解决方案案例来说,具体步骤如下所示[^2]: 1. 准备好三份不同路径下存放着各自专属配置项(sentinel.conf) 的哨岗程序; 2. 编辑这些文档定义监听目标以及通知邮箱列表等内容; 3. 利用命令行工具依次开启每一个守护者单元使之进入待命姿态等待接收事件报告; 4. 确认所有组件均已成功上线之后便可以测试整个体系能否按照预期发挥作用了。 ```bash cd /opt/redis-5.0.7/ redis-sentinel sentinel.conf & ``` 以上述脚本为例说明如何启动单个哨位实体,实际应用当中应当重复此动作直至覆盖全部预定位置。 #### 运作逻辑解析 一旦某个Slave失去联系超过一定时限后就会被标记为已离线(Suspect),此时其余在线成员之间会展开一轮投票决议是否要将其正式认定为不可达(Down)[^4]。如果确实如此则立即挑选出一位表现最佳的竞争者晋升为首脑带领剩余群体维持日常运营秩序直到失联个体恢复正常为止。 在此过程中涉及到的关键考量因素之一就是所谓的“优先级”,它决定了候选名单里谁最有资格接替前任领导者的位置。默认情况下数值越低代表权重越高,默认设定为100,用户可以根据实际情况自定义调整这个值以便更好地适应不同的应用场景需求。 另外值得注意的地方在于原先担任过Master职务的那个对象即便后来降格成为了Follower身份也依然保留着曾经拥有的那份记忆不会轻易改变自己的定位除非再次遭遇类似的权力更迭情形才会考虑做出相应的变。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值