Sentinel work fail after rename config command of redis - redis

I've installed stablest redis(ver 3.2). Everything work fine until I renamed CONFIG command of redis, sentinel could not promote slave to be master.
Think the problem is sentinel still use CONFIG command (has been renamed) to change configuration of redis.
Is there any way to change configuration of sentinel (via redis-cli or configuration files sentinel.conf) to adapt redis configuration (renamed config command). If there isn't, how about changing source code?
Thanks

After google, I found solution for this problem.
I replace redis/src/sentinel.c via this redis github, rebuild and install redis from source.
Then I could add a directive to sentinel.conf to configure sentinel use renamed config command.
sentinel config-command mymaster <renamed-command>

Related

Redis Sentinel Rename-Command Ignored

I am trying to limit the allowed privileges for external redis sentinel users by renaming critical commands as follow:
sentinel rename-command mymaster FAILOVER failover-secret
However, the configurations are being ignored, and I still can trigger the renamed command using the original name:
127.0.0.1:26379> sentinel failover mymaster
OK
Redis Version:
Redis server v=6.0.9 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=e874f7259751a389
The best option would be to put this in your Redis server's config file as opposed to setting it via CLI. It sounds like setting it this way either only applies to that connection (so other connections won't have that config change) or it only persists until the server restarts. Putting it in the config file would persist for all connections, and across restarts.
Another option if you're using Redis v6 (or can upgrade to v6) is to create separate users and specify the available commands per user. This option is discussed in this answer.

Sentinel configuration file

When adding a master to Sentinel, I always add the entries by editing sentinel.conf, but I often find out that application is being rewritten by another user (Sentinel).
I'm wondering if there is a more appropriate and an efficient way to add hosts to Sentinel without the need to edit the config file manually.
You can configure sentinel to monitor a new master at runtime.
Example:
SENTINEL MONITOR {cluster_name} {master_ip} {master_port} {quorum}
SENTINEL SET {cluster_name} auth-pass {password}
SENTINEL FLUSHCONFIG # Force Sentinel to rewrite its configuration file
For additional information check out the Redis Sentinel docs:
https://redis.io/topics/sentinel#reconfiguring-sentinel-at-runtime
Hope that helps!

Redis.conf for slave with sentinel

Should I use exact mirror of redis.conf on slave, if it would be promoted as master when failover activates.
For example should I appendonly yes to slave ?
The slaves configuration are different than the master one, so you will need to have 1 config file per server, plus one sentinel config file. Here you have a nice tutorial to make it work (basically) https://seanmcgary.com/posts/how-to-build-a-fault-tolerant-redis-cluster-with-sentinel

Redis-Sentinel with Redis whose CONFIG command is renamed

The CONFIG command is renamed to CONFIG_2267bccb973c432d96a26e96ca50860a
As I know, Redis-sentinel relies on this command, yes? How can configure redis-sentinel to use the renamed command?
You can't. Redis sentinel doesn't support renamed config commands. By the way this is an admin question so it belongs on serverfault.

How to keep redis server running

I am using redis for session support in nodejs app. I have installed redis server and it works when I run redis-server, but when I close terminal redis stops and does not work. How do I keep redis server running after closing the terminal?
And, if you'd like a quick option, run: redis-server --daemonize yes.
The easiest way to launch Redis as a daemon is to edit the configuration file and change the following line:
# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
daemonize yes
Be sure to provide the configuration file on the redis-server command line when you launch it.
An example of configuration file is provided in the Redis distribution.
As mentioned by #DidierSpezia in his answer,
Set daemonize yes in Redis conf file.
Set daemonize yes in Redis conf file at /path/to/redis.conf Generally
it should be there at /etc/.
And :
Then trigger redis-server with the conf file as an argument:
./redis-server /etc/redis.conf
UPDATE
You may directly run the redis with demonize flag as well
redis-server --daemonize yes
The accepted answer is mostly outdated.
While the question is old, Google still ranks this highly, so allow me to correct this.
The OP did not provide any detail about his setup, but you can assume it is a linux, and he doesn't mention containers, so you can also assume he is running redis without them.
There is three detail that make the accepted answer a thing to forget
Most (popular) distros come with systemd by default
Most (popular) distros have redis in their official repos
that official redis package installs systemd service for redis
So
It will have supervised systemd in its default config
To start: the redis daemon with sudo systemctl start redis#instanceName where you substitue "instanceName". Also sudo systemctl enable redis#instanceName for auto-starting on boot. (BTW, forget about service start, and init scripts already! These are less portable nowdays than calling directly systemctl).
do NOT set to daemonize: yes, that will interfere with the systemd supervisioning redis!
Systemd will supervise, restart your redis, and you can set service depenedencies and service preconditions to/for it, even for a custom executable it is not that hard, search for systemd unit files (you'll need a ~10 lines config file). Chances are, you'd want it.
If the three detail (making systemd the correct answer) are not met/relevant, you are most likely running redis containerized. For docker/podman/etc., it is another question altogether... (no systemd in the inner linux, but you'd have to (or already do) supervise(d) the container-daemon itself)