# redis.conf
repl-backlog-size 1mb      # Default: 1MB — dangerously small for most production workloads
repl-backlog-ttl  3600     # How long to keep the backlog after last replica disconnects

# Check current backlog configuration and usage
redis-cli INFO replication | grep -E "repl_backlog|master_repl"
# master_repl_offset:    18446744073    ← bytes primary has sent since start
# repl_backlog_active:   1
# repl_backlog_size:     1048576        ← 1MB (default — too small)
# repl_backlog_first_byte_offset: 18445695497
# repl_backlog_histlen:  1048576        ← backlog is full (at capacity)

# WAIT numreplicas timeout_ms
# Blocks until numreplicas replicas have acknowledged the current replication offset,
# or until timeout_ms milliseconds elapse — whichever comes first.

# After a critical write:
redis-cli SET payment:idempotency:abc "processed"
# → OK

redis-cli WAIT 1 100
# → 1  (1 replica acknowledged within 100ms)
# If 0 returned: no replica acknowledged within 100ms — treat write as unconfirmed

// ✅ Production pattern: WAIT after durability-critical writes
async function processPaymentIdempotent(idempotencyKey: string, result: string) {
  await redis.set(`payment:idempotency:${idempotencyKey}`, result, 'EX', 86400)

  // Require at least 1 replica to acknowledge before returning
  const ackedReplicas = await redis.wait(1, 100) // 1 replica, 100ms timeout

  if (ackedReplicas < 1) {
    // Replica did not acknowledge — the write may be lost on primary failure.
    // Options: retry, alert, or accept the risk based on business requirements.
    throw new Error(`Replication acknowledgment timeout for key ${idempotencyKey}`)
  }
}

# redis.conf (replica)
replica-serve-stale-data yes   # Default

# ❌ Scenario with replica-serve-stale-data yes:
# Primary: SET account:42:balance 1000
# Network partition: replica loses primary for 30 seconds
# Application reads from replica: GET account:42:balance → "1000"
# Primary (still alive on other side of partition): balance updated to 900 after debit
# Replica returns stale "1000" for 30 seconds — application makes decisions on wrong balance

# Check replication lag before trusting replica reads
redis-cli -p 6380 INFO replication | grep master_last_io_seconds_ago
# → master_last_io_seconds_ago: 31   ← 31 seconds since last contact with primary

# ✅ For application data (not cache): reject stale reads on disconnected replicas
replica-serve-stale-data no
# Replicas return SYNC error for all read commands when disconnected from primary
# Client receives: LOADING Redis is loading the dataset in memory
# Better than silently serving stale data

# Full replication status
redis-cli INFO replication
# role: master
# connected_slaves: 2
# slave0: ip=10.0.0.2,port=6380,state=online,offset=18446744000,lag=0
# slave1: ip=10.0.0.3,port=6380,state=online,offset=18446743950,lag=1
# master_repl_offset: 18446744073
# repl_backlog_size: 104857600

# lag=0: replica is within 1 replication cycle (typically <10ms) of primary
# lag=1: replica is 1 replication cycle behind — acceptable under load
# lag>5: significant lag — investigate disk I/O, network bandwidth, or slow replica

# Byte-level replication lag
master_offset=$(redis-cli INFO replication | grep master_repl_offset | cut -d: -f2 | tr -d '\r ')
slave_offset=$(redis-cli -p 6380 INFO replication | grep master_repl_offset | cut -d: -f2 | tr -d '\r ')
echo "Lag bytes: $((master_offset - slave_offset))"

# sentinel.conf
sentinel monitor mymaster 10.0.0.1 6379 2
# Monitor "mymaster" at 10.0.0.1:6379
# Quorum: 2 — requires 2 Sentinels to agree on ODOWN before failover

sentinel down-after-milliseconds mymaster 5000
# Mark primary as SDOWN if no response for 5000ms

sentinel failover-timeout mymaster 60000
# Failover must complete within 60 seconds or it is aborted

sentinel parallel-syncs mymaster 1
# Number of replicas that can sync simultaneously after failover
# 1 = replicas sync one at a time (conservative — avoids overwhelming new primary)

import Redis from 'ioredis'

// ❌ Broken: hardcoded primary address — fails permanently after failover
const redis = new Redis({ host: '10.0.0.1', port: 6379 })

// ✅ Correct: sentinel-aware client — automatically follows failover
const redis = new Redis({
  sentinels: [
    { host: '10.0.0.10', port: 26379 },
    { host: '10.0.0.11', port: 26379 },
    { host: '10.0.0.12', port: 26379 },
  ],
  name: 'mymaster',            // Matches sentinel.conf "sentinel monitor mymaster ..."
  sentinelRetryStrategy: (times) => Math.min(times * 100, 3000),
  connectTimeout: 10000,
})

// ioredis automatically:
// 1. Connects to any available Sentinel
// 2. Asks for current primary address (SENTINEL get-master-addr-by-name mymaster)
// 3. Connects to primary
// 4. Subscribes to Sentinel pub/sub for +switch-master events
// 5. Reconnects to new primary on failover notification

# redis.conf (primary)

# Refuse to accept writes if fewer than 1 replica is connected and caught up
min-replicas-to-write 1

# A replica is considered "caught up" only if its replication lag is ≤ 10 seconds
min-replicas-max-lag 10