Redis configuration rewriting (CONFIG REWRITE)

[Salvatore Sanfilippo]

Hello!

We have something new:

http://antirez.com/news/54

soon merged into 2.8 / unstable

Cheers,
Salvatore

--
Salvatore 'antirez' Sanfilippo
open source developer - VMware
http://invece.org

Beauty is more important in computing than anywhere else in technology
because software is so complicated. Beauty is the ultimate defence
against complexity.
— David Gelernter

[Jokea]

Hi,

Useful feature. Found a typo:

Line 1594: "eveysec", AOF_FSYNC_EVERYSEC,

should be "everysec".


Regards,
Jokea

[Salvatore Sanfilippo]

Hello Jokea,

thanks, the bug was already fixed in one of the recent commits, today
I tested everything in depth and found a number of bugs as you can see
from the git commits... :-)

Now I'm confident enough that everything is sane, so merging into 2.8
and unstable.

Cheers,
Salvatore

> --
> You received this message because you are subscribed to the Google Groups
> "Redis DB" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to redis-db+u...@googlegroups.com.
> To post to this group, send email to redi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/redis-db?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.

[Yiftach Shoolman]

Looks like a great/very useful feature, Salvatore.

[Salvatore Sanfilippo]

Thanks for the feedback Yiftach!

[CharSyam]

I introduced this feature to my friend. he said to me. "I implemented this feature using shell script. but I wanted this feature as an official way." and he will use this feature with happiness. :)  Thank you.

2013/5/16 Salvatore Sanfilippo <ant...@gmail.com>

[Salvatore Sanfilippo]

Great! Thanks

[Keith Ainsworth]

I was wondering about the behavior of the slaveof field on config rewrite. From reading the code:

If the server is a master (or redis cluster), the slaveof line will get blanked out

If the server is a slave, ensure the line reads "slaveof masterhost masterport"

My problem with the behavior, is that if I start the server as a slave, then promote it to master, then rewrite the config, I'll get my identical config file with the slaveof line blanked out. Then if I demote it to a slave again and rewrite, the config file will get a line appended to the end of the file to avoid modifying the file structure. From here, if we consider a live system where the role of a server might change dynamically and several times a day, we have a disk-space leak in the form of the config file! (the config constantly growing by a line each slave'ing, and blanking it each master'ing).

I realize this is a small problem in the grand scheme of things, but I'm working on a managed redis infrastructure, and the consistency of this feature is important to me.

I propose that:

• If the server is redis cluster; use original behavior (this problem shouldn't be relevant)
  
• If the server is a master; the line should be rewritten as 'slaveof no one' instead of blanked
• If the server is a slave; use original behavior

Additionally, the config parsing for 'slaveof no one' would need to be handled properly, so the master slaveof configuration doesn't become a slave config for an invalid host/port.

This may feel hacky at first, but the slaveof 'no one' is already used as the command, so it's not inherently new language to redis, it's just a new use case for this language. Additionally, this way, in a live environment where I dynamically flip the replication role, the config file would reliably flip between two known states, instead of slowly, surely filling the conf file with whitespace, which seems much more expected.

That said, I'd be happy with any fix, such that when the replication role is flipping, and the config is being rewritten with 'CONFIG REWRITE', that the config file flips between 2 states (assuming the masterhost/masterport is the same for slave configurations).

I can try out patching this if you like my approach, let me know-

Thanks!

[Keith Ainsworth]

Correction:

After running back and forth a couple times, I realize that it only appends 1 blank line at the end of the file, then it starts deleting the line altogether. This isn't a fix to the leak however, as if other vars change to/from default values they get lines blanked out, so if the order of changes is correct it's still possible to get growing config files (this is what I was noticing before). Therefore, I think the inplace 'rewrite' of the slaveof is better still. 

[Paul Court]

Will Sentinel be using this after a new master is elected?