Rump: Hot-sync two Redis databases using dumps

So this gets a list of keys from the server A via the SCAN command, gets their value via DUMP, and sequentially runs RESTORE on server B to load the value?

If so then there's zero transactional consistency between the keys themselves. If each key is independent then that's not really an issue, but if you have multiple keys that make sense only in context of each other, it'd be possible to get values for each that corresponding to different moments in time (each reflecting when the DUMP command was invoked for that particular key).

I get that this is meant to work around limitations in AWS's Redis offering (namely the lack of BGSAVE, direct access to RDB, or SLAVEOF) but I'd suggesting highlighting that inconsistency at the top of the docs.

This is one of those cases where I wonder what the benefits are of Amazon vs running your own instance and just using the commands the way they were intended (by Redis in this case). The Amazon version of Elasticsearch has similar disadvantages with some blocked commands (understandably for security reasons).

Elasticache disabling SLAVEOF is the main reason why I don't use it in production.