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的一些命令

// 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机器数量的增加也会加重这个问题