StackExchange Redis serving stale data when the old master is UP

[Vijay Akkaladevi]

I have Redis cluster (1 master and 2 slave) and 3 sentinels running for each server . 

Server 1 (master)

Server 2 (slave)

Server 3 (slave)

In the initial configuration it's working fine. I have made a server 1 down , Server 3 is voted as master

Server 1(down)

Server 2(slave)

Server 3(master).

Now i made Server 1 Up.

At this point it's serving the stale data where it left from the server 1.

Any Ideas want i can do? TIA

[Marc Gravell]

what servers does SE.Redis know about? basically: what have you configured, and how did you do the switchover?

SE.Redis has support for "cluster", but does *not* currently have tight sentinel integration. If sentinel announced a change: SE.Redis wouldn't have been listening.

As for why SE.Redis doesn't support this: simply, time and familiarity. Better sentinel support has always been on my radar, but has never made it high on the list - which is simply to say: other things have made it higher, and I only have so many hours to give.

Marc

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

[Vijay Akkaladevi]

SE.Redis is configured to 3 redis-servers. As i said i am running 3 sentinels on each of these servers. Switch overs is automatically happening. But when the old master is Up. 

Request is serving by the old master which is up. It have the stale data. As it is not synched the data.

On Thursday, 4 May 2017 12:52:39 UTC+5:30, Marc Gravell wrote:

what servers does SE.Redis know about? basically: what have you configured, and how did you do the switchover?

SE.Redis has support for "cluster", but does *not* currently have tight sentinel integration. If sentinel announced a change: SE.Redis wouldn't have been listening.

As for why SE.Redis doesn't support this: simply, time and familiarity. Better sentinel support has always been on my radar, but has never made it high on the list - which is simply to say: other things have made it higher, and I only have so many hours to give.

Marc

On 4 May 2017 8:08 a.m., "Vijay Akkaladevi" <vija...@gmail.com> wrote:

I have Redis cluster (1 master and 2 slave) and 3 sentinels running for each server . 

Server 1 (master)

Server 2 (slave)

Server 3 (slave)

In the initial configuration it's working fine. I have made a server 1 down , Server 3 is voted as master

Server 1(down)

Server 2(slave)

Server 3(master).

Now i made Server 1 Up.

At this point it's serving the stale data where it left from the server 1.

Any Ideas want i can do? TIA

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.

[Marc Gravell]

and again: how did you do the switchover? via the sentinel? if so, SE.Redis wasn't listening to 

them. That code doesn't exist right now; it could be added, but it needs time to do.

To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.

[Vijay Akkaladevi]

Yes switch over is happening via sentinel. When my master is down i am able to write to data to one of the slave(that has become new master after the voting master). So i  assuming that SE.Redis is able to identify the new master. 

Problem comes when my old master is up. I am getting the stale data. 

[Salvatore Sanfilippo]

Hi Marc, no need to listen for sentinel events, it is enough that at every disconnection from the server you ask sentinel again about the current master.

[Vijay Akkaladevi]

How i can ask sentinel about the current master.?

On Thursday, 4 May 2017 17:47:33 UTC+5:30, Salvatore Sanfilippo wrote:

Hi Marc, no need to listen for sentinel events, it is enough that at every disconnection from the server you ask sentinel again about the current master.

On May 4, 2017 9:22 AM, "Marc Gravell" <marc.g...@gmail.com> wrote:

what servers does SE.Redis know about? basically: what have you configured, and how did you do the switchover?

SE.Redis has support for "cluster", but does *not* currently have tight sentinel integration. If sentinel announced a change: SE.Redis wouldn't have been listening.

As for why SE.Redis doesn't support this: simply, time and familiarity. Better sentinel support has always been on my radar, but has never made it high on the list - which is simply to say: other things have made it higher, and I only have so many hours to give.

Marc

On 4 May 2017 8:08 a.m., "Vijay Akkaladevi" <vija...@gmail.com> wrote:

I have Redis cluster (1 master and 2 slave) and 3 sentinels running for each server . 

Server 1 (master)

Server 2 (slave)

Server 3 (slave)

In the initial configuration it's working fine. I have made a server 1 down , Server 3 is voted as master

Server 1(down)

Server 2(slave)

Server 3(master).

Now i made Server 1 Up.

At this point it's serving the stale data where it left from the server 1.

Any Ideas want i can do? TIA

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.

To post to this group, send email to redi...@googlegroups.com.
Visit this group at https://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.

To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.

[hva...@gmail.com]

See this Reddit post for an overview of the client<-->sentinel interactions and a link to a tutorial with examples of clients asking sentinel for status.