Redis databases on a dev machine with multiple pro

Question

How do you manage multiple projects on your development and/or testing machine, when some of those projects use Redis databases?

There are 2 major problems:

1. Redis doesn't have named databases (only numbers 0-16)
2. Tests are likely to execute FLUSHDB on each run

Right now, I think we have three options:

1. Assign different databases for each project, each dev and test environment
2. Prefix keys with a project name using something like redis-namespace
3. Nuke and seed the databases anytime you switch between projects

The first one is problematic if multiple projects assign "0" for the main use and "1" for the test and such. Even if Project B decided to change to "2" and "3", another member in the project might have a conflict in another projects for him. In other words, that approach is not SCM friendly.

For the second one, it's a bad idea simply because it adds needless overhead on runtime performance and memory efficiency. And no matter what you do, another project might be already using the same key coincidentally when you joined the project.

The third option is rather a product of compromise, but sometimes I want to keep my local data untouched while I deploy small patches for another projects.

I know this could be a feature request for Redis, but I need a solution now.

Any ideas, practices?

Answer 1

If the projects are independent and so do not need to share data, it is much better to use multiple redis instances - each project configuration has a port number rather than a database name/id. Create an appropriately named config file and startup script for each one so that you can get whichever instance you need running with a single click.

Make sure you update the save settings in each config file as well as setting the ports - Multiple instances using the same dump.rdb file will work, but lead to some rather confusing bugs.

I also use separate instances for development and testing so that the test instance never writes anything to disk and can be flushed at the start of each test.

Answer 2

Redis is moving away from multiple databases, so I would recommend you start migrating put of that mechanism sooner rather than later. This means one instance per db. Given the very low overhead of running Redis, this isn't a problem from a resources standpoint.

That said, you can specify the number of databases, and providing A naming standard would work. For example, configure redis to have say, 60 DBS and you add 10 for the test db. For example db3 uses db13 for testing.

It sounds like your dev, test, and prod environments are pretty tied together. If so, I'd suggest moving away from that. Using separate instances is the easiest route to that, and provides protection against cross purpose contamination. Between this and the future of redis being single-db per instance, separate instances is the best route.