Should Redis be configed as a cache server or not?

installation
1

The official GitHub page for Discourse says

“We use Redis as a cache and for transient data.”.

But Sidekiq, which is a part of Discourse, says

“Many people use Redis as a cache but it’s important that Sidekiq be run against a Redis instance that is not configured as a cache but as a persistent store.”

and it also suggests

“using two separate Redis instances, each configured appropriately, if you wish to use Redis for caching and Sidekiq”

So what should I do? I currently have only one Redis configed as a LRU cache. Should I make another one for Sidekiq, and how? Or I can safely ignore Sidekiq’s suggestion?

Thanks.

2

Are you trying to install Discourse for production use? If so, simply follow these instructions:

3

In general we try to avoid Redis flushes, but it’s not completely the end of the world if it does get flushed. Worst case, some emails might not get sent such as password resets and users will need to re-request.

4 Likes
4

I’m not using Docker. I deployed it through Capistrano. It’s production.

5

Just for info, on the forums:

The only officially supported installs of Discourse are the Docker based beginner and advanced installs. We regret that we cannot support any other methods of installation.

https://github.com/discourse/discourse/blob/master/docs/INSTALL.md

1 Like
7

Yes, I know that. But for Chinese users, Docker is not a good choice: it’s intended for convenience but due to the network block(GFW) from within China, bundler install fails frequently for network error. So Chinese Docker user has to manually edit the Docker templates and configs and so on to fix that. It’s not easy, not to say that the Docker image download is VERY SLOW in China, and I’m afraid someday it may be totally unavailable. So a workaround for me is to use bundler package to avoid network download for installing Ruby Gems, which I’ve prepared in some special way before. In short, I need a way with highly custom installation script and Capistrano fits me. Rather complex, right?

1 Like
8

I am pretty sure @fantasticfears had a workaround for this.

9
3 Likes
12

Thanks. However I tried Taobao mirror before, that doesn’t always work: Gems of required(new) version had been missing for 1+ months because the mirror server stopped syncing with official source for unknown reason. Here is an example: https://github.com/alibaba/ruby.taobao.org/issues/50
Taobao mirror is not always reliable.

13

Thanks but @fantasticfears’s solution depends on Taobao mirror, which is not always reliable. Please see my previous reply for details.

14

It’s been moved to RubyChina mirror. I documented them here and there in Chinese.

You have more than one way to fix this, either by mirrors or by proxy. If you have a reliable proxy, you don’t even bother whether a mirror is perfectly stable to you. Besides, RubyChina mirror is rather stable comparing to the launch. https://github.com/ruby-china/rubygems-mirror/issues?q=is%3Aissue+is%3Aclosed

Docker can also employ a proxy as described in the documentation.

If you are using Capistrano, you have more choices since you are a senior developer.

5 Likes
15

Thanks! I’ll look into the Docker solution again when I have to turn to it. For now, my Capistrano deployment has been working well. Thanks for all your help!

1 Like