Does Discourse really need to flush Redis on boot?


(David Celis) #1

Maybe you’ll think I’m a weird case here, but I don’t… I was really surprised when, after booting Discourse up for the first time on my machine, it obliterated my Redis database. Discourse isn’t the only app I’ve got on my machine that uses Redis; I use it on other personal projects, including projects that I keep development data around for. Thankfully I had a very recent backup, but it made me annoyingly wonder why the attitude seems to be that Discourse owns the Redis instance and that it’s okay to wipe it out on every boot of the Rails environment.

Maybe your answer to this question will be, “Why didn’t you boot up the Vagrant VM?” Sure, I could have done that, but I already have all of the necessary software installed locally. It’s easier for me to just type bundle install and rails server and be done with it.

Is it really a problem to have existing data in my Redis database before running Discourse? Does discourse not namespace its Redis data at all? Can we change the “DO_NOT_FLUSH_REDIS” environment variable to something more along the lines of “FLUSH_REDIS”?

I think this could be way friendlier for devs that want to start hacking on Discourse.


(Sam Saffron) #2

I agree, this is uncalled for. I am pushing a change to avoid this, if people want to flush redis they can do it manually. It bites me often even when I am developing. @eviltrout added it for a reason, but I think we might as well correct the underlying problem as opposed to constantly nuking redis in dev.


(Robbie Straw) #3

You can namespace it by altering the redis.yml config: https://github.com/discourse/discourse/blob/master/config/redis.yml.sample

The lines that say db: _ refer to numbered redis databases; changing those should wall discourse off into a different namespace.

I’m not sure if Discourse flushes the whole instance though, or just the numbered database it’s using.


(Sam Saffron) #4

Done,

We are namespaced btw, see:


(David Celis) #5

@drbawb That’s what I figured, which made the flushing all the more confusing.

@sam Thanks, I really appreciate that. I would have opened a PR but I wanted to see if there was backstory behind the setting before I did that. Thank you!


(Robin Ward) #6

I am pretty sure that reason was you asked for it :stuck_out_tongue: We were caching site stuff and you had a bug where you weren’t getting the latest cached stuff, so I added it when not in production mode.


(Sam Saffron) #7

fair enough, if this starts playing up again we are going to have to figure out how to expire slightly less information.


(Lee_Ars) #8

Not to re-open old wounds, but I just saw this thread and it explains quite handily why when I checked out my locally-hosted Etherpad instance a few days ago for the first time in a few months, every single one of my pads was gone :frowning: Etherpad was using Redis for its database, and even through I’d assigned Discourse a different number database (4 for prod, where Etherpad was using 0), one of the flushes Discourse did when I was first getting everything set up looks to have nuked it.

Not really a super-big deal–nothing lost that I don’t have backups of somewhere, but it meant I had to dig a lot harder to find some stuff I needed for a piece I’m writing.