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?
Comment From: mezzatto
I did this with vfork() + execv(). Check it out:
https://gist.github.com/3827099
(in portuguese)
Comment From: toutouastro
+1
Comment From: syst3mw0rm
+1
Comment From: codedstructure
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.
Comment From: mattsta
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
Comment From: clan
+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.
Comment From: rodrigobahiense
+1