Add ability to identify a Redis instance by a name #694

Open
djanowski opened this Issue Oct 3, 2012 · 7 comments

Comments

Projects
None yet
8 participants
Contributor

djanowski commented Oct 3, 2012

I believe it's common to have different Redis instances for different aspects of your applications, especially when those aspects need different persistence strategies (the typical case of handling payment information vs. user comments).

It's also somewhat less common to have different Redis instances hanging around for different applications (for instance, I do share some dedicated hardware between different projects which use a separate Redis instance). I agree this must be a less common scenario.

The problem I've found is that some times it becomes hard to maintain these instances. Currently, if I use something like ps(1) or htop(1) it's either hard/tricky/impossible to tell which Redis process belongs to what instance (some times you can tell because of the config path you give to redis-server, but some times this is implicit because of $PWD).

My proposal is to add an id configuration directive, one which can identify instances by their concern (or whatever criteria you choose). This ID could be used in two ways:

  1. Change argv[0] to have ps(1) reflect the instance identification.

  2. Have redis-cli query this ID and include it in the prompt. For example:

    redis 127.0.0.1:6379 (payments)>
    

What do you think?

mezzatto commented Oct 3, 2012

I did this with vfork() + execv(). Check it out:

https://gist.github.com/3827099

(in portuguese)

The recent(?) change to include TCP listening address & port number rather than the config file makes this slightly worse in the case of Unix socket (only) based instances (i.e. port=0 in the config file), where it is possible to have the following for multiple independent redis-server instances:

$ ps ax | grep redis
12233 ?        Ssl    0:00 redis-server *:0                                                    
12270 ?        Ssl    0:00 redis-server *:0                                                    
12274 ?        Ssl    0:00 redis-server *:0                                                    
12321 ?        Ssl    0:00 redis-server *:0
$

Though I acknowledge the config file thing wasn't necessarily any better; they could all have been started on the command line without an explicit config file.

Contributor

mattsta commented Apr 24, 2014

An ideal Redis process name could update with the role of the server and have a format like: [executable name] [custom server name] [role (standalone|master [replica count]|replica (of master)|cluster-master [slots]|cluster-replica [for slots; replica of [master]])] bindaddr[0]

So, something like:

  • redis-server comment-engine standalone [::1]:9921
  • redis-server sessions cluster-master (slots 1-300) 10.5.9.21:4471
  • redis-server api-throttle master (3 live replicas) 66.21.31.40:8831
  • redis-server fast-audit replica (master 172.16.5.20:9931) 127.16.5.21:9931
  • redis-server recent-comments cluster-replica (slots 2096-3020,4060-8901; master 10.46.120.7:5791) 10.46.120.9:5791

mattsta referenced this issue Apr 25, 2014

Set process name in ps output to make operations safer.
This commit allows Redis to set a process name that includes the binding
address and the port number in order to make operations simpler.

Redis children processes doing AOF rewrites or RDB saving change the
name into redis-aof-rewrite and redis-rdb-bgsave respectively.

This in general makes harder to kill the wrong process because of an
error and makes simpler to identify saving children.

This feature was suggested by Arnaud GRANAL in the Redis Google Group,
Arnaud also pointed me to the setproctitle.c implementation includeed in
this commit.

This feature should work on all the Linux, OSX, and all the three major
BSD systems.

clan commented Apr 26, 2014

+1

I also prefer an option for the old behavior (i.e., do not change the proc title at all) because it's more predictable. Especially when we use salt for service state management, as I've commented
here, thanks.

zugl commented Jul 12, 2014

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment