redis主从切换会堵塞进程吗_redis主从配置及主从切换 .

环境描述：

主redis：192.168.10.1 6379

从redis：192.168.10.2 6380

一、主从配置

1、将主从redis配置文件redis.conf中的aemonize no 改为 yes

2、修改从redis配置文件redis.conf中的port 6379 改为 6380，添加slaveof 192.168.10.1 6379

3、启动主从服务

主redis：

[root@localhost redis-2.8.3]# src/redis-server /soft/redis-2.8.3-master/redis-2.8.3/redis.conf

从redis：

[root@localhost redis-2.8.3]# src/redis-server /soft/redis-2.8.3-slave/redis-2.8.3/redis.conf

4、测试数据同步

主redis：

[root@localhost redis-2.8.3]# src/redis-cli -p 6379

127.0.0.1:6379> set name abc

OK

127.0.0.1:6379> get name

"abc"

127.0.0.1:6379>

从redis：

[root@localhost redis-2.8.3]# src/redis-cli -p 6380

127.0.0.1:6380> get name

"abc"

127.0.0.1:6380>

5、默认是读写分离的

在从redis：

[root@localhost redis-2.8.3]# src/redis-cli -p 6380

127.0.0.1:6380> set name 123

(error) READONLY You can't write against a read only slave.

二、主从切换

1、停止主redis

[root@localhost redis-2.8.3]# src/redis-cli -n 6379 shutdown

[root@localhost redis-2.8.3]# src/redis-cli -p 6379

Could not connect to Redis at 127.0.0.1:6379: Connection refused

not connected>

2、将从redis设成主redis

[root@localhost redis-2.8.3]# src/redis-cli -p 6380 slaveof NO ONE

OK

3、测试从redis是否切换从主redis

[root@localhost redis-2.8.3]# src/redis-cli -p 6380

127.0.0.1:6380> set name 123

OK

127.0.0.1:6380> get name

"123"

127.0.0.1:6380>

4、原来的主redis恢复正常了，要重新切换回去

1)将现在的主redis的数据进行保存

[root@localhost redis-2.8.3]# src/redis-cli -p 6380

127.0.0.1:6380> get name

"abc"

127.0.0.1:6380> set name 123

OK

127.0.0.1:6380> get name

"123"

127.0.0.1:6380> save

OK

127.0.0.1:6380> get name

"123"

127.0.0.1:6380>

2)将现在的主redis根目录下dump.rdb文件拷贝覆盖到原来主redis的根目录

3)启动原来的主redis

[root@localhost redis-2.8.3]# src/redis-server /soft/redis-2.8.3-master/redis-2.8.3/redis.conf

4)在现在的主redis中切换

[root@localhost redis-2.8.3]# src/redis-cli -p 6380 slaveof 192.168.10.1 6379

OK

当redis的master出现问题的时候,是否依然可以请求slave

slave-serve-stale-data yes

slave是否只读

slave-read-only yes

slave每隔10s  ping 一次master

repl-ping-slave-period 10

slave的优先级,,master选举的依据

slave-priority 100

*redis.conf配置文件中配置  save "" 可以禁用rdb快照方式 , 但是在redis的客户端执行 save命令的话 ,  依然会产生 rdb文件

*禁用了rdb快照方式以后 , redis的主从同步依然会产生rdb文件

*主从同步从库断开以后 , 重新建立主从同步 , 会从断开的offset开始同步 ,

*禁用rdb快照以后 , 只是会保证 , 没有 自动触发条件 产生rdb文件

redis高可用(sentinel)

sentinel配置:

cd /opt/redis320/config

touch sentinel.conf

vim sentinel.conf

sentinel monitor mymaster 192.168.10.160 6379 2

sentinel down-after-milliseconds mymaster 60000

sentinel failover-timeout mymaster 180000

sentinel parallel-syncs mymaster 1

#sentinel monitor resque 192.168.1.3 6380 4

#sentinel down-after-milliseconds resque 10000

#sentinel failover-timeout resque 180000

#sentinel parallel-syncs resque 5

启动sentinel :

redis-server /opt/redis320/config/sentinel.conf --sentinel

出现这样的提示表示 sentinel成功

1322:X 05 Jun 19:14:56.449 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

1322:X 05 Jun 19:14:56.449 # Sentinel ID is 6927b6e2b5539dedb2fd040ced7a5bd6d1b52a77

1322:X 05 Jun 19:14:56.449 # +monitor master mymaster 192.168.10.160 6379 quorum 1

1322:X 05 Jun 19:14:56.452 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 192.168.10.160 6379

1322:X 05 Jun 19:15:56.454 # +sdown slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 192.168.10.160 6379

1322:X 05 Jun 19:16:03.166 # +sdown master mymaster 192.168.10.160 6379

1322:X 05 Jun 19:16:03.166 # +odown master mymaster 192.168.10.160 6379 #quorum 1/1

在运行sentinel的时候要注意:

*是否有密码配置  , 如果被监控的master-slave是有密码设置的,需要在sentinel的配置文件中添加  sentinel auth-pass 配置

*关闭防火墙

我们配置两个sentinel进程：

vi sentinel.conf

port 26379

sentinel monitor mymaster 127.0.0.1 6000 2

sentinel auth-pass mymaster 123456

vi sentinel.conf

port 26479

sentinel monitor mymaster 127.0.0.1 6000 2

sentinel auth-pass mymaster 123456

启动sentinel服务(到对应的目录执行相应的命令)：

redis-server sentinel.conf --sentinel

查看日志：

[7014] 11 Jan 19:42:30.918 # +monitor master mymaster 127.0.0.1 6000 quorum 2

[7014] 11 Jan 19:42:30.923 * +slave slave 127.0.0.1:6002 127.0.0.1 6002 @ mymaster 127.0.0.1 6000

[7014] 11 Jan 19:42:30.925 * +slave slave 127.0.0.1:6001 127.0.0.1 6002 @ mymaster 127.0.0.1 6000

从对应的日志观察到，一个master服务，两个slave服务

我们现在来kill master进程

[root@localhost slave1]# ps -ef|grep redis

root      6960     1  0 19:29 ?        00:00:02 redis-server *:6000

root      6968     1  0 19:30 ?        00:00:01 redis-server *:6001

root      6975     1  0 19:30 ?        00:00:01 redis-server *:6002

root      7014  6570  0 19:42 pts/0    00:00:01 redis-server *:26479

root      7017  6789  0 19:42 pts/5    00:00:01 redis-server *:26379

root      7021  6729  0 19:46 pts/3    00:00:00 grep redis

[root@localhost slave1]# kill -9 6960

我们观察日志：

[7014] 11 Jan 19:43:41.463 # +sdown master mymaster 127.0.0.1 6000

[7014] 11 Jan 19:46:42.379 # +switch-master mymaster 127.0.0.1 6000 127.0.0.1 6001

master切换了，当6000端口的这个服务重启的时候，他会变成6001端口服务的slave。

因为sentinel在切换master的时候，把对应的sentinel.conf和redis.conf文件的配置修改。

期间我们还需要关注的一个问题：sentinel服务本身也不是万能的，也会宕机，所以我们还得部署sentinel集群，象我这样多启动几个sentinel。

关注这个配置：

sentinel monitor mymaster 127.0.0.1 6000 2

这个后面的数字2,是指当有两个及以上的sentinel服务检测到master宕机，才会去执行主从切换的功能。

redis持久化

Redis的持久化有两种 , RDB和AOF , 这两种方式都有他们的特点, 可以根据特点在不同的应用场景使用

RDB原理和场景:

说到rdb的原理,首先要说到这个的触发条件 , 一种是手动触发 , 一种是自动触发

自动触发 的条件是在 配置文件 中配置的 ,

save 900 1       #900s的时间内如果有一个key有变化,就会触发rdb

save 300 10      #300s的时间内如果有10个key有变化

save 60 10000    #60s的时间内如果有10000个key有变化

可以通过   save  ""  来禁用

手动触发  是通过在客户端命令行执行 save 或者  bgsave  命令触发的

这两个命令的区别在于 是否会阻塞 当前的客户端请求,  save会阻塞客户端请求 , 而bgsave不会阻塞客户端请求,

save是占用当前的主进程将所有的redis数据快照到  rdb  文件中

bgsave是主进程fork一个子进程  ,  然后通过 copy - on - write 来将数据快照到rdb文件中

但是bgsave有一个缺陷 , 因为是使用的 copy - on - write 技术 , 所以 RDB模式需要Redis服务所占内存的1倍的内存 ,如果数据量太大而内存太小的话,

就会导致 数据不会完整的快照到rdb文件中 , 所以rdb技术只是适合备份 , 如果是需要可靠性的话,就需要 AOF 来支持了,下面会介绍 AOF技术

bgsave的工作流程：

Redis调用fork()。于是我们有了父子两个进程。

子进程开始将数据集写入一个临时RDB文件。

当子进程完成了新RDB文件，替换掉旧文件。

rdb除了备份以外 , 另一个重要的应用场景就是 主从同步 了

AOF的原理和场景:

aof的方式是类似于 mysql的binlog , 如果大家对于mysql比较熟悉的话,可能会理解的很快 ,  和mysql 的binlog 的区别就是 , binlog是可以用于进行mysql主从同步的,

但是aof只是redis用于持久化的方式 .

aof的原理就是用户在客户端的操作命令都会记录到aof文件中 ,  触发的条件在配置文件中进行配置 ,

appendonly   yes   //启用aof持久化方式

# appendfsync   always     //收到写命令就立即写入磁盘, 最慢 , 但是能够保证完全的持久化

appendfsync      everysec   //每分钟写入磁盘一次,   在性能和持久化之间做了很好的折中        (默认配置,  很好)

#appendfsync    no            //完全依赖os,  性能最好 , 持久化没有保证

aof主要用户对数据需要高可靠性的场景.

但是记录每次用户的操作记录 , 可能造成的后果是 出现很多的无用指令 , 就是可以被优化的 , 所以 aof 又有着两个配置 ,对aof文件进行重写 ,

#当aof文件达到64m的时候,会自动 重写 aof文件  ,缩小文件大小

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

这段配置的意思是 当aof的文件到达 64m 的时候, 对aof文件进行重写 , 使得aof文件变得更小 , 以后每增长 100%(64m  , 128m  , 192m ... ) 的时候,都会触发这个优化动作;

但是aof的这个重写操作的原理是  rewrite会像replication一样，fork出一个子进程，创建一个临时文件，遍历数据库，将每个key、value对输出到临时文件。  也就是说 ,

还是 copy-on-write 的问题 ...