FLUSHALL and FLUSHDB commands on redis return "unk command"

Question

To flush redis, the FLUSHALL command is to be used.

Using Redis 2.6.16, when I tried both FLUSHALL and FLUSHDB commands while using redis-cli, I got an unknown command error. Other commands work fine.

a) What is going wrong with the FLUSH* commands?

b) Is a workaround to do a shutdown of Redis, then delete the rdb file? (I believe so)

UPDATE:

No, we never solved this.

(The only known solution is to use step 'b' above)

Maccarthy

Your assumption (b) is correct. Regarding (a); what's wrong with your commands: very strange, I haven't got a clue. Did you do a make and a make test? There must be st wrong with your build. – Mont

Yes, I did the whole make/make test on initial install a year ago. This is a production instance that works fine in all other ways. – Maccarthy

same problem here; did you solve? – Curlicue

Same problem, anybody have solution? – Holloweyed

Answer 1

It could be that your Redis configuration has renamed some commands to prevent your database from being accidentaly deleted.

Look for the following lines in your redis.conf:

rename-command FLUSHDB ""
rename-command FLUSHALL ""

Lethargic

Just a note: this is a server setting, not client ;) – Vashtivashtia

This is the default in the Bitnami Redis kubernetes helm chart, for anyone else using that and running into this surprise. Undo by modifying the master/slave.disableCommands value. – Tartlet

Answer 2

Redis official Helm chart by default disables FLUSHDB and FLUSHALL commands. In this case, it is not specified in any of the redis.conf inside the containers, so you need to specify it in your Redis YAML:

master:
  disableCommands: []

Water

Please note that it is specified in the values.yaml file - for both master and slaves – Tevere

In the end we did not enable the commands, instead we executed the following command in the shell of the Redis container provided by Bitnami: echo 'KEYS *' | redis-cli * | sed 's/^/DEL /' | redis-cli – Ostiole

I think there is a small typo, the * near the redis-cli is not needed. The command should be like that: echo 'KEYS *' | redis-cli | sed 's/^/DEL /' | redis-cli – Leicester

Answer 3

I was using Helm and didn't want to go through reinstalling it, so I worked around this issue by modifying the configmap that Helm generates to contain the config.

CONFIGMAP=<<value of common.names.fullname>>-configuration
kubectl edit cm $CONFIGMAP

You should see something like:

  master.conf: |-
    dir /data
    # User-supplied master configuration:
    rename-command FLUSHDB ""
    rename-command FLUSHALL ""
    # End of master configuration
  redis.conf: |-
    # User-supplied common configuration:
    # Enable AOF https://redis.io/topics/persistence#append-only-file
    appendonly yes
    # Disable RDB persistence, AOF persistence already enabled.
    save ""
    # End of common configuration
  replica.conf: |-
    dir /data
    slave-read-only yes
    # User-supplied replica configuration:
    rename-command FLUSHDB ""
    rename-command FLUSHALL ""
    # End of replica configuration

Remove lines beginning with rename-command so it looks more like this:

  master.conf: |-
    dir /data
    # User-supplied master configuration:
    # End of master configuration
  redis.conf: |-
    # User-supplied common configuration:
    # Enable AOF https://redis.io/topics/persistence#append-only-file
    appendonly yes
    # Disable RDB persistence, AOF persistence already enabled.
    save ""
    # End of common configuration
  replica.conf: |-
    dir /data
    slave-read-only yes
    # User-supplied replica configuration:
    # End of replica configuration

Restart the redis pods

kubectl delete pods $(kubectl get pods | grep redis | awk {'print $1'})

Now exec into the master pod and flush all

kubectl exec redis-master-0 -- redis-cli FLUSHALL
OK

Be aware that you will have to do this again if you reinstall your Helm release if you want to use FLUSHALL or FLUSHDB again.

Update: Although this works, when you go to reinstall your helm release the pods will go into crashloopbackoff because they will see in the history that the commands you ran don't exist, so you will have to go through this again to get the pods to run. Probably best to go with @camilo-sampedro's answer in this case.

Kittie