Redis Replication Made Simple: With Spring Boot Integration
Arata

Arata @aratax

About: Coding, and writing the future

Location:
Between screens and servers
Joined:
Aug 3, 2025

Redis Replication Made Simple: With Spring Boot Integration

Publish Date: Aug 9
0 0

Imagine it’s 3 AM. Your Redis server—yes, the one holding all your app’s session data—just crashed. Your team’s phones are buzzing. Users are locked out, and panic is rising.

What if I told you this nightmare could be avoided with a simple feature built right into Redis? Enter Redis replication—your built-in safeguard for data availability, read scaling, and peace of mind.


🔑 What Is Redis Replication?

At its core, Redis replication enables a single Redis instance (the primary) to automatically copy its data to one or more replicas.

  • The primary handles all write operations.
  • Replicas stay in sync and serve read requests, reducing the load on the primary.
  • If the primary fails, replicas can quickly take over.

This fundamental setup lays the groundwork for high availability and scaling in Redis environments.


⚙️ How Does It Work?

Redis replication works in three key stages:

  1. Initial Sync: A replica requests a full snapshot (RDB) from the primary, loads it, and applies any updates.
  2. Command Streaming: Once synced, the replica continuously receives write commands from the primary to stay current.
  3. Partial Resync (PSYNC2): If a replica temporarily disconnects, it resumes from where it left off using Redis’s backlog buffer—avoiding a full resync.

This process is asynchronous, which means replicas may lag slightly but offer high throughput.


🖥 Setting Up Replication (Primary + Two Replicas)

Here’s how to launch a simple master-replica setup locally:

# Start Primary
redis-server --port 6379

# Start Replica 1
redis-server --port 6380 --replicaof 127.0.0.1 6379

# Start Replica 2
redis-server --port 6381 --replicaof 127.0.0.1 6379
Enter fullscreen mode Exit fullscreen mode

At this point, reads can be routed to replicas while writes continue to flow to the primary.


🆕 Chained Replication (Replica of a Replica)

Beyond basic replication, Redis supports chained replication, where a replica can act as a source for another replica.

Why Use It?

  • Reduce primary load: Only one replica pulls directly from the primary.
  • Regional optimization: Place replicas closer to users while syncing through a nearer node.
  • Better bandwidth usage: Ideal for distributed or high-latency networks.

Example:

# Primary
redis-server --port 6379

# Replica 1 (syncs from primary)
redis-server --port 6380 --replicaof 127.0.0.1 6379

# Replica 2 (syncs from Replica 1)
redis-server --port 6381 --replicaof 127.0.0.1 6380
Enter fullscreen mode Exit fullscreen mode

✒Deployment Diagram

This diagram shows a primary node with two direct replicas and one chained replica.

          +--------+
          | Server |
          +---+----+
              |
             WRITE
              v
          +--------+
          | Master |
          +---+----+
          /        \
     SYNC/          \SYNC
        v            v
+-------+--+    +----+------+
| Replica  |    |  Replica  |
+----+-----+    +-----+-----+
     |
 CHAINED SYNC
     v
+----+-----+
| Replica  |
+----------+
Enter fullscreen mode Exit fullscreen mode

⚡ Diskless Replication

To further speed up initial synchronization, enable diskless replication, which streams snapshots directly to replicas:

redis.conf (master)

repl-diskless-sync yes
repl-diskless-sync-delay 5
Enter fullscreen mode Exit fullscreen mode

redis.conf (replica)

replicaof redis-master 6379
replica-read-only yes
repl-diskless-load on-empty-db
Enter fullscreen mode Exit fullscreen mode

This avoids writing intermediate files to disk and is ideal for large datasets or high-performance environments.


🔧 Spring Boot with Redis Replicas

Let’s integrate this into a Spring Boot project for practical use.

Dependency:

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
Enter fullscreen mode Exit fullscreen mode

Configuration:

@Bean
public LettuceConnectionFactory redisConnectionFactory() {
    RedisStaticMasterReplicaConfiguration masterReplicaConfig =
            new RedisStaticMasterReplicaConfiguration("127.0.0.1", 6379);
    masterReplicaConfig.addNode("127.0.0.1", 6380);
    masterReplicaConfig.addNode("127.0.0.1", 6381);
    masterReplicaConfig.setPassword(RedisPassword.of("myRedisPass"));

    LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
            .readFrom(ReadFrom.ANY_REPLICA)
            .build();

    return new LettuceConnectionFactory(masterReplicaConfig, clientConfig);
}
Enter fullscreen mode Exit fullscreen mode

This configuration connects Spring Boot to a primary and its replicas, preferring replica reads automatically.


🛠 Verifying Reads Are Hitting Replicas

To confirm that reads hit replicas rather than the primary:

1️⃣ Monitor Replica Activity

redis-cli -p 6380 MONITOR
Enter fullscreen mode Exit fullscreen mode

Execute a read query and see it logged on the replica.

2️⃣ In Spring Boot

@Autowired
private RedisTemplate<String, Object> redisTemplate;

@Bean
public CommandLineRunner testRedis() {
    return args -> {
        ValueOperations<String, Object> ops = redisTemplate.opsForValue();
        ops.set("user:1", "Alice"); // Write -> Master
        String value = ops.get("user:1"); // Read -> Replica
        System.out.println("Read value (replica preferred): " + value);
    };
}
Enter fullscreen mode Exit fullscreen mode

⚠️ Limitations of Replicas Alone

However, while replication improves resilience, it doesn’t guarantee full HA on its own.

  • No automatic failover: Promotion must be done manually without Sentinel or Cluster.
  • Asynchronous replication: Recent writes might be lost if the primary fails before syncing.
  • Single control point: The primary remains the bottleneck for writes.

These gaps highlight why replication is essential but insufficient for full HA in production environments.


✅ Final Thoughts

Redis replication is a simple yet powerful way to protect against single points of failure, scale reads, and prepare for failover. Its nature—one primary continuously mirrored by one or more replicas—ensures that your data is redundant, accessible, and performance-optimized.

Why use replicas?

  • Keep a live backup ready for emergencies.
  • Reduce read load on the primary.
  • Improve latency with geographically placed replicas.

Key takeaway: Replication is your first step toward high availability. Pair it with Sentinel for automatic failover or Cluster for sharding to achieve a production-grade, fault-tolerant Redis deployment.


🛠 Demo Project for Readers

I have created a demo project that showcases practical usage of Redis replica.

Project Includes:

  • Docker: Pre-configured Redis master & replicas using docker-compose.
  • Spring Boot: Example backend service demonstrating Redis read/write splitting.

🔗 Access the Project

You can clone or explore the project from my repository :

git clone https://github.com/arata-x/redis-ha.git
cd redis-ha
Enter fullscreen mode Exit fullscreen mode

Additional Resources

Comments 0 total

    Add comment