Will it work with multiple instances of redis?

[vlasky]

Hello Ramez,

My client is running their Meteor app on multiple server communicating with a MongoDB replica set.

Will redis-oplog work if there is a separate instance of Redis on each server, or do all instances of Meteor need to communicate with the same instance of Redis?

[ramezrafla]

Hi Vlad,

It has to be a single instance of Redis so the messages are transmitted.
Truth is, a single instance can carry a lot of load. So you don't need to create a cluster of redis (unless you have a massive app)

[vlasky]

Hi Ramez, my client's cluster has been designed for high availability to allow their app to keep operating if up to two servers go down. With a single instance of Redis, that would be a single point of failure.

Given that it has to be a single instance, have you considered switching to ioredis in order to natively support Redis Sentinel?

[ramezrafla]

A cluster should work - I haven’t tried but seems obvious. When you said singe instance I thought they were independent. You would be the first I know when I try it out. I’ll check out ioredis

[vlasky]

Yes, I did mean independent instances. I considered Redis Sentinel to be the fallback option if your answer to my original question was "single instance required".

I see that there are forks of the original redis-oplog that have been switched to ioredis and mention the use of Sentinel.

[ramezrafla]

@vlasky
Can you guide me to a fork with Sentinel that you know works well?
I checked and ioredis seems to be the recommended Node package (must have changed since I last looked)

[vlasky]

Hi Ramez,

I have no experience with Redis Sentinel yet.

I'm doing my homework to ensure that everything meets my client's requirements before proceeding with deploying and testing it.

I often browse GitHub network to see what other people have been doing with their forks and that is how I knew others were using it with ioredis and Sentinel.

Examples:

https://github.com/sharekey/redis-oplog
cult-of-coders/redis-oplog#372