【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变化，则做快照

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