Redis 2.6.11 Info Keyspace Counts not Giving Exact Values #1233

amaron opened this Issue Aug 7, 2013 · 5 comments


None yet
5 participants

amaron commented Aug 7, 2013

I am not sure if this is an issue, but key count displayed under Keyspace Tab from Redis Info and counting number of keys returned by keys * are not returning the same number.

[user@Computer ~]$ redis-cli -p 7380 info| grep db0
[user@Computer ~]$ redis-cli -p 7380 keys * | wc -l
[user@Computer ~]$ redis-cli -p 7380 info| grep db0

Is this an issue?

jknair commented Aug 7, 2013

I saw these same issues on slaves when trying out replication across WAN.

I'm seeing this as well with 2.6.12.


mattsta commented Jul 30, 2014

Have any datasets or test cases showing the differences?

Running KEYS * will force-expire any old key it comes across, so if you have old keys waiting to be lazily expired, you'll see your count drop as compared to immediate info output.

Also, just a reminder, nobody should be using KEYS with large data sets. SCAN is much preferred because it doesn't do an uninterrupted linear scan across your entire keyspace like KEYS does.


/opt/redis/bin/redis-cli -a 'password' -n 1 keys | wc -l


INFO shows 360512 keys in the same DB.

Restarting Redis didn't fix it. Only way to clear it was to shutdown redis, delete the RDB file and let it resync from the master on restart.


mattsta commented Jul 30, 2014

We're stepping over some terms here.

Does "I'm seeing this as well" include replication not matching the master or only one-server KEYS * vs. INFO output mismatch?

Now, " Only way to clear it" — "it" = the mismatched count? Is the replica set to disable all writes?

Replicas and masters expire keys independently, so they will have different physical key counts. If you run KEYS * on both master and replica, they should return the same number if nobody is writing to either server between the two runs.

And... in your example, the redis-cli command can't actually work because KEYS requires an argument. Perhaps just tail the output to get the highest counted lines to see what's getting returned?

@badboy badboy closed this Jul 3, 2017

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