这是一个创建于 1470 天前的主题，其中的信息可能已经有所发展或是发生改变。
服务器上的 AOF 文件 60G,我能通过bgrewriteaof这个命令压缩吗？压缩效果会怎么样？现在 redis 使用内存 7G 。
redis 版本 3.2
 |
1
ADANMEI OP 也开启过自动重写
``` appendfilename "appendonly.aof" auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb aof-load-truncated yes aof-rewrite-incremental-fsync yes ``` |
 |
2
nightspirit 2020-12-18 22:34:21 +08:00  1
AOF 重写：
(1) 随着 AOF 文件越来越大，里面会有大部分是重复命令或者可以合并的命令（ 100 次 incr = set key 100 ） (2) 重写的好处：减少 AOF 日志尺寸，减少内存占用，加快数据库恢复时间 |
 |
3
MurphyL0 2020-12-18 22:51:39 +08:00 via Android
auto-aof-rewrite-min-size 这个改大些
|
 |
4
black11black 2020-12-19 05:37:16 +08:00 via Android
问个题外话，lz 的 aof 在达到这个体量以后性能怎么样啊。看网上一些测试说超过一千万行以后性能缩到不如 mongodb
|
 |
5
aijam 2020-12-19 05:44:56 +08:00
@black11black 不知道你从哪里看来的。aof 和 redis 性能没啥关系吧？归根到底主存储还是全内存。
|
|
6
black11black 2020-12-19 05:52:22 +08:00 via Android
@aijam 表达失误，我的意思不是 aof 导致性能下降，而是想知道行数增加到一定程度后，redis 持久方案下对性能影响有多少
|
 |
7
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 |
 |
8
arloor 2020-12-19 09:23:21 +08:00
aof 重写可以在头部使用 rdb 来减少 aof 文件的大小
具体搜下这个配置：server.aof_use_rdb_preamble |
|
9
black11black 2020-12-19 09:29:59 +08:00 via Android
@lewis89 你没回错人？驴唇不对马嘴？
|
|
10
lewis89 2020-12-19 09:37:50 +08:00
@black11black #9 持久化是异步线程，为什么会对性能有影响？而且 AOF 官方说了 不会同步写入 log 停电会可能丢失 你真的了解 Redis ？ 别人云亦云。
|
|
11
lewis89 2020-12-19 09:39:09 +08:00
@black11black #9 就算是写 10 亿行，只要是磁盘顺序写，根本无压力好吗？而且又是异步线程写入。
|
 |
12
thet 2020-12-19 09:55:38 +08:00 via iPhone
aof 重写不是自动的吗
|
 |
13
cxshun 2020-12-19 10:14:32 +08:00
@ADANMEI #1 是不是尝试把 rewrite-percentage 调低点，这里 100 是指你的 aof 文件大小扩大一倍才触发 rewrite，假设你调到 5，以你现在的大小来看，那么你的 aof 文件增加 3g 就会触发重写。
PS：你的 redis 使用内存 7g，正常来说 aof 文件不会那么大的，感觉像是一直没有触发重写的样子。 |
 |
14
huntcool001 2020-12-19 17:49:41 +08:00
不应该怎么大的.
你连上命令行,输入: info Persistence , 回车 贴一下最后面 aof_开头的信息. |
|
15
huntcool001 2020-12-19 17:54:20 +08:00
我看其他人也报告过这个问题.可能是老版本的 bug 吧. 业务量低的时候手动 bgrewriteaof 触发一下就好了.应该压缩到 10G 以下
|
 |
16
bootvue 2020-12-19 20:54:53 +08:00
redis cluster 集群 把数据分一分会不会好一点
|
|
17
black11black 2020-12-19 21:08:47 +08:00 via Android
@lewis89 你发的帖子里自己都解释了持久化策略有逐条同步，每秒同步等等。有 dump 事务，我提问一下对性能影响怎么了，正常问题，轮得到你来这里跳脚。还问我真的了解 redis，笑死个人，你是某斯林，不了解的人不让在论坛里说话？还是你比我多了解多少？
磁盘顺序写，基于异步写入响应，我们对单机 redis 的可用性期望是至少 50kqps 起步，加入硬盘响应后就硬盘寻道那速度完全不影响？再说我本来我问的就是数据量超出内存之后的环境，默认肯定在于更新和读取，你扯着个写入不知所云了半天也不知道你在说啥。你的 redis 业务需求就一个写入？就一个 nosql 干起了 tsdb 的活计？ |
 |
18
test3207 2020-12-20 07:28:32 +08:00 via Android
auto-aof-rewrite-percentage 应该要大于 100，不然不会触发重建。先手动连入 client 跑一次 bgaofrewrite，再重新配置这个 percentage 。另外 auto-aof-rewrite-min-size 也不建议配置得这么低，频繁触发重建本身会浪费服务器性能，手动 rewrite 之后记一下重建文件的大小，这边配置有一些余量即可。
|
|
19
ADANMEI OP 这是 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 ``` |
Select Language