Redis（1.12）Redis cluster搭建常见错误
【1】gem install redis 报错
redis-cluster安装需要通过gem install redis来安装相关依赖。否则报错。
通过gem install redis执行后会出现两个问题：
（1.1）缺少zlib依赖
问题：
ERROR: Loading command: install (LoadError)
cannot load such file -- zlib
ERROR: While executing gem ... (NoMethodError)
undefined method 'invoke_with_build_args' for nil:NilClass
解决：
通过yum install zlib-devel 安装zlib库
然后集成zlib库到ruby环境
cd /usr/local/ruby-2.2.7/ext/zlib #这个路径，其实就是你的安装包解压路径
ruby extconf.rb
重要：ext/openssl/Makefile 增加 top_srcdir = ../..
//这一步如果不修改，make时会爆出另外一个错误
//make:*** No rule to make target '/include/ruby.h', needed by 'zlib.o'. Stop
make && make install
（2）缺少openssl库
问题：
ERROR: While executing gem ... (Gem::Exception)
Unable to require openssl, install OpenSSL and rebuild ruby (preferred) or use non-HTTPS sources
解决：
通过yum install openssl-devel 安装openssl库
然后集成到ruby环境
cd /usr/local/ruby-2.2.7/ext/zlib
ruby extconf.rb
重要：ext/openssl/Makefile 增加 top_srcdir = ../..
//修改Makefile中的$(top_srcdir)为../..
make && make install
【2】can't connect to node 192.168.1.13:7001
当报无法连接的时候，通过telnet192.168.1.13:7001 是无法连接通，则说明配置的哪里有问题导致的
可能导致问题的原因
原因1：redis的配置文件，发现，在配置文件中配置bind 127.0.0.1这个地址,修改指定的IP地址，可以同时指定127.0.0.1，这样本机和ip地址都可以访问
参考：bind 192.168.1.13 127.0.0.1
当通过原因1解决后，发现还是报错，虽然telnet是可以正常连接了，但是还是报上面的错误
原因2：因为在复制集群的时候，原来安装好的Redis是配置了账号密码，必须要每个redis去掉密码后再配置集群，再在集群中配置账号密码
注释掉配置文件中的配置密码位置
#requirepass 123456
【3】Node 192.168.135.173:7001 is not empty
错误详情：Node 192.168.135.173:7001 is not empty. Either the node already knows other nodes (check with CLUSTER NODES) or contains some key in database 0.
意思是说，数据库已经有数据了，如果要构建新的集群，需要删掉这些数据。
（1）把cluster-config-file生成的配置文件删除
（2）将需要新增的节点下aof、rdb等本地备份文件删除；pid文件删除；如果还不行就登录进去 flushall
（3）kill掉所有的Redis服务，重新启动。
在往redis cluster集群环境中添加节点时遇到一个问题，提示新增的Node不为空： [root@slave2 redis]# redis-trib.rb add-node --slave 192.168.1.103:7004 192.168.1.102:7002 ....... [ERR] Node 192.168.1.103:7004 is not empty. Either the nodealready knows other nodes (check with CLUSTER NODES) or contains some key in database 0. 解决办法：(如果redis cluster所有节点同时断电同时宕机, 则节点重启后, 只能重新创建集群, 之前的集群数据全部丢失! 重新创建集群前,各节点要如下操作) 1）将192.168.1.103节点机redis下的aof、rdb等本地备份文件全部删除 2）同时将新Node的集群配置文件删除，也即是删除redis.conf里面cluster-config-file指定所在的文件； 3）"redis-cli -c -h 192.168.1.103 -p 7004"登陆后，执行 "flushdb"命令进行清除操作 4）重启reds服务 5）最后再次执行节点添加操作
【4】[ERR] Not all 16384 slots are covered by nodes
[ERR] Not all 16384 slots are covered by nodes
[WARNING] Node 192.168.1.100:7000 has slots in importing state
由于redis clster集群节点宕机（或节点的redis服务重启），导致了部分slot数据分片丢失；在用check检查集群运行状态时，遇到错误；
[root@slave2 redis]# redis-trib.rb check 192.168.1.100:7000
........
[ERR] Not all 16384 slots are covered by nodes.
原因分析：
这个往往是由于主node移除了，但是并没有移除node上面的slot，从而导致了slot总数没有达到16384，其实也就是slots分布不正确。
所以在删除节点的时候一定要注意删除的是否是Master主节点。
解决办法：
官方是推荐使用redis-trib.rb fix 来修复集群。通过cluster nodes看到7001这个节点被干掉了。可以按照下面操作进行修复
[root@slave2 redis]# redis-trib.rb fix 192.168.1.100:7000
修复完成后再用check命令检查下是否正确（查看别的节点）
[root@slave2 redis]# redis-trib.rb check 192.168.1.101:7002
只要输入任意集群中节点即可，会自动检查所有相关节点。
可以查看相应的输出看下是否是每个Master都有了slots。
如果分布不均匀那可以使用下面的方式重新分配slot:
[root@slave2 redis]# redis-trib.rb reshard 192.168.1.100:7000
特别注意：
在部分节点重启后重新回到集群中的过程期间，在check集群状态的时候会出现"[ERR] Not all 16384 slots are covered by nodes."这个报错，
需要稍微等待一会，等重启节点完全回到集群中后，这个报错就会消失！
======================================================
=============================================================================================
温馨提示：
- 集群中只要有一组master-slave节点同时挂点，则集群服务也会挂掉；待该组master和slave节点的redis恢复后，这部分slot槽的数据也会丢失。
- 集群中1/2或master节点挂掉，则集群服务也会挂掉；待这些master节点服务重启后，会自动加入到集群中，需等待一段时间，集群恢复正常，数据不会丢失。
- 集群中master节点关闭，需要等待一小段时间，它对应的slave节点就会变成master节点，集群服务正常，数据会随之到新的maser节点的slot。
- master节点挂掉后，重启redis服务（一定要在原来的aof和nodes*.conf文件路径下启动），则会自动加入到cluster集群中，并会变成slave节点。
- 新添加的master节点的slot默认为0，master主节点如果没有slots，存取数据就都不会被选中! 故要为新增加的master节点进行reshard重新分配slot。
- slave从节点的slot为0，数据不会存储在slave节点！只会存储在master主节点中，master节点才有slot数值。
======================================================
注意：每一组的master-slave节点不能同时挂掉或短时间内先后挂掉，否则这部分slot内的数据就会丢失。
比如说一主一从，当master节点挂掉后，数据都保存到slave节点内，稍过一会，slave节点就会被选举为新的master节点。
老的master节点重启后重新回到集群中，并自动变为它原来的slave(现在是新的master)的slave节点，并自动同步数据。
这个时候新的master节点如果挂掉，则数据同样会保存到新的slave节点中，新的slave节点过一段时间同样会被再次选举为新的master，如此类推....
如果master节点和它的slave节点同时挂掉，或者在其中一个挂掉后还没有来得及恢复到集群中，另一个就挂掉，这种情况下，这部分slot槽的数据肯定就没有了。
所以说，一般会重启一个节点，待该节点恢复到集群中后，再可以重启它对应的slave或master节点。
redis作为纯缓存服务时，数据丢失，一般对业务是无感的，不影响业务，丢失后会再次写入。但如果作为存储服务(即作为存储数据库)，数据丢失则对业务影响很大。
不过一般业务场景，存储数据库会用mysql、oracle或mongodb。
======================================================
【5】[WARNING] Node 192.168.1.100:7000 has slots in importing state
redis cluster集群节点重启后，要想恢复集群状态，正确的做法是：
1）要在各个节点原来的appendonly.aof ，dump.rdb，nodes_*.conf 文件所在路径下重启redis服务。这样就能确保redis启动后用到之前的数据文件。
（可以使用find命令查找这些文件所在路径，然后在这个路径下启动redis服务）
2）各个节点的redis服务正常启动后，就可以直接查看redis cluster状态了，检查集群状态是否恢复。
注意：
一定要在原来的数据文件的路径下启动redis，如果启动的路径错误，则读取的数据文件就不是之前的了，这样集群就很难恢复了。这个时候就需要删除之前的数据文件，
重新创建集群了。(或者直接在/data/redis-4.0.6/redis-cluster/700*目录下的redis.conf文件里的cluster-config-file指定文件的绝对路径)
集群节点的redis服务重启后，check集群状态，如有下面告警信息，处理如下：
[root@redis-node01 redis-cluster]# /data/redis-4.0.6/src/redis-trib.rb check 192.168.1.100:7000 ........... ........... [OK] All nodes agree about slots configuration. >>> Check for open slots... [WARNING] Node 192.168.1.100:7000 has slots in importing state (5798,11479). [WARNING] Node 192.168.1.100:7001 has slots in importing state (1734,5798). [WARNING] Node 192.168.1.101:7002 has slots in importing state (11479). [WARNING] The following slots are open: 5798,11479,1734 >>> Check slots coverage... [OK] All 16384 slots covered.
解决办法:
一定要登录到告警信息中的节点和对应的端口上进行操作。
执行"cluster setslot <slot> stable"命令，表示取消对槽slot 的导入（ import）或者迁移（ migrate）。
执行后，这部分slot槽的数据就没了。
[root@redis-node01 redis-cluster]# /data/redis-4.0.6/src/redis-cli -h 192.168.1.100 -c -p 7000 192.168.1.100:7000> cluster setslot 5798 stable OK 192.168.1.100:7000> cluster setslot 11479 stable OK [root@redis-node01 redis-cluster]# /data/redis-4.0.6/src/redis-cli -h 192.168.1.100 -c -p 7001 192.168.1.100:7001> cluster setslot 1734 stable OK 192.168.1.100:7001> cluster setslot 5798 stable OK [root@redis-node01 redis-cluster]# /data/redis-4.0.6/src/redis-cli -h 192.168.1.101 -c -p 7002 192.168.1.101:7002> cluster setslot 11479 stable
OK，再次检查集群，一切正常
