Redis主从复制

定义
主从复制,就是主机数据更新后根据配置和策略,自动同步到备用机的master/slaver机制,Master以写为主,Slave以读为主


用处
读写分离,性能扩展
容灾快速恢复


配从(服务器)不配主(服务器)
1.拷贝多个redis.conf文件
2.开启daemonize yes(base.conf)
3.Pid文件名称
4.指定端口
5.log文件名称
6.dump.rdb文件名称
7.appendonly关闭或替换名字(base.conf)
include /Users/vory/Desktop/VoRy/lib/redis-3.2.5/base.conf
port 6379
pidfile /var/run/redis_6379.pid
dbfilename dump_6379.rdb

include /Users/vory/Desktop/VoRy/lib/redis-3.2.5/base.conf
port 6380
pidfile /var/run/redis_6380.pid
dbfilename dump_6380.rdb

info replication
打印主从复制的相关信息
slaveof <ip> <port>
成为某个实例的从服务器
slaveof no one
将从机变为主机
VoRyMacBook-Pro:~ vory$ redis-cli -p 6380
127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0
slave_repl_offset:1
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6380>
每次从机与master断开之后,都需要重新连接(除非配置对应的conf文件)



一主二仆模式演示
1.切入点问题
slave1、slave2是从头开始复制还是从切入点开始复制(例如从4进来,那么之前的123是否也可以复制)
答案:从机 从头开始复制 主机的内容
127.0.0.1:6391> get k1
(nil)
127.0.0.1:6391> slaveof 127.0.0.1 6389
OK
127.0.0.1:6391> get k1
"v1"

2.从机是否可写?即是否可set
答案:不可写
127.0.0.1:6391> slaveof 127.0.0.1 6389
OK
127.0.0.1:6391> set k2 v2
(error) READONLY You can't write against a read only slave.

3.主机shutdown后情况如何?从机是上位还是原地待命?
原地待命,此时依旧可读
127.0.0.1:6391> slaveof 127.0.0.1 6389
OK
====================主机shutdown====================
127.0.0.1:6390> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6389
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:1051
master_link_down_since_seconds:66
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
====================主机重新上线====================
127.0.0.1:6390> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6389
master_link_status:up
master_last_io_seconds_ago:6
master_sync_in_progress:0
slave_repl_offset:57
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

4.主机重新启动后,主机新增记录,从机还能否顺利复制?
答案:依旧顺利复制
5.其中一台从机down后情况如何?依照原有它能跟上大部队吗?
这特喵的什么意思啊?没有看懂????
从机shutdown之后再上线是否还有主机数据?
有啊?如果开启了RDB,shutdown之后就会有,没开启就没有= =
此时已经不再是从机了




薪火相传
1.上一个slave可以是下一个slave的Master
2.slave同样可以接受其它slave的连接和同步请求,那么该slave作为链条中下一个的master,可以有效减轻master的写压力,去中心化降低风险
3.中途变更专项:会清除之前的数据,重新建立拷贝最新的
4.缺点:一旦某个slave宕机,后面的slave都没法备份




反客为主
这个说的是哪个?????为什么我没试验出来?????
当一个master宕机后,后面的slave可以立刻升为master,其后面的slave不用做任何修改

slaveof no one:使当前数据库停止于其他数据库的同步,并转为主数据库




哨兵模式(sentinal)
sentinel系统主要用于管理多个redis服务器,该系统主要执行三个任务:监控、提醒、自动故障转移

反客为主的自动版,能够后台监控主机是否故障,如果故障则根据投票数自动将从机切换为主机
配置哨兵模式
1.调整为一主二仆模式,假设为6379带6380、6381
2.新建sentinel.conf文件(redis.conf文件同目录下)
3.sentinel.conf中填写如下内容
sentinel monitor mymaster <ip> <主机redis端口号> <num>
其中mymaster为监控对象起的服务器名称,任意指定,你开心就好
num为至少有多少个哨兵同意迁移的数量,即判断客观下线所需的主管下线sentinel个数,通俗来讲是:主机down后slave投票决定谁接替成为主机,得票数多少后转换角色
启动哨兵
redis-sentinel  sentinel.conf文件全路径
例如
redis-sentinel /opt/redis-3.1.5/sentinel.conf
sentinel.conf
故障恢复
sentinel的一些命令
// sentinel的基本状态信息
INFO
// 列出所有被监视的主服务器,以及这些主服务器的当前状态
SENTINEL masters
// 列出给定主服务器的所有从服务器,以及这些从服务器的当前状态
SENTINEL slaves <master name>
// 返回给定名字的主服务器的IP地址和端口号
SENTINEL get-master-addr-by-name <master name>
// 重置所有名字和给定模式pattern相匹配的主服务器
// 重置操作会清除主服务器目前的所有状态,包括正在执行中的故障转移,并移除目前已经发现和关联的主服务器的所有从服务器和Sentinel
SENTINEL reset <pattern>
// 在主服务器失效时,在不询问其他Sentinel意见的情况下,强制开始一次自动故障转移。但是它会给其它sentinel发送一个最新的配置,其他sentinel会跟着这个配置进行更新
SENTINEL failover <master name>



复制原理
1.每次从机联通后,都会向主机发送sync指令
2.主机接受到命令后,立刻启动后台的存盘进程,同时收集所有接收到的用于修改数据库的执行。在后台进程执行完毕之后,,发送rdb文件给从机,以完成一次同步
3.从机收到rdb文件后,进行全盘加载(全量复制)
4.之后每次主机的写操作,都会立刻发送给从机,从机执行相同的命令(增量复制)
5.只要是重新连接master,一次完全同步(全量复制)将被自动执行



复制的缺点
由于所有的写操作都是现在master上操作,之后同步更新到slave上,所以从master同步到slave会有一定的延迟,当系统繁忙时,延迟问题会更加严重,slave机器数量的增加也会加重这个问题
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值