{
  "id": "replica-of",
  "title": "Replica Of geo-distributed Redis",
  "url": "https://redis.io/docs/latest/operate/rs/7.8/databases/import-export/replica-of/",
  "summary": "Replica Of provides read-only access to replicas of the dataset from different geographical locations.",
  "content": "In Redis Enterprise, the Replica Of feature provides active-passive geo-distribution to applications  for read-only access\nto replicas of the dataset from different geographical locations.\nThe Redis Enterprise implementation of active-passive replication is called Replica Of.\n\nIn Replica Of, an administrator designates a database as a replica (destination) of one or more databases (sources).\nAfter the initial data load from source to destination is completed,\nall write commands are synchronized from the sources to the destination.\nReplica Of lets you distribute the read load of your application across multiple databases or\nsynchronize the database, either within Redis Enterprise or external to Redis Enterprise, to another database.\n\nYou can [create Active-Passive]() databases on Redis Enterprise Software or Redis Cloud.\n\n[Active-Active Geo-Distribution (CRDB)]()\nprovides these benefits and also provides write access to all of the database replicas.\n\n\nConfiguring a database as a replica of the database that it replicates\ncreates a cyclical replication and is not supported.\n\n\nThe Replica Of is defined in the context of the destination database\nby specifying the source databases.\n\nA destination database can have a maximum of thirty-two (32) source\ndatabases.\n\nIf only one source is defined, then the command execution order in the\nsource is kept in the destination. However, when multiple sources are\ndefined, commands that are replicated from the source databases are\nexecuted in the order in which they reach the destination database. As a\nresult, commands that were executed in a certain order when compared\nacross source databases might be executed in a different order on the\ndestination database.\n\n\nThe Replica Of feature should not be confused with the\nin-memory [Database\nreplication]()\nfeature, which is used for creating a master / replica configuration that\nenables ensuring database high-availability.\n\n\n## Replication process\n\nWhen a database is defined as a replica of another database, all its\nexisting data is deleted and replaced by data that is loaded from the\nsource database.\n\nOnce the initial data load is completed, an ongoing synchronization\nprocess takes place to keep the destination always synchronized with its\nsource. During the ongoing synchronization process, there is a certain\ndelay between the time when a command was executed on the source and\nwhen it is executed on the destination. This delay is referred to as the\n**Lag**.\n\nWhen there is a **synchronization error**, **the process might stop** or\nit might continue running on the assumption that the error automatically\nresolves. The result depends on the error type. See more details below.\n\nIn addition, **the user can manually stop the synchronization process**.\n\nWhen the process is in the stopped state - whether stopped by the user\nor by the system - the user can restart the process. **Restarting the\nprocess causes the synchronization process to flush the DB and restart\nthe process from the beginning**.\n\n### Replica Of status\n\nThe replication process can have the following statuses:\n\n- **Syncing** - indicates that the synchronization process has\n    started from scratch. Progress is indicated in percentages (%).\n- **Synced** - indicates that the initial synchronization process was\n    completed and the destination is synchronizing changes on an ongoing\n    basis. The **Lag** delay in synchronization with the source is\n    indicated as a time duration.\n- **Sync stopped** - indicates that the synchronization process is\n    currently not running and the user needs to restart it in order for\n    it to continue running. This status happens if the user stops the\n    process, or if certain errors arose that prevent synchronization\n    from continuing without manual intervention. See more details below.\n\nThe statuses above are shown for the source database. In addition, a\ntimestamp is shown on the source indicating when the last command from\nthe source was executed on the destination.\n\nThe system also displays the destination database status as an aggregate\nof the statuses of all the sources.\n\n\nIf you encounter issues with the Replica Of process, refer\nto the troubleshooting section [Replica Of repeatedly\nfails]().\n\n\n### Synchronization errors\n\nCertain errors that occur during the synchronization process require\nuser intervention for their resolution. When such errors occur, the\nsynchronization process is automatically stopped.\n\nFor other errors, the synchronization process continues running on the\nassumption that the error automatically resolves.\n\nExamples of errors that require user intervention for their resolution\nand that stop the synchronization process include:\n\n- Error authenticating with the source database.\n- Cross slot violation error while executing a command on a sharded\n    destination database.\n- Out-of-memory error on a source or on the destination\n    database.\n\nExample of an error that does not cause the synchronization process to\nstop:\n\n- Connection error with the source database. A connection error might\n    occur occasionally, for example as result of temporary network\n    issues that get resolved. Depending on the connection error and its\n    duration the process might be able to start syncing from the last\n    point it reached (partial sync) or require a complete\n    resynchronization from scratch across all sources (full sync).\n\n## Encryption\n\nReplica Of supports the ability to encrypt uni-directional replication\ncommunications between source and destination clusters utilizing TLS 1.2\nbased encryption.\n\n## Data compression for Replica Of\n\nWhen the Replica Of is defined across different Redis Enterprise\nSoftware clusters, it may be beneficial to compress the data that flows\nthrough the network (depending on where the clusters physically reside\nand the available network).\n\nCompressing the data reduces the traffic and can help:\n\n- Resolve throughput issues\n- Reduce network traffic costs\n\nCompressing the data does have trade-offs, which is why it should not\nalways be turned on by default. For example:\n\n- It uses CPU and disk resources to compress the data before sending\n    it to the network and decompress it on the other side.\n- It takes time to compress and decompress the data which can increase\n    latency.\n- Replication is disk-based and done gradually, shard by shard in the\n    case of a multi-shard database. This may have an impact on\n    replication times depending on the speed of the disks and load on\n    the database.\n- If traffic is too fast and the compression takes too much time it\n    can cause the replication process to fail and be restarted.\n\nIt is advised that you test compression out in a lower environment\nbefore enabling it in production.\n\nIn the Redis Enterprise Software management UI, when designating a\nReplica Of source from a different Redis Enterprise Software cluster,\nthere is also an option to enable compression. When enabled, gzip\ncompression with level -6 is utilized.\n\n## Database clustering (sharding) implications\n\nIf a **source** database is sharded, that entire database is treated as\na single source for the destination database.\n\nIf the **destination** database is sharded, when the commands replicated\nfrom the source are executed on the destination database, the\ndestination database's hashing function is executed to determine to\nwhich shard/s the command refers.\n\nThe source and destination can have different shard counts and functions\nfor placement of keys.\n\n### Synchronization in Active-Passive Replication\n\nIn Active-Passive databases, one cluster hosts the source database that receives read-write operations\nand the other clusters host destination databases that receive synchronization updates from the source database.\n\nWhen there is a significant difference between the source and destination databases,\nthe destination database flushes all of the data from its memory and starts synchronizing the data again.\nThis process is called a **full sync**.\n\nFor example, if the database updates for the destination databases\nthat are stored by the destination database in a synchronization backlog exceed their allocated memory,\nthe source database starts a full sync.\n\n\nWhen you failover to the destination database for write operations,\nmake sure that you disable **Replica Of** before you direct clients to the destination database.\nThis avoids a full sync that can overwrite your data.\n\n\n## Active-Passive replication backlog\n\nIn addition to the [database replication backlog](), active-passive databases maintain a replication backlog (per shard) to synchronize the database instances between clusters.\nBy default, the replication backlog is set to one percent (1%) of the database size divided by the database number of shards and ranges between 1MB to 250MB per shard.\nUse the [`rladmin`]() utility to control the size of the replication backlog. You can set it to `auto` or set a specific size.  \n\nFor an Active-Passive database:\n```text\nrladmin tune db \u003cdb:id | name\u003e repl_backlog \u003cBacklog size in MB or 'auto'\u003e\n```\n\n\nOn an Active-Passive database, the replication backlog configuration applies to both the replication backlog for shards synchronization and for synchronization of database instances between clusters.\n\n",
  "tags": ["docs","operate","rs"],
  "last_updated": "2026-04-01T08:10:08-05:00",
  "children": [{"id":"create","summary":"Create Replica Of database","title":"Create a database with Replica Of","url":"https://redis.io/docs/latest/operate/rs/7.8/databases/import-export/replica-of/create/"},{"id":"replicaof-repeatedly-fails","summary":"Troubleshoot when the Replica Of process repeatedly fails and restarts.","title":"Replica Of Repeatedly Fails","url":"https://redis.io/docs/latest/operate/rs/7.8/databases/import-export/replica-of/replicaof-repeatedly-fails/"}]
}