StackExchange / StackExchange/StackExchange.Redis

Writing/reading to master/replica in AWS Cluster disabled redis.

Open
#2,261 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

☁️ platform:AWS
Dominant language
C#
Stars
6.2k
Forks
1.6k
Avg merge
1d 15h
Merged PRs (30d)
43

Description

I'm trying to find a way to use the replicas for reading and master for writing operations with the library. Apparently the code for doing that is this one:

    await connectionMultiplexer.GetDatabase()
        .StringSetAsync("hola", "mundo", CommandFlags.DemandMaster);

    await connectionMultiplexer.GetDatabase()
        .StringGetAsync("hola", flags: CommandFlags.PreferReplica);

which works on my local machine using a simple setup of redis like this (docker-compose):

services:
  redis-master:
    image: redis
    container_name: redis-master
    ports:
      - "6379:6379"

  redis-slave:
    image: redis
    container_name: redis-replica
    ports:
      - "6380:6379"
    command: redis-server --replicaof redis-master 6379
    depends_on:
      - redis-master

However, this code fails to do the same on my servers, as all operations go to the master node. Here's an output of IConnectionMultiplexer.GetStatus()

21:29:07.4035: master.elasticache1d4.xx.usw2.cache.amazonaws.com:6379: Standalone v2.0.0, master; keep-alive: 00:01:00; int: ConnectedEstablished; sub: ConnectedEstablished, 0 active
21:29:07.4063: master.elasticache1d4.xx.usw2.cache.amazonaws.com:6379: int ops=11, qu=0, qs=0, qc=0, wr=0, socks=1, non-pref=1; sub ops=4, qu=0, qs=0, qc=0, wr=0, socks=1
21:29:07.4252: master.elasticache1d4.xx.usw2.cache.amazonaws.com:6379: Circular op-count snapshot; int: 0+11=11 (1,10 ops/s; spans 10s); sub: 0+4=4 (0,40 ops/s; spans 10s)
21:29:07.4252: replica.elasticache1d4.xx.usw2.cache.amazonaws.com:6379: Standalone v2.0.0, master; keep-alive: 00:01:00; int: ConnectedEstablished; sub: ConnectedEstablished, 0 active; not in use: RedundantMaster
21:29:07.4252: replica.elasticache1d4.xx.usw2.cache.amazonaws.com:6379: int ops=10, qu=0, qs=0, qc=0, wr=0, socks=1; sub ops=4, qu=0, qs=0, qc=0, wr=0, socks=1
21:29:07.4252: replica.elasticache1d4.xx.usw2.cache.amazonaws.com:6379: Circular op-count snapshot; int: 0+10=10 (1,00 ops/s; spans 10s); sub: 0+4=4 (0,40 ops/s; spans 10s)
21:29:07.4255: Sync timeouts: 0; async timeouts: 0; fire and forget: 0; last heartbeat: 2s ago

Looks like the replica is recognized as a master.

Trying to find a solution I reached this doc:

Cluster mode disabled clusters don’t support the cluster discovery commands and aren’t compatible with all clients dynamic topology discovery functionality.

So apparently I'm needing to create two connections? one for the master and another for the replicas?

The aws doc also says that it's possible to create a manual topology configuration using lettuce (a java library):

Cluster mode disabled with ElastiCache isn’t compatible with Lettuce’s MasterSlaveTopologyRefresh. Instead, for cluster mode disabled you can configure a StaticMasterReplicaTopologyProvider and provide the cluster read and write endpoints.

Is it possible to do with this library?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the CommandFlags example and the IConnectionMultiplexer.GetStatus() output in the issue, then compare them with the linked AWS guidance for ElastiCache cluster mode disabled. Determine whether the library supports manual master/replica topology for this setup and document or verify the required configuration; done means read operations reliably reach replicas while writes reach the master.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, csharp, redis
Domain
cloud, database
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.