[redis-持久化,主从复制原理,Redis-Sentinel]
作者:互联网
[redis-持久化,主从复制原理,Redis-Sentinel]
1 持久化
# redis的所有数据保存在内存中,对数据的更新将异步的保存到硬盘上
快照:某时某刻数据的一个完成备份
-mysql的Dump
-redis的RDB
写日志:任何操作记录日志,要恢复数据,只要把日志重新走一遍即可
-mysql的 Binlog
-Redis的 AOF
1.1 rdb方式
# 原理是:某一时刻,把数据完整备份,重启,把数据加载回内存
# 三种方式实现
-在客户都命令行中敲命令
-save ---》同步操作
-在客户都命令行中敲命令
-bgsave---》异步操作(又起了一条保存线程,单独保存,不会阻塞其他命令的执行)
-在配置文件中写
save 900 1
save 300 10
save 60 10000
如果60s中改变了1w条数据,自动生成rdb
如果300s中改变了10条数据,自动生成rdb
如果900s中改变了1条数据,自动生成rdb
# 注意:如果是正常关闭redis,会触发bgsave---》要强行关闭
# 缺点
-可以能会丢失数据
# 缓冲相关用这种方式,如果对数据要求严格,保证不丢,不能使用这种方式
1.2 aof 方式
# 客户端每写入一条命令,都记录一条日志,放到日志文件中,如果出现宕机,可以将数据完全恢复
# 三种策略
日志不是直接写到硬盘上,而是先放在缓冲区,缓冲区根据一些策略,写到硬盘上
always:redis–》写命令刷新的缓冲区—》每条命令fsync到硬盘—》AOF文件
everysec(默认值):redis——》写命令刷新的缓冲区—》每秒把缓冲区fsync到硬盘–》AOF文件
no:redis——》写命令刷新的缓冲区—》操作系统决定,缓冲区fsync到硬盘–》AOF文件
# AOF 重写
本质就是把过期的,无用的,重复的,可以优化的命令,来优化
这样可以减少磁盘占用量,加速恢复速度
# 实际配置
appendonly yes #将该选项设置为yes,打开
appendfilename "appendonly-${port}.aof" #文件保存的名字
appendfsync everysec #采用第二种策略
dir /bigdiskpath #存放的路径
no-appendfsync-on-rewrite yes #在aof重写的时候,是否要做aof的append操作,因为aof重写消耗性能,磁盘消耗,正常aof写磁盘有一定的冲突,这段期间的数据,允许丢失
1.3 RDB-AOF混合持久化
# 配置文件写
save 60 10
save 30 5
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-use-rdb-preamble yes
# 在aof文件中,既有rdb的东西,又又aof日志的记录
2 主从复制原理与优化
# 主从复制的流程和原理
1. 副本库通过slaveof 127.0.0.1 6379命令,连接主库,并发送SYNC给主库
2. 主库收到SYNC,会立即触发BGSAVE,后台保存RDB,发送给副本库
3. 副本库接收后会应用RDB快照
4. 主库会陆续将中间产生的新的操作,保存并发送给副本库
5. 到此,我们主复制集就正常工作了
6. 再此以后,主库只要发生新的操作,都会以命令传播的形式自动发送给副本库.
7. 所有复制相关信息,从info信息中都可以查到.即使重启任何节点,他的主从关系依然都在.
8. 如果发生主从关系断开时,从库数据没有任何损坏,在下次重连之后,从库发送PSYNC给主库
9. 主库只会将从库缺失部分的数据同步给从库应用,达到快速恢复主从的目的
# 主库是否要开启持久化
如果不开有可能,主库重启操作,造成所有主从数据丢失!
# 主从同步的辅助配置
min-slaves-to-write 1
min-slaves-max-lag 3
#那么在从服务器的数量少于1个,或者三个从服务器的延迟(lag)值都大于或等于3秒时,主服务器将拒绝执行写命令
# 主从复制方案
-命令
-在从库上
slaveof 127.0.0.1 6379
slaveof no one # 取消主从
-通过info可以查看主从信息
-配置文件(从库配)
slaveof 10.0.0.101 6379
slave-read-only yes
3 Redis-Sentinel
#主从复制存在的问题:
#1 主从复制,主节点发生故障,需要做故障转移,可以手动转移:让其中一个slave变成master--->高可用
#2 主从复制,只能主写数据,所以写能力和存储能力有限---》集群
# 高可用:哨兵
# 原理
1 多个sentinel发现并确认master有问题
2 选举触一个sentinel作为领导
3 选取一个slave作为新的master
4 通知其余slave成为新的master的slave
5 通知客户端主从变化
6 等待老的master复活成为新master的slave
# 搭建
-一主两从
-sentinel是特殊的redis,单独进程,需要额外启动,也有配置文件,客户端也可以链接
# sentinel配置文件
port 26379
daemonize yes
dir data
protected-mode no
bind 0.0.0.0
logfile "redis_sentinel.log"
# mymaster随便写,127.0.0.1 6379主库地址和端口 2 个哨兵认为主库挂了,才算挂
sentinel monitor mymaster 127.0.0.1 6379 2
#这个配置项指定了需要多少失效时间,一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒,默认为30秒
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
daemonize yes
pidfile /var/run/redis.pid
port 6379
dir "/root/s17/redis/redis4/data"
logfile 6379.log
daemonize yes
pidfile /var/run/redis2.pid
port 6380
dir "/root/s17/redis/redis5/data"
logfile “6380.log”
slaveof 127.0.0.1 6379
slave-read-only yes
port 26379
daemonize yes
dir ./redis4/data
protected-mode no
bind 0.0.0.0
logfile "redis_sentinel3.log"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
import redis
from redis.sentinel import Sentinel
# 连接哨兵服务器(主机名也可以用域名)
# 10.0.0.101:26379
sentinel = Sentinel([('10.0.0.101', 26379),
('10.0.0.101', 26378),
('10.0.0.101', 26377)
],
socket_timeout=5)
print(sentinel)
# 获取主服务器地址
master = sentinel.discover_master('mymaster')
print(master)
# 获取从服务器地址
slave = sentinel.discover_slaves('mymaster')
print(slave)
##### 读写分离
# 获取主服务器进行写入
# master = sentinel.master_for('mymaster', socket_timeout=0.5)
# w_ret = master.set('foo', 'bar')
# slave = sentinel.slave_for('mymaster', socket_timeout=0.5)
# r_ret = slave.get('foo')
# print(r_ret)
标签:mymaster,主从复制,slave,Redis,redis,master,sentinel,yes 来源: https://www.cnblogs.com/liupengfei1123/p/15191226.html