redis 的 AOF 文件 60G 了,我该怎么压缩这个文件呢

2020-12-18 21:29:46 +08:00
 ADANMEI

服务器上的 AOF 文件 60G,我能通过bgrewriteaof这个命令压缩吗?压缩效果会怎么样?现在 redis 使用内存 7G 。 redis 版本 3.2

4598 次点击
所在节点    Redis
20 条回复
ADANMEI
2020-12-18 21:52:48 +08:00
也开启过自动重写
```
appendfilename "appendonly.aof"
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-rewrite-incremental-fsync yes
```
nightspirit
2020-12-18 22:34:21 +08:00
AOF 重写:
(1) 随着 AOF 文件越来越大,里面会有大部分是重复命令或者可以合并的命令( 100 次 incr = set key 100 )
(2) 重写的好处:减少 AOF 日志尺寸,减少内存占用,加快数据库恢复时间
MurphyL0
2020-12-18 22:51:39 +08:00
auto-aof-rewrite-min-size 这个改大些
black11black
2020-12-19 05:37:16 +08:00
问个题外话,lz 的 aof 在达到这个体量以后性能怎么样啊。看网上一些测试说超过一千万行以后性能缩到不如 mongodb
aijam
2020-12-19 05:44:56 +08:00
@black11black 不知道你从哪里看来的。aof 和 redis 性能没啥关系吧?归根到底主存储还是全内存。
black11black
2020-12-19 05:52:22 +08:00
@aijam 表达失误,我的意思不是 aof 导致性能下降,而是想知道行数增加到一定程度后,redis 持久方案下对性能影响有多少
lewis89
2020-12-19 07:44:48 +08:00
@black11black #6

Using AOF Redis is much more durable: you can have different fsync policies: no fsync at all, fsync every second, fsync at every query. With the default policy of fsync every second write performances are still great (fsync is performed using a background thread and the main thread will try hard to perform writes when no fsync is in progress.) but you can only lose one second worth of writes.

不会英文 不会读文档,弱点就来了吧,官方说的很清楚了 AOF 你可以选 log 写的机制,而且是后台线程在操作,AOF 并不是事务性的,可能会丢失

https://redis.io/topics/persistence
arloor
2020-12-19 09:23:21 +08:00
aof 重写可以在头部使用 rdb 来减少 aof 文件的大小
具体搜下这个配置:server.aof_use_rdb_preamble
black11black
2020-12-19 09:29:59 +08:00
@lewis89 你没回错人?驴唇不对马嘴?
lewis89
2020-12-19 09:37:50 +08:00
@black11black #9 持久化是异步线程,为什么会对性能有影响?而且 AOF 官方说了 不会同步写入 log 停电会可能丢失 你真的了解 Redis ? 别人云亦云。
lewis89
2020-12-19 09:39:09 +08:00
@black11black #9 就算是写 10 亿行,只要是磁盘顺序写,根本无压力好吗?而且又是异步线程写入。
thet
2020-12-19 09:55:38 +08:00
aof 重写不是自动的吗
cxshun
2020-12-19 10:14:32 +08:00
@ADANMEI #1 是不是尝试把 rewrite-percentage 调低点,这里 100 是指你的 aof 文件大小扩大一倍才触发 rewrite,假设你调到 5,以你现在的大小来看,那么你的 aof 文件增加 3g 就会触发重写。

PS:你的 redis 使用内存 7g,正常来说 aof 文件不会那么大的,感觉像是一直没有触发重写的样子。
huntcool001
2020-12-19 17:49:41 +08:00
不应该怎么大的.

你连上命令行,输入:

info Persistence , 回车

贴一下最后面 aof_开头的信息.
huntcool001
2020-12-19 17:54:20 +08:00
我看其他人也报告过这个问题.可能是老版本的 bug 吧. 业务量低的时候手动 bgrewriteaof 触发一下就好了.应该压缩到 10G 以下
bootvue
2020-12-19 20:54:53 +08:00
redis cluster 集群 把数据分一分会不会好一点
black11black
2020-12-19 21:08:47 +08:00
@lewis89 你发的帖子里自己都解释了持久化策略有逐条同步,每秒同步等等。有 dump 事务,我提问一下对性能影响怎么了,正常问题,轮得到你来这里跳脚。还问我真的了解 redis,笑死个人,你是某斯林,不了解的人不让在论坛里说话?还是你比我多了解多少?

磁盘顺序写,基于异步写入响应,我们对单机 redis 的可用性期望是至少 50kqps 起步,加入硬盘响应后就硬盘寻道那速度完全不影响?再说我本来我问的就是数据量超出内存之后的环境,默认肯定在于更新和读取,你扯着个写入不知所云了半天也不知道你在说啥。你的 redis 业务需求就一个写入?就一个 nosql 干起了 tsdb 的活计?
test3207
2020-12-20 07:28:32 +08:00
auto-aof-rewrite-percentage 应该要大于 100,不然不会触发重建。先手动连入 client 跑一次 bgaofrewrite,再重新配置这个 percentage 。另外 auto-aof-rewrite-min-size 也不建议配置得这么低,频繁触发重建本身会浪费服务器性能,手动 rewrite 之后记一下重建文件的大小,这边配置有一些余量即可。
ADANMEI
2020-12-21 09:26:30 +08:00
这是 AOF info Persistence

```

aof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:44
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_current_size:91520045163
aof_base_size:5035173402
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:185160

```
xiaoba123
2021-02-08 08:06:01 +08:00
@arloor 新版本才有这个,3.2 版应该没有

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/736912

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX