关于redis:Redis的持久化

开发环境原本一片祥和（外表上看起来），就在为上线做筹备，验证零碎某一个关键性问题的时候，Redis集群忽然不能用了，并给出了上面这段十分“敌对”的提醒。

Caused by: redis.clients.jedis.exceptions.JedisDataException: 
    MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk.
    Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). 
    Please check the Redis logs for details about the RDB error.

尽管第一次见到这个问题，然而这里呈现的RDB，只能联想到Redis的长久化。

于是，从长久化开始找问题。
首先是确保生成的rdb文件没有问题，在服务器上执行命令查看rdb的合法性
redis-check-rdb dump.rdb

顺带将aof也检测一下
redis-check-aof appendonly.aof

如果aof文件存在问题，还能够通过命令修复（这里的修复是将有问题的局部删除）
redis-check-aof --fix appendonly.aof

我啰嗦一下redis的长久化机制，Redis是折腾内存的，但内存有个问题，一旦断电，所有的数据都会失落。所以就须要有一个机制来解决这种可能呈现的状况。于是Redis呈现了两种长久化策略，别离是RDB和AOF。

RDB

RDB就是指Redis DataBase，是Redis中默认开启的长久化策略，在配置文件中处于SNAPSHOTTING模块。

规定

当满足某一种规定时，Redis就会fork一个子过程（一说Redis单线程），将数据写入到一个临时文件，当这个临时文件写完之后，再将原来的dump.rdb文件替换为这个临时文件，这就实现了一次长久化操作。Redis配置文件中默认提供了三种规定：

• 900秒内（15分钟）至多有一个key变更
• 300秒内（5分钟）至多有十个key变更
• 60秒内至多有一万个key变更
  每一种规定被满足都会触发长久化，咱们就能够依据本人的状况批改这个配置或增减配置。
  当然，还有另外两种状况也会生成rdb文件，一种是敞开redis的时候，还有一种是执行save或者bgsave命令的时候；尽管flushall命令也会生成rdb文件，但这条命令是清空数据库，会失去一个空的rdb文件。

复原RDB

将rdb文件放到dir指定的目录下，并确保rdb开启，启动redis即可。

敞开RDB

将所有规定正文后，配置 save ' ' 。

其余配置

• stop-writes-on-bgsave-error: 当长久化呈现问题时，进行写入redis，默认yes
• rdbcompression: 对rdb文件做压缩，默认yes
• rdbchecksum: 对生成的rdb文件做校验，默认yes
• dbfilename: 保留的rdb文件名称，默认dump.rdb
• dir: 保留rdb文件的门路；复原rdb数据时将rdb文件放在此目录下

优缺点

RDB文件紧凑，占用空间小；写入rdb时不会占用主过程；适宜大量数据的备份与复原；
RDB只能备份到某个工夫节点，并且可能会失落最初一次备份后的更改数据；此外，fork子过程时，须要一块与主过程雷同大小的内存空间；

AOF

AOF是指 append only file，是一种记录执行命令的形式，将执行命令追加到文件开端，redis配置种默认敞开。处于配置种的 APPEND ONLY MODE模块。

开启

配置文件中批改appendonly值为yes

规定

AOF也有本人的规定：

• appendfsync always：每一条命令都会做长久化，性能耗费大
• appendfsync everysec：每一秒做一次长久化，可能会失落一秒内的数据
• appendfsync no：长久化机会交由操作系统管制，安全性低

复原RDB

将aof文件放到dir指定的目录下，并确保rdb开启，启动redis即可。

其余配置

• appendfilename：生成aof文件名称，默认appendonly.aof
• no-apendfsync-on-rewrite: 这个配置就是我查到的解决问题的配置，默认为no，搜到的材料都让我改成yes。不明确为什么要这么改，所以没有批改。
• auto-aof-rewrite-min-size: 为了防止aof文件过于臃肿，容许aof文件达到某一大小后触发重写，重写会将aof做整合，升高磁盘占用。该配置须要满足上面的百分比。
• auto-aof-rewrite-percentage: aof重写百分比配置，默认100%。当aof文件达到上一个文件的某个百分比时，触发重写，该配置需满足下面的重写最小尺寸。

完结

在解决问题的时候，还找到了一个很奇怪的景象，cpu为什么这么高？

接下来不晓得怎么解决，又想到之前看过的文章Redis和es被利用挖矿，索性不深究，间接kill。