How Does Redis RDB Persistence Work?

What is RDB Persistence?

RDB (Redis Database) is Redis's persistence mechanism that takes point-in-time snapshots of your data. Think of it like taking a photograph of your database's complete state at a specific moment.

Core RDB Mechanisms

1. Snapshot Creation Process

BGSAVE Command Flow (Recommended):

1. Command Trigger: Client sends BGSAVE request
2. Process Forking: Main process forks a persistence child process
3. Parallel Processing:
   • Child process traverses memory to generate snapshot → writes to temp file → atomically replaces old file
   • Main process continues serving client requests, using Copy-on-Write to ensure data consistency
4. Completion Notification: Child process exits, main process updates persistence status

SAVE Command Notes

• Synchronous Blocking: Main process handles persistence directly, blocking all requests
• Usage Risk: Can cause service unavailability (longer blocks with larger datasets)
• Suitable Scenarios:
  • Development environment debugging
  • Low-traffic maintenance windows

2. Copy-on-Write Technology

Copy-on-Write is a core optimization technique Redis uses during RDB file generation. Like photography, it captures the state at the moment of the snapshot, and subsequent modifications don't affect the captured image.

Key Principles:

• Parent and child processes share memory pages
• When parent process modifies data, it copies the modified page
• Child process continues writing original snapshot data

Working Flow:

1. When forking occurs, parent and child processes share the same memory space
2. When parent process handles write requests, it copies the memory page to be modified
3. Parent process makes changes on the copy, child process uses original data
4. Child process safely writes data to RDB file

Advantages:

• Avoids direct full data copying, saving memory
• Ensures snapshot consistency
• Minimizes impact on main process

# Monitor fork latency
redis-cli info stats | grep latest_fork_usec
# Example output: latest_fork_usec: 523 (microseconds)

Important Considerations:

• More write operations mean higher additional memory overhead
• Large object modifications cause entire page copies
• Memory fragmentation may impact performance

3. RDB File Structure

The RDB file is stored in a compressed binary format with three main sections:

1. File Header

REDIS0009    # Redis magic number + version
FE 00        # Database selector
FB           # Database number
$5           # Key-value pair count

Field Descriptions:

• Magic Number: Fixed "REDIS" string for quick file type identification
• Version Number: 4-digit number, e.g., "0009" indicates RDB version 9

2. Data Section

Data Type Encoding:

• String: Most basic data type
• List/Set/Sorted Set/Hash: Uses specific identifiers
• Expiration Time: Supports second and millisecond precision

3. File Footer

• Uses CRC64 checksum to ensure file integrity
• File end marker (FF) indicates RDB file completion

Key Points:

• File format supports incremental updates, newer versions are backward compatible
• CRC64 checksum algorithm ensures data integrity
• LZF algorithm compression reduces storage space

Key Configuration Parameters

1. Basic Configuration

# Automatic snapshot trigger (after 1 modification within 900 seconds)
save 900 1

# RDB filename
dbfilename dump.rdb

# Compression settings
rdbcompression yes
rdbchecksum yes

2. Advanced Configuration

# Stop writes on background save error
stop-writes-on-bgsave-error yes

# Child process memory limit
rdb-save-incremental-fsync yes

Best Practices

1. Production Environment Configuration

Backup Strategy:

• Master Node: Disable automatic save, schedule manual BGSAVE
• Replica Node: Configure save 900 10000 trigger rule

2. Performance Optimization

• Memory Control: Single RDB file should not exceed 10GB
• Disk Space: Maintain 2x memory as available space
• Monitoring Metrics:

  # Monitor persistence status
  redis-cli info persistence | grep -E "rdb_last_save_time|rdb_last_bgsave_status"
  

RDB vs AOF Comparison

Common Issues and Solutions

1. Snapshot-Related Performance Issues

Symptoms:

• Increased client request latency
• Sudden Redis memory usage spike

Solutions:

# Adjust Linux kernel parameters
vm.overcommit_memory = 1
transparent_hugepage = never

2. Data Loss Risk

Scenario Example:

• Configuration: save 60 10000
• 9999 writes occur at 59 seconds, system crashes at 61 seconds → All data is lost

Optimization:

# Combine RDB+AOF
aof-use-rdb-preamble yes

3. RDB File Corruption

Recovery Steps:

# 1. Verify file integrity
redis-check-rdb --fix dump.rdb

# 2. Use redis-restore tool
cat dump.rdb | redis-restore --host 127.0.0.1 --port 6379

Summary

RDB persistence forms the foundation of Redis's data safety strategy. Proper configuration can balance performance and reliability. In production environments, it's recommended to combine RDB snapshots with AOF logs for both minute-level and second-level protection.

Related Topics:

• How Does Redis AOF Persistence Work?
• Practice Redis Interview Questions Like LeetCode
• Interview Practice: Redis Persistence Mechanisms