Always create base AOF file when redis start from empty.#10102
Always create base AOF file when redis start from empty.#10102oranagra merged 14 commits intoredis:unstablefrom chenyang8094:feature-additional-for-multi-part-aof
Conversation
|
Add some of my comments at the top: I'm not sure if disabling This will also affects the way some tests , For example if you want to test whether aofrewrite of a data type is correct, Before this you can do: Regardless of whether redis-server is started with But now you should force set So I changed a lot of existing tests that depended on this way. Ironically, if I execute |
oranagra
left a comment
There was a problem hiding this comment.
haven't reviewed the tests yet.
oranagra
left a comment
There was a problem hiding this comment.
i agree it's a good idea to remove the change about blocking BGREWRITEAOF from this PR.
please mark all the comments that where related to the reverted changes as resolved, and please post your comments about the use case or existing users for that in #9794
or if we go back to the previous version, it could be two groups of nested if-else.
i.e. the problem with the first version was just the wrong placement of the `}`, but the later version with indentation and without `{}` was confusing.
soloestoy
left a comment
There was a problem hiding this comment.
I'm happy that we keep BGREWRITEAOF, avoid a breaking change, it's useful in many scenarios.
|
@soloestoy we removed it from this PR to be discussed separately, but i'm not sure we reached a decision yet. |
|
Hi @oranagra @soloestoy IIRC, some users actually use this feature 😂, AOF is easy to inject to another redis server when running, such as by |
|
@ShooterIT thank. can you move that message to #9794 (we took that content out of this PR) |
See issue #9794
Force create a BASE file (use a foreground
rewriteAppendOnlyFile) when redis starts from an empty data set andappendonlyis yes.The reasoning is that normally, after redis is running for some time, and the AOF has gone though a few rewrites, there's always a base rdb file. and the scenario where the base file is missing, is kinda rare (happens only at empty startup), so this change normalizes it.
But more importantly, there are or could be some complex modules that are started with some configuration, when they create persistence they write that configuration to RDB AUX fields, so that can can always know with which configuration the persistence file they're loading was created (could be critical). there is (was) one scenario in which they could load their persisted data, and that configuration was missing, and this change fixes it.
Add a new module event: REDISMODULE_SUBEVENT_PERSISTENCE_SYNC_AOF_START, similar to
REDISMODULE_SUBEVENT_PERSISTENCE_AOF_START which is async.
Note: This PR initially also disabled BGREWRITEAOF when appendonly config is no, but that part was later removed to be discussed separately.