Your best bet would be to actually test on-disk usage of Redis in as
close to the same scenario as possible.

Note that when the AOF is rewritten, Redis will fork the same way that
it forks during a BGSAVE in order to rewrite the AOF. This will create
a second copy of the AOF, which will grow to contain all of your Redis
data, then it will get more recent commands. How often this will occur
will depend on both 'auto-aof-rewrite-percentage' and
'auto-aof-rewrite-min-size', whose meaning can be found in the
configuration file.

If it just so happens that the rewriting repeatedly fails (permissions
and/or disk space is the typical cause), your AOF will actually
continuously grow until you run out of space, which can cause some
very unpleasant results.

So to really answer your question: test it with real data, then
multiply it by 10x. This is a classic time-money tradeoff. By spending
more money on disk space, you can save yourself a lot of time later.

Regards,
 - Josiah

I am wondering what are the advantage in
using  'auto-aof-rewrite-percentage' and 'auto-aof-rewrite-min-size' except
more confusion..

Redis won't automatically rewrite the AOF if it is below
auto-aof-rewrite-min-size, obviously. And Redis won't automatically
rewrite the AOF if since the last rewrite, the file size has not grown
auto-aof-rewrite-percentage larger than before.

So to get the AOF to be automatically rewritten, assuming that
auto-aof-rewrite-min-size is 64M, the last rewrite produced a file of
size X megabytes, and you leave auto-aof-rewrite-percentage at 100,
then you will get a rewrite of the AOF when it reaches max(64, 2*X)
megabytes in size. When it gets that large, it will create a new file
of approximately X megabytes again, plus whatever writes you've
received while the rewrite was happening. So you will likely have a
bit more than 3X on disk before the original 2X AOF is deleted,
dropping you back to ~X before it starts growing again.

Note that the X is relatively unrelated to your in-memory size.
Depending on your data structures, I usually expect that a dump or AOF
will be approximately 1/20 to 1/5 the in-memory size. So if you are
limiting it to 4 gigabytes, your 'X' will likely be around 200M-800M
if your data is anything like mine.

The reason I recommended that you test is because *your data* and
*your access patterns* will determine the actual X related to your 4G.
If you do your calculations right, your on-disk required space may be
substantially less than the 4G that you set aside for it in your first
email.

Considering the design, I am wondering why use a percentage instead of a
fixed size?

I know you need some flexibility for redis special use case, but you can
use

e.g.

auto-aof-rewrite-min-size = 64M
auto-aof-rewrite-max-size = 128M (no AOF can grown large than this)

So when people plan their disk space, they can use the baseline 128M
multiple by some factors to safety plan the free space.

Not challenge you but just want to learn the design behind.

Instead, Redis just says "if the AOF is at least X megabytes, and the
AOF is at least Y% larger than the AOF at the end of the last rewrite,
then do a rewrite now". That means that you choose how much space to
"waste", relative to the amount of data that you *need* to store. That
is also why Y is typically 100 (you waste at most half of the space).

So now you mean the AOF contains all the shortest steps that is required to
build an empty DB to the latest DB? Even when I deleted the rdb file and I
can rebuild the db using just the AOF?

Unless you are looking for an easy to backup point-in-time dump, if
you have AOF enabled, there really is no need for the rdb (though they
are still created if you have slaves, because they are used for slave
sync).