Redis Essentials: Installation, Persistence, and High Availability

Redis stands as an open-source, high-performance in-memory data store. Often referred to as a data structure server, it supports various data types including strings, hashes, lists, sets, and sorted sets. These data types allow for atomic operations such as appending to strings, incrementing hash values, adding elements to lists, and performing set intersections, unions, and differences.

To achieve its notable performance, Redis primarily operates with an in-memory dataset. However, it also provides robust data persistence mechanisms, including periodic disk snapshots (RDB) and an append-only file (AOF) that logs every write operation.

Furthermore, Redis supports master-replica (formerly master-slave) replication, featuring fast, non-blocking initial synchronization and automatic reconnection upon network disconnections. Additional features encompass basic transaction support, publish/subscribe messaging, pipelining, and a wide array of client libraries for most popular programming languages.

Setting Up Redis

Installation Steps

To install Redis, typically you'll download the source, compile, and install it. Here's a common sequence of commands:

# Download the Redis source archive
wget http://download.redis.io/releases/redis-4.0.10.tar.gz

# Extract the archive
tar -xvf redis-4.0.10.tar.gz

# Navigate into the extracted directory
cd redis-4.0.10

# Compile Redis
make

# Install Redis binaries to /usr/local/bin
make install

# Start the Redis server in the background using default configuration
# It will listen on port 6379 by default without a password
nohup redis-server &

# To start with a specific configuration file (e.g., located at /path/to/redis.conf)
# nohup redis-server /path/to/redis.conf &

Basic Client Interaction

Once the server is running, you can interact with it using the Redis command-line interface (redis-cli). To connect to a specific port, use the -p flag.

# Connect to Redis on the default port 6379
redis-cli

# Test connection
127.0.0.1:6379> ping
PONG

# Set a key-value pair
127.0.0.1:6379> set mykey "hello redis"
OK

# Retrieve the value for a key
127.0.0.1:6379> get mykey
"hello redis"

# Delete a key
127.0.0.1:6379> del mykey
(integer) 1

# Set a key with an expiration time of 10 seconds
127.0.0.1:6379> setex expiringkey 10 "ephemeral value"
OK

# Alternatively, set expiration for an existing key (in seconds)
127.0.0.1:6379> set anotherkey "some value"
OK
127.0.0.1:6379> EXPIRE anotherkey 300
(integer) 1

# View remaining time to live (TTL) for a key
127.0.0.1:6379> TTL expiringkey
(integer) 8

# Remove expiration from a key, making it persistent
127.0.0.1:6379> PERSIST anotherkey
(integer) 1

Common Key Management Commands

Redis provides a rich set of commands for managing keys:

  • DEL key [key ...]: Deletes one or more keys.
  • DUMP key: Serializes the value stored at a key and returns it.
  • EXISTS key [key ...]: Checks if one or more keys exist.
  • EXPIRE key seconds: Sets a timeout on key. After the timeout has expired, the key will automatically be deleted.
  • EXPIREAT key timestamp: Sets the expiration for a key as a UNIX timestamp.
  • PEXPIRE key milliseconds: Sets a timeout on key in milliseconds.
  • PEXPIREAT key milliseconds-timestamp: Sets the expiration for a key as a UNIX timestamp specified in milliseconds.
  • KEYS pattern: Finds all keys matching the given pattern. For example, KEYS * returns all keys.
  • MOVE key db: Moves a key from the currently selected database to the specified destination database.
  • PERSIST key: Removes the expiration from a key, making it persistent.
  • PTTL key: Returns the remaining time to live of a key in milliseconds.
  • TTL key: Returns the remaining time to live of a key in seconds.
  • RANDOMKEY: Returns a random key from the currently selected database.
  • RENAME key newkey: Renames a key.
  • RENAMENX key newkey: Renames a key, only if the new key name does not exist.
  • TYPE key: Returns the type of value stored at key (string, list, set, etc.).

Stopping Redis

To gracefully shut down the Redis server:

# Shutdown Redis connected locally
redis-cli shutdown

# If Redis was installed via a package manager (e.g., yum), you might use systemctl
# systemctl stop redis

# If a password is set or connecting remotely, include host, port, and password
# redis-cli -h your_redis_host -p 6379 -a your_password shutdown

Exiting the Client

To exit the Redis command-line interface:

127.0.0.1:6379> QUIT

Configuring Password and Remote Access

For security, it's crucial to set a password and control network access. This is typically done in the redis.conf file:

# Locate 'requirepass' in redis.conf and uncomment/modify it
# requirepass your_strong_password

# For remote access, ensure 'protected-mode' is 'no' and 'bind' is commented out or set to 0.0.0.0
# protected-mode no
# bind 127.0.0.1   # Comment this line to allow connections from all interfaces, or set to 0.0.0.0

After modifying the configuration, restart Redis with the updated config file. Then, connect to Redis with authentication:

# Start Redis with the specified configuration
nohup redis-server /path/to/your/redis.conf &

# Connect using host, port, and password
redis-cli -h 127.0.0.1 -p 6379 -a your_strong_password

# Alternatively, authenticate after connecting
# redis-cli
# auth your_strong_password
# OK

Viewing Server Statistics

The INFO command provides comprehensive statistics and information about the Redis server. Key sections include:

# In the redis-cli, execute:
127.0.0.1:6379> info
  • Server: Redis version, OS, architecture, process ID, uptime, listening port, config file path.
  • Clients: Number of connected clients, longest output list, biggest input buffer, blocked clients.
  • Memory: Total memory allocated by Redis (used_memory), human-readable format (used_memory_human), memory consumption peak, memory fragmentation ratio.
  • Persistence: RDB/AOF loading status, last save time, AOF enabled status, AOF file size, rewrite status.
  • Stats: Total connections received, commands processed, instantaneous operations per second, rejected connections, expired/evicted keys, keyspace hits/misses.
  • Replication: Server role (master/replica), connected replicas, master host/port (if replica), replication offset.
  • CPU: System and user CPU time consumed by Redis and its background processes.
  • Keyspace: Number of keys, expired keys, and average TTL per database.

Other Useful Commands

  • DBSIZE: Returns the number of keys in the currently selected database.
  • KEYS *: Lists all keys in the database (use with caution in production environments as it can block the server).
  • CLIENT LIST: Returns information and statistics about all connected clients.
  • CLIENT KILL [ip:port]: Kills the connection of a client specified by IP address and port.
  • FLUSHALL: Deletes all keys from all databases.
  • FLUSHDB: Deletes all keys from the currently selected database.
  • LASTSAVE: Returns the UNIX timestamp of the last successful save to disk.
  • TIME: Returns the current server time as a two-item array (UNIX timestamp and microseconds).
  • SELECT index: Changes the currently selected database (default is 0).
  • MOVE key destination_db: Moves a key from the current database to the specified destination database.

Configuring Redis Parameters

Key parameters in redis.conf:

  • daemonize yes/no: Run Redis as a daemon.
  • port 6379: The port Redis will listen on.
  • timeout 0: Client idle timeout in seconds.
  • maxclients 10000: Maximum number of connected clients.
  • maxmemory <bytes>: Maximum memory Redis will use.
  • maxmemory-policy volatile-lru: Eviction policy when maxmemory is reached.
  • slowlog-log-slower-than 10000: Log queries slower than this many microseconds.
  • slowlog-max-len 128: Maximum number of entries in the slow log.

You can inspect and modify parameters at runtime:

# Get current maxclients setting
127.0.0.1:6379> config get maxclients
1) "maxclients"
2) "10000"

# Set maxclients to a new value at runtime
127.0.0.1:6379> config set maxclients 10001
OK

Data Persistence in Redis

Redis is an in-memory database, which means data resides in RAM for speed. To prevent data loss in case of server crashes or restarts, Redis offers two primary persistence mechanisms: RDB (Redis Database) snapshots and AOF (Append-Only File) logging.

RDB: Snapshotting

RDB persistence involves taking point-in-time snapshots of the Redis dataset and saving them to disk as a binary file (dump.rdb). This method is ideal for backups and disaster recovery.

Configuration in redis.conf:

# Automatic saving to disk conditions:
# Save if 1 key changes in 900 seconds (15 minutes)
save 900 1
# Save if 10 keys change in 300 seconds (5 minutes)
save 300 10
# Save if 10000 keys change in 60 seconds (1 minute)
save 60 10000

# Filename for the RDB persistence file
dbfilename "dump.rdb"

# Directory where RDB files will be stored
dir "/var/lib/redis/"

These save rules trigger a background save (BGSAVE) when satisfied. You can also manually trigger RDB saves:

  • SAVE: This command performs a synchronous save, blocking the Redis server until the RDB file is fully written. During this time, Redis cannot process any other commands.
  • BGSAVE: This command performs an asynchronous save by forking a child process to handle the disk writing. The parent Redis process remains unblocked and continues serving client requests. While more efficient, BGSAVE can temporarily double memory usage as the child process is a copy of the parent's memory space.

You can also dynamically adjust RDB save conditions:

# Check current RDB save configurations
127.0.0.1:6379> CONFIG GET save
1) "save"
2) "900 1 300 10 60 10000"

# Modify RDB save configuration (e.g., save if 1000 changes in 21600 seconds)
127.0.0.1:6379> CONFIG SET save "21600 1000"
OK

AOF: Append-Only File

AOF persistence logs every write operation received by the server. Instead of saving the data state, it records the commands necessary to rebuild the dataset. When Redis restarts, it re-executes the commands from the AOF file to restore the data.

Example AOF file content:

*2
$6
SELECT
$1
0
*3
$3
SET
$3
key
$5
value

Configuring AOF in redis.conf:

# Directory where AOF files will be stored
dir "/var/lib/redis/"

# Enable AOF persistence (default is 'no')
appendonly yes

# Filename for the AOF persistence file
appendfilename "appendonly.aof"

# AOF fsync policy (controls how often data is written to disk)
appendfsync everysec

# AOF rewrite conditions:
# Trigger rewrite when current AOF size is 100% larger than last rewrite size
auto-aof-rewrite-percentage 100
# Trigger rewrite only if AOF size is at least 64MB
auto-aof-rewrite-min-size 64mb

AOF persistence involves three steps: command append, file write, and file synchronization (fsync).

  1. Command Append: Every write command is appended to the AOF buffer.
  2. File Write: The AOF buffer content is written to the operating system's file buffer for the AOF file.
  3. File Synchronization (fsync): The OS file buffer is flushed to physical disk. The appendfsync setting controls the frequency of this crucial step:
    • always: Redis performs an fsync operation for every write command. This offers the strongest data safety but is the slowest option.
    • everysec: Redis performs an fsync once per second. This is a good balance between data safety (losing at most one second of data) and performance.
    • no: Redis leaves fsync decisions to the operating system. This is the fastest option but offers the least data safety, as data might be lost from the OS buffer during a crash.

AOF files can grow very large over time because they record every write operation. To mitigate this, Redis implements an AOF rewrite mechanism. This process creates a new, optimized AOF file by removing redundant commands (e.g., multiple updates to the same key, deleted keys). The auto-aof-rewrite-percentage and auto-aof-rewrite-min-size parameters determine when an automatic rewrite should be triggered. If the current AOF file size exceeds auto-aof-rewrite-min-size and its growth percentage relative to the last rewrite's size surpasses auto-aof-rewrite-percentage, a rewrite is initiated.

When Redis restarts, if both RDB and AOF persistence are enabled, Redis will prioritize using the AOF file to restore the dataset, as it typically offers better data durability.

Redis Replication (Master-Replica)

Redis replication allows data from a master instance to be copied to multiple replica instances. This setup enhances data redundancy, scalability for read operations, and fault tolerance. Replication works using a publish/subscribe mechanism, where the master publishes its writes to connected replicas.

Configuring Master and Replicas

A typical setup involves one master and one or more replicas. Replicas can also serve as masters for other replicas, forming a hierarchical structure.

Master Configuration

The master instance needs to be configured to listen on a network interface that replicas can reach. In redis.conf, modify the bind directive:

# On your master server (e.g., 10.86.255.166)
# vi /etc/redis/redis.conf
bind 10.86.255.166

After changes, restart the Redis master.

Replica Configuration

On each replica instance, you need to tell it which master to replicate from. This is done via the slaveof directive in its redis.conf:

# On your replica server (e.g., 10.86.255.167)
# vi /etc/redis/redis.conf
slaveof <masterip> <masterport> # Specify the master's IP and port
masterauth <master-password>   # If the master requires authentication
slave-read-only yes            # Recommended: set replicas to read-only mode

Alternatively, you can configure replication dynamically using the redis-cli:

# On the replica instance, connect to its redis-cli
redis-cli -p 6379
127.0.0.1:6379> SLAVEOF <masterip> <masterport>
OK

Verifying Replication Status

Use the INFO replication command on both master and replica instances to check the replication status.

# On the master
127.0.0.1:6379> INFO replication
# Replication
role:master
connected_slaves:1
slave0:ip=10.86.255.167,port=6379,state=online,offset=309,lag=1
...


# On the replica
127.0.0.1:6379> INFO replication
# Replication
role:slave
master_host:10.86.255.166
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:365
slave_priority:100
slave_read_only:1
...

A healthy replication setup will show master_link_status:up on the replica, and the master_repl_offset and slave_repl_offset values should be close or equal, indicating data synchronization.

Promoting a Replica to Master

If the master becomes unavailable, a replica can be promoted to a master. This involves stopping replication to its former master:

# On the replica instance you want to promote
redis-cli -p 6379
127.0.0.1:6379> SLAVEOF NO ONE
OK

# Verify its new role
127.0.0.1:6379> info replication
...
role:master
...

Replication Health Checks and Partial Resynchronization

Replicas periodically send PING commands to the master (controlled by repl-ping-slave-period, default 10 seconds). If the connection breaks, Redis 2.8 and latter versions support partial resynchronization using a replication backlog buffer on the master. If the replica reconnects and its replication offset falls within the master's backlog, only the missing data is sent. Otherwise, a full resynchronization occurs.

Master Write Behavior Control

Since Redis 2.8, you can configure a master to accept write operations only when a minimum number of replicas are connected and synchronized within a specified lag time. This helps prevent data loss if the master becomes isolated:

# In redis.conf on the master
min-slaves-to-write 3 # Master requires at least 3 connected replicas
min-slaves-max-lag 10 # Replicas must not lag behind by more than 10 seconds

Redis High Availability with Sentinel

Redis Sentinel is a distributed system designed to provide high availability for Redis deployments. It monitors master and replica instances, automatically handles failovers when a master is detected as down, and reconfigures instances accordingly.

Sentinel Architecture

A typical Sentinel setup involves multiple Sentinel processes running on different servers, monitoring a set of Redis master and replica instances. When a master fails, Sentinels agree on its unavailability and elect one of the replicas to be the new master, then reconfigure other replicas to follow the new master.

Configuring and Starting Sentinels

Each Sentinel instance requires its own configuration. Here's an example:

# In /etc/redis-sentinel.conf
daemonize yes # Run Sentinel as a daemon
port 26379    # Sentinel's listening port

# Monitor a master named 'mymaster' at <masterip>:6379,
# with a quorum of 2 Sentinels required to agree on a failure
sentinel monitor mymaster <masterip> 6379 2

Start a Sentinel process using the configuration file:

redis-sentinel /etc/redis-sentinel.conf
# Alternatively
redis-server /etc/redis-sentinel.conf --sentinel

Deploy multiple Sentinels, ideally an odd number (e.g., 3, 5) on different machines, for robust quorum-based decision making.

Verifying Sentinel Status

Connect to a Sentinel instance using redis-cli (specifying the Sentinel's port):

redis-cli -p 26379

# Get general Sentinel information
127.0.0.1:26379> INFO sentinel

# Get information about monitored masters
127.0.0.1:26379> sentinel masters

# Get information about replicas for a specific master
127.0.0.1:26379> sentinel replicas mymaster

Failover Demonstration

To observe Sentinel's failover capability, stop the current Redis master instance:

# On the Redis master
127.0.0.1:6379> SHUTDOWN

The Sentinels will detect the master's failure, elect a new master from the available replicas, and reconfigure the remaining replicas to follow the new master. You can check the Sentinel logs (e.g., /var/log/redis/sentinel.log) for failover events. Then, check the roles of your Redis instances:

# On the former replica that became the new master
<new_master_ip>:6379> info replication
role:master
...

# On other replicas
<replica_ip>:6379> info replication
role:slave
master_host:<new_master_ip>
...

If you restart the original master, Sentinel will automatically reconfigure it as a replica of the newly elected master.

Sentinel Command-Line Interface

Sentinels also expose commands for management and inspection:

  • SENTINEL masters: Lists all monitored masters and their state.
  • SENTINEL replicas <master-name>: Lists replicas for the specified master.
  • SENTINEL get-master-addr-by-name <master-name>: Returns the IP and port of the current master for a specific monitored master name. Clients can use this to discover the current master.
  • SENTINEL reset <master-name>: Resets the state of a specific master and all its replicas.
  • SENTINEL failover <master-name>: Forces a failover for a master, even if its still reachable.
  • SENTINEL flushconfig: Forces the Sentinel to rewrite its configuration on disk, often used after manual configuration changes.

Tags: Redis Persistence RDB AOF Replication

Posted on Fri, 08 May 2026 23:23:31 +0000 by john8675309

Hot Tags

©2026 Freaks City