Replica Redis per la ridondanza

Imagine your data disappearing or your server becoming overloaded! Redis replication is a robust feature designed to prevent these issues.

It allows you to create exact copies of your Redis dataset across multiple Redis instances. These copies are called replicas (formerly slaves), and the original is the master.

In a replication setup, one Redis instance acts as the master. It's the primary source for all write operations.

• Master: Handles all write commands (like SET, LPUSH) and propagates changes to its replicas.
• Replicas: Receive a copy of the master's data. They primarily handle read commands (like GET, LRANGE), offloading work from the master.

Replication brings several crucial advantages to your Redis deployment:

• Data Redundancy: If the master fails, your data isn't lost. A replica can be promoted to master.
• Read Scalability: Distribute read operations across multiple replicas, significantly increasing your application's read throughput.
• High Availability: Forms the basis for automatic failover solutions like Redis Sentinel.
• Data Backup: Replicas can be stopped and saved to disk without impacting the master.

When a replica connects to a master, a full synchronization occurs. The master creates a snapshot of its data and sends it to the replica.

After the initial sync, the master continuously sends new write commands to all connected replicas. This ensures replicas stay up-to-date in real-time. This is called partial resynchronization.

Let's simulate setting up a replica. First, ensure you have a master running (default port 6379). Then, start another Redis instance on a different port, say 6380:

After configuring a replica, you can check its status using the INFO replication command. Connect to both the master and replica instances to see their roles.

For the replica (port 6380), you should see its role as 'replica' and details about its master:

One of the main benefits is read scaling. You can configure your application to direct read queries to one or more replicas instead of always hitting the master.

• Master: Handles all SET, DEL, LPUSH, etc.
• Replicas: Handle GET, LRANGE, SMEMBERS, etc.

This distributes the workload and improves overall application responsiveness, especially for read-heavy applications.

Keep these points in mind when working with Redis replication:

• Read-Only Replicas: Replicas are usually configured as read-only to prevent accidental writes. This is the default behavior in modern Redis versions.
• Asynchronous Replication: Replication is asynchronous. This means a small delay might occur before data written to the master appears on replicas (eventual consistency).
• Manual Failover: If a master fails, you must manually promote a replica to master unless you use a high-availability solution like Redis Sentinel.

Redis replication is fundamental for many common scenarios:

• High Availability: Paired with Redis Sentinel, it provides automatic failover if the master becomes unavailable.
• Analytics & Reporting: Run complex queries or generate reports on replicas without impacting the performance of your primary application accessing the master.
• Data Distribution: Replicas can be geographically distributed to serve users closer to their location, reducing latency.
• Disaster Recovery: Replicas act as live backups, ready to take over if the master data is corrupted or lost.

Great job! In this lesson, we explored Redis replication.

• We learned that replication creates copies of your master dataset on replica instances.
• Key benefits include data redundancy and read scalability.
• We saw how to configure a basic replica using the --replicaof option.
• Replication is asynchronous and forms the backbone for higher availability solutions like Redis Sentinel.

Next, we'll dive into Redis Sentinel to achieve automatic failover!