【Redis一】Redis2.4.5搭建主从复制环境

Redis主从复制搭建步骤

 

Redis搭建主从复制的步骤十分简单，以下在Windows上操作。

 

注意，本文基于Redis2.4.5，属于较老版本，这里强调版本是在本文写完的时候补上的。对Redis的主从复制机制，失望透顶，没有任何的failover，不知道最新的2.8版本，以及即将出来的3.0版本，是否有改进。

 

1. 解压Redis压缩包至E:\devsoftware\redis-2.4.5-win32-win64\64bit

2.在Redis目录中复制两份redis.conf，分别命名为redis.conf.slave1,redis.conf.slave2

3.修改redis.conf.slave1文件，

• port 6379 改为 port 6380
• 打开slaveof指令，改为slaveof 127.0.0.1 6379
• 将快照文件名改为dbfilename dump.slave1.rdb
• 如果使用AOF方式持久化，则需要将appendfilename appendonly.aof改为appendfilename appendonly.slave1.aof

4. 修改redis.conf.slave2文件

• port 6379 改为 port 6381
• 打开slaveof指令，改为slaveof 127.0.0.1 6379
• 将快照文件名改为dbfilename dump.slave2.rdb
• 如果使用AOF方式持久化，则需要将appendfilename appendonly.aof改为appendfilename appendonly.slave2.aof

5. 启动三个Redis服务器，形成一主两从的主从复制副本集

 

通过上面的启动过程，可见只需要redis-server一个启动脚本即可，它读取不同的配置文件，来完成初始化

 

 

• Master启动时的日志输出

 

 

[21684] 25 Nov 20:54:16 * Slave ask for synchronization
[21684] 25 Nov 20:54:16 * Starting BGSAVE for SYNC
[21684] 25 Nov 20:54:16 * Foregroud saving started by pid 21684
[21684] 25 Nov 20:54:17 * DB saved on disk
[21684] 25 Nov 20:54:17 * Background saving terminated with suc
[21684] 25 Nov 20:54:17 * Synchronization with slave succeeded

 

 

•  Slave1启动时的日志输出

 

[21068] 25 Nov 20:54:15 * Server started, Redis version 2.4.5
[21068] 25 Nov 20:54:15 * DB loaded from disk: 0 seconds
[21068] 25 Nov 20:54:15 * The server is now ready to accept connections on port
[21068] 25 Nov 20:54:16 - DB 0: 1 keys (0 volatile) in 4 slots HT.
[21068] 25 Nov 20:54:16 - 0 clients connected (0 slaves), 1180024 bytes in use
[21068] 25 Nov 20:54:16 * Connecting to MASTER...
[21068] 25 Nov 20:54:16 * MASTER <-> SLAVE sync started
[21068] 25 Nov 20:54:16 * Non blocking connect for SYNC fired the event.
[21068] 25 Nov 20:54:17 * MASTER <-> SLAVE sync: receiving 19 bytes from master
[21068] 25 Nov 20:54:17 * MASTER <-> SLAVE sync: Loading DB in memory
[21068] 25 Nov 20:54:17 * MASTER <-> SLAVE sync: Finished with success

 

主服务器写入从服务器读取数据测试

•  往主服务器上写入一个数据，检查从服务器是否同步

 

 

E:\devsoftware\redis-2.4.5-win32-win64\64bit>redis-cli.exe -h 127.0.0.1 -p 6379
redis 127.0.0.1:6379> set  abc 1
OK
redis 127.0.0.1:6379> get abc
"1"
redis 127.0.0.1:6379>Ctrl + C

 

 

• 两个从服务器的读取操作：

 

 

E:\devsoftware\redis-2.4.5-win32-win64\64bit>redis-cli.exe -h 127.0.0.1 -p 6380
redis 127.0.0.1:6380> get abc
"1"
redis 127.0.0.1:6380> ^C
E:\devsoftware\redis-2.4.5-win32-win64\64bit>redis-cli.exe -h 127.0.0.1 -p 6381
redis 127.0.0.1:6381> get abc
"1"
redis 127.0.0.1:6381>

 

 

从服务器写入，其它服务器读取数据测试

• 往从服务器上写入一个数据，检查其它服务器是否同步

 

 

redis 127.0.0.1:6381> set def 2
OK 

 

• 两个从服务器的读取操作：

 

E:\devsoftware\redis-2.4.5-win32-win64\64bit>redis-cli.exe -h 127.0.0.1 -p 6380
redis 127.0.0.1:6380> get def
(nil)
redis 127.0.0.1:6380> ^C
E:\devsoftware\redis-2.4.5-win32-win64\64bit>redis-cli.exe -h 127.0.0.1 -p 6379
redis 127.0.0.1:6379> get def
(nil)

 结果很意外。意料中，此处有两种情况，一是把写请求转发给主服务器，然后主服务器再同步给从服务器，这是Redis的做法；二是不允许直接写从服务器，这是MongoDB的做法。如下图所示，slave2有两个key，slave1只有1个key

 

 
 

从服务器写入后，其它两台并没有写入，这产生了严重的不一致性问题，如何解决？？

 

.

主服务器挂了，是否会自动的Lead选举

 经测试发现，slave1和slave2已经处于无Lead状态了，测试方法根据前面的主服务器的特性，在slave1和slave2上分别插入一条数据，看能否同步到对方的服务器上，结果显示没有同步，也就是说，slave1和slave2都不是Leader。

当主服务器起来之后，slave1和slave2又成为它的slave，也就是，不管主服务器什么情况，它永远是slave的master。不幸的事情发生了，在Master挂了这段时间里，对slave1和slave2的所有写操作，等到Master起来，由于主从复制，所有对slave的写都被冲洗掉了。

 内存快照文件

在Redis的当前目录下产生了三个rdb文件，分别是dump.rdb,dump.slave1.rdb和dump.slave2.rdb。rdb文件时Redis的内存快照文件。rdb是二进制文件，不过用文本编辑器打开rdb文件，还是能隐隐约约的看到其中的一些内容，如dump.slave2.rdb：

REDIS0002? def? abc?

Redis默认配置启用了内存快照的方式来进行内存数据持久化操作，这在redis.conf文件中定义

save 900 1 //900秒内，有1个key变化，则做快照
save 300 10 //300秒内，有10个key变化，则做快照
save 60 10000 //60秒内，有10000个key变化，则做快照

 计时时间点是从内存快照做完开始算起