部署redis集群，从服务器上的数据会因为端口没有开放，同步时key会被覆盖？

2021.03.19 最后定位了问题，就是redis集群没有设置密码，别黑客攻击了，然后被执行了flushall 命令，把key全部 清除掉了

---

目前开发中遇到一个问题，就是部署的redis集群中，存储的key会莫名其妙的被删除，具体原因还未定位到

 

具体现象是：在03-02 21:47:40  是redis集群中都存在key

但是在03-02 21:53:40 在redis集群中确找不到key了，

redis集群配置在/redis-cluster 下面，但是相应的master 和slave 配置文件都没有配置日志路径，无法查询到日志

 

查看redis的aof 日志，发现居然这个日志中都没有时间的，也是没啥用啊，

DEL
$27
authAddLift_822300001000042
*3
$3
SET
$33
parking_subscriber140317589856080
$17
"6L05368PAJ0E362"
*2
$3

查看cluster的 rdb 文件，也没法打开，这个主要是用来恢复数据用的。

 

但是通过cluster node 查询到 有三个节点的状态是fail ，初步怀疑是 这三个节点虽然能连上的，但是状态有问题，正好这个key是存储在这个节点上的，

或者本来是存储在这个节点上的，能访问到，在某一个时刻，需要主从数据同步的时候，主的节点上没有，从的节点上有，然后就把数据给覆盖了？？？

 

异常的时候：

172.6.135.19:7003> CLUSTER NODES
9a1eb8a0cc7aa97d0e437d0d420b483be727e927 172.6.135.19:7001@17001 master - 0 1614738055688 1 connected 0-5460
3cf4888935ddf1ed758872fa4996dff57533d88c 172.6.135.19:7002@17002 master - 0 1614738055000 2 connected 10923-16383
34e4591b5684f4a91eaf6e23359d3572a9d3374d 172.6.135.10:7006@17006 slave,fail 3cf4888935ddf1ed758872fa4996dff57533d88c 1599987104995 1599987101989 6 connected
b38824033aa9599f57969d5cc7078eacca721bee 172.6.135.19:7003@17003 myself,master - 0 1614738050000 8 connected 5461-10922
a8010691b4cdc166a211f114364562447ea89e98 172.6.135.10:7004@17004 slave,fail b38824033aa9599f57969d5cc7078eacca721bee 1599987099987 1599987096000 8 connected
f66f51c4b09404994d2bd18fe1a1cf0d16c97411 172.6.135.10:7005@17005 slave,fail 9a1eb8a0cc7aa97d0e437d0d420b483be727e927 1599987102992 1599987099000 5 connected

正常的时候：【之前是服务器上 7004  7005  7006 端口没有开放】

172.6.135.10:7005> cluster nodes
b38824033aa9599f57969d5cc7078eacca721bee 172.6.135.19:7003@17003 master - 0 1614739627000 8 connected 5461-10922
34e4591b5684f4a91eaf6e23359d3572a9d3374d 172.6.135.10:7006@17006 slave 3cf4888935ddf1ed758872fa4996dff57533d88c 0 1614739625766 6 connected
3cf4888935ddf1ed758872fa4996dff57533d88c 172.6.135.19:7002@17002 master - 0 1614739626768 2 connected 10923-16383
a8010691b4cdc166a211f114364562447ea89e98 172.6.135.10:7004@17004 slave b38824033aa9599f57969d5cc7078eacca721bee 0 1614739624765 8 connected
f66f51c4b09404994d2bd18fe1a1cf0d16c97411 172.6.135.10:7005@17005 myself,slave 9a1eb8a0cc7aa97d0e437d0d420b483be727e927 0 1614739625000 5 connected
9a1eb8a0cc7aa97d0e437d0d420b483be727e927 172.6.135.19:7001@17001 master - 0 1614739627769 1 connected 0-5460

 

172.6.135.19:7001主   172.6.135.10:7005从

172.6.135.19:7002主   172.6.135.10:7006从

172.6.135.19:7003主   172.6.135.10:7004从               本来这里配置的是后者为主，但是因为一次故障，7004宕机了，然后将7003升为主，7004再回复的时候，就成了从

 

我在修改了集群的配置文件后，需要重启，如何重启？主要是修改配置文件增加日志，保证缓存数据不丢失

---

那现在遇到的这个问题的具体原因可能是：

之前存储在slave节点上的数据，因为master 需要与他同步，所以数据被覆盖了？？？

---

2021-03-05 

今天又复现了，和之前说的端口放开与否没有任何关系了

因为前两天出现的时候，已经把端口开放了。

那现在看到的现象是：03.02 19:37:47 key是存在的

但是在03.02 19:44:00 key 就找不到了

所以要定位出，在这7分钟到底发生了什么？？？

 

查看各个节点的aof 日志看看，因为rdb没法打开查看

 

 

 

看到fluashall

redis  aof日志中 flushall  表示什么？？？

可能问题的关键就在这里，因为flushall 删除了原来的全部数据

---

rdb 持久化的策略时间改长一点

# save 900 1
# save 300 10
# save 60 10000
save 1800 1

aof重写的时间间隔也扩大一点

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

修改成

auto-aof-rewrite-percentage 200
auto-aof-rewrite-min-size 256mb

 

看通过这样的策略对 性能影响小一点，这样会不会解决这个问题

---

配置重写触发机制

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。

触发AOF快照

根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。

根据AOF文件恢复数据

正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。

但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。

AOF的重写机制

前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。

重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件。最后替换旧的aof文件。

触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。