Describe the bug
Keys created using DEBUG POPULATE are not propagated to replicas.
To reproduce
Set up a master and a replica. Call e.g. DEBUG POPULATE 10 on the master. Check the keys on the replica using DBSIZE, KEYS or SCAN 0.
Expected behavior
I expect the same content on the replica as on the master (given the replica isn't writable, slow, offline or defect).
Additional information
I guess that the reason is that server.dirty++ is not done in the implementation of DEBUG POPULATE.
Other fun facts
- The DEBUG command is not flagged as a write command (although DEBUG POPULATE is doing writes)
- DEBUG POPULATE doesn't care about cluster slots, so when called on a cluster node, keys not belonging to this node can be created.
- DEBUG POPULATE is documented in the output of DEBUG HELP, but not on redis.io
Comment From: oranagra
Fun fact number 4: * DEBUG POPULATE is not meant to be consistent with other parts of Redis (IMHO).
it's not a real command, just a testing hack.. Other sub-commands of DEBUG are also not consistent, like not supporting COMMAND GETKEYS and cluster MOVED response.
IMHO It is perfectly fine that it is documented in DEBUG HELP but not in Redis.io. other DEBUG subcommands should not be in Redis.io, and soon they'll be gone from there. I suppose it'll also be missing from COMMAND output too.
See #9687, #9656, #9684 All in some way partially related.
Comment From: zuiderkwast
OK, then at least some of these limitations could be mentioned in the DEBUG HELP output. It'd be helpful. (Today I tried to use debug populate in a test case involving replication...)
Comment From: oranagra
Meh.. You won't make that mistake again... 8-) Feel free to add warnings.. In theory we can also fix things, but I think that incrementing the dirty counter and propagating it would be a mistake, and may also cause some tests to break.