Add Active-Passive replication warnings to data eviction policies

- Document that writing to destination (passive) replica causes data inconsistency
- Explain eviction/expiration only operates on active replica
- Detail memory management conflicts and replication failures
- Provide proper steps for transitioning passive to active database
- Include warning about syncer exit due to command failures

Addresses DOC-824

Author: mich-elle-luna

content/operate/rc/databases/configuration/data-eviction-policies.md

@@ -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.
+
+