Skip to content
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,34 @@ For each database, you can choose from these data eviction policies:

## Prevent data eviction

Redis Cloud supports [Auto Tiering]({{< relref "/operate/rs/databases/auto-tiering/" >}})
Redis Cloud supports [Auto Tiering]({{< relref "/operate/rs/databases/auto-tiering/" >}})
to prevent data eviction but maintain high performance.

Auto Tiering can extend your database across RAM and Flash Memory and intelligently manage "hot" (active) data in RAM and "cold" (less active) data in Flash memory (SSD).

## Active-Passive replication considerations

When using Active-Passive replication with [Replica Of]({{< relref "/operate/rs/databases/import-export/replica-of/" >}}), data eviction and expiration policies have important implications for data consistency.

{{< warning >}}
**Do not write to the destination (passive) replica database.** Writing to the destination replica can cause serious data consistency issues and replication failures.
{{< /warning >}}

### Problems caused by writing to passive replicas

In Active-Passive setups, eviction and expiration only operate on the active (source) database. When you write to the passive replica:

- **Memory management conflicts**: The passive replica cannot rely on eviction or expiration to manage local writes, requiring sufficient memory to handle both replicated data and local writes.
- **Data inconsistency**: Local writes create differences between the source and destination databases, causing replicated commands to behave differently on each database.
- **Replication failures**: Inconsistent data can cause replicated commands to fail with errors, which will cause the synchronization process to exit and break replication.

### Transitioning from passive to active

To properly transition a passive replica to become an active, writable database:

1. **Stop replication** using the Redis Cloud console interface
2. **Remove the replicaOf source** by running the `REPLICAOF NO ONE` command on the database

Both steps are required to ensure the database can safely accept writes and manage its own eviction and expiration policies.