文章目录
- 一、主从服务器安装redis服务
- 二、主从服务器同步配置(需密码认证)
- 三、主从服务器同步测试
- 四、主从复制同步必要性
- 五、主从同步复制过程说明
- 六、持久化方式
服务器 | IP |
redis服务器160(主) | 192.168.1.210 |
redis服务器170(从) | 192.168.1.220 |
一、主从服务器安装redis服务
二、主从服务器同步配置(需密码认证)
1、主redis服务器210,修改redis.conf配置文件,在下图所示位置添加“requirepass 1111”,即设置密码为“1111”。redis-cli客户端访问时需要密码认证,如下图。
find / -name redis.conf
vi /usr/local/redis/redis.conf
2、从redis服务器220,修改redis.conf配置文件,在下图所示位置添加"replicaof 主redisIP 主redis端口"和“masterauth 1111”,如下图。
find / -name redis.conf
vi /usr/local/redis/redis.conf
三、主从服务器同步测试
1、主redis服务器210重启redis服务,启动redis本地客户端。
pkill redis
netstat -anp |grep redis
/usr/local/redis/src/redis-server /usr/local/redis/redis.conf
/usr/local/redis/src/redis-cli
2、从redis服务器220重启redis服务,启动redis本地客户端。
/usr/local/redis/src/redis-cli -p 6379 shutdown
/usr/local/redis/src/redis-server /usr/local/redis/redis.conf
/usr/local/redis/src/redis-cli
3、主redis服务器210通过客户端查看信息,提示需要密码认证,输入命令“auth 1111”,可以查看信息角色:master,连接的slaves主机数量,slave主机信息等。
info replication
auth 1111
info replication
4、从redis服务器220通过客户端可以查看角色:slave,连接的master主机IP、端口,master主机的连接状态等。up表示主从已连接,可以同步。
info replication
5、主redis服务器210,修改key的值。
set key 77777777
6、从redis服务器220也可查到同样的值,证明同步正常工作。
get key
四、主从复制同步必要性
- 虽然redis有持久化机制,但是有时redis服务器重启也会丢失数据,因为redis重启后会将硬盘中的数据恢复到内存中。但是当redis服务器的硬盘损坏了,可能就会导致数据丢失。如果通过redis的主从复制就能很好的避免这种单点故障。
- 当主redis数据库有两个从redis服务器,即使其中一台服务器宕机,其他两台服务器照样可以正常工作。主从redis保持实时同步,当主redis写入数据时,通过主从复制机制会将数据复制到两个从redis服务器上。
- 只有一个主redis,但可以有多个从redis。主从复制不会阻塞主redis,在同步数据时,主redis可以继续处理客户端的请求。
五、主从同步复制过程说明
1、slave服务启动后主动建立和master服务的联系,发送sync同步命令。
2、master启动一个后台进程将数据镜像保存到rdb文件中,此时如果生成rdb文件过程中存在写数据操作,将会导致rdb文件和当前master数据不一致,所以此时master主进程会开始收集写命令并缓存起来。
3、master发送rdb文件给slave。
4、slave将rdb文件保存在磁盘中,加载到内存中恢复。
5、master把写命令的缓存转发给slave。后续master收到的写命令会通过之前建立的连接发送给slave,当主从连接断开时slave会自动重新建立连接。如果master同时收到多个slave发来的sync命令时,只启动一个进程写数据镜像,发送给多个slave。
6、redis2.8之前slave每次同步会从master复制全部数据,如果首次同步当然没问题。但是如果slave停止工作,再次启动时可能只有少量数据不同步,这时slave又要从master复制全部数据,这样性能肯定没有只复制那一小部分未同步的数据快。
7、redis2.8之后使用部分复制机制,当slave连接master时,主动发送psync命令,slave提供master的runid(机器标示,随机生成)和offset(数据偏移量),master验证rundi和offset是否有效,如果master验证runid未通过,则slave进行全同步(首次同步),验证通过则说明slave曾与master同步过,此时根据offset同步部分数据即可。
六、持久化方式
redis提供了两种数据备份的方式rdb和aof。
持久化方式 | rdb | aof |
默认状态 | 默认开启;把redis.conf中所有的save注释即可关闭 | 默认关闭,在redis.conf中设为 appendonly yes即是开启了aof; |
同步机制 | 满足条件触发同步,即可以指定某个时间内发生多少个命令时进行同步 | 每秒同步或者每次发生命令后同步 |
存储内容 | 存储的是Redis里具体的值 | 存储的是执行更新操作的命令 |
存储文件的路径 | 根据dir以及dbfilenname来指定路径和具体的文件名 | 根据dir以及appendfilename来指定具体的路径和文件名 |
优点 | 存储数据文件时会进行压缩,文件体积比aof小;在恢复的时候速度比aof快;非常适合备份用。 | aof策略的备份机制是每秒或者每发生写操作的时候都会同步,因此即使服务器故障,最多只会丢失1秒的数据;aof存储的是redis命令,并且是直接追加到aof文件后面,因此每次备份的时候只要添加新的数据进去就可以了;如果aof文件比较大了,那么Redis会进行重写,只保留最小的命令集合。 |
缺点 | rdb在满足触发条件才会触发同步机制,rdb在同步的时候都重新保存整个Redis中的数据,在这种情况下,一旦服务器故障,会造成这段时间的数据丢失;在数据保存进rdb的时候,redis会fork出一个子进程用来同步,在数据量比较大的时候,可能非常耗时。 | aof文件因为没有压缩,因此比rdb体积大;aof是在每秒或者每次写操作都进行备份,因此如果并发量比较大,效率可能会有点慢;aof文件因为存储的是命令,因此在灾难恢复的时候Redis会重新运行aof中的命令,因此恢复速度比不上rdb。 |
rdb持久化参数 | 介绍 |
save 900 1 | 900秒和至少1个键改变才会被保存 |
save 300 10 | 300秒和至少10个键改变才会被保存 |
save 60 10000 | 60秒和至少10000个键改变才会被保存 |
stop-writes-on-bgsave-error yes | 错误发生时停止写入 |
rdbcompression yes | 启用压缩 |
rdbchecksum yes | 检验 |
dbfilename dump.rdb | rdb文件名 |
dir /var/lib/redis | rdb文件保存路径 |
AOF持久化参数 | 说明 |
appendonly no | 不启用aof持久化。若启动aof持久化,只要修改为appendonly yes即可。 |
auto-aof-rewrite-percentage 100 | 当aof文件的大小增张了指定比例的时候,执行一次重写操作。 |
auto-aof-rewrite-min-size 64mb | 设定aof文件重写操作最小值。 |
appendfilename “appendonly.aof” | aof持久化信息保存在哪个文件中。 |
appendfsync always | 一旦执行了操作,会立刻将操作的语句记录到aof文件中。 |
appendfsync everysec | 每秒向aof文件进行一次写入操作。 |
appendfsync no | 不主动向aof执行写入操作,由系统自行判断何时向磁盘执行写入操作。 |