Introduction: This is a continuation of the article on the Azure Redis Cache which is available here. The option of improving the zone redundancy requires replicas to be placed in different availability zones. A region supports three availability zones, and it is possible to spread the replicas over the availability zone when creating a new instance. This article delves into the options available to transfer the cache entries from an existing non-redundant AZ-server to the AZ-server. 

Solution: The standard configuration of a Redis server comes with a primary and a secondary server even if they are placed in the same datacenter. A geographical region consists of multiple zones and a zone consists of multiple datacenters, and the standard configuration does not have geo-redundancy.  It has replication built-in so that technique is applicable across any scope and between Redis instances as well.  When two Redis servers make use of the replication this way, they are said to be linked. When the servers are linked, only one can take writes, which is the source of the link and not the target. When a manual failover occurs, the link must be broken before the target can be made the primary. The writes are always in one place even if there is connection forwarding. We don’t discuss clustered options in linking because the shard count can vary between the source and the target of the link, which prevents replication.

The other option requires the import and export of data, and this has the added benefit of not being governed by configurations and topology of the data import and export. This option requires a storage account for the data to be exported and imported. The data is usually in the format of RDB and the manner of the import is the same as new entries being set in the cache. Each export is a full backup of the data in RDB format which means that there are no incremental changes, unlike AOF-based persistence.  Although data can be periodically exported, the export-import is usually one time and at the beginning of the use of the new server. When the data is imported more than once, the old entries from the previous import are not overwritten and the new entries are added.  Time to the expiry of the objects is not reset in the new server.

 

Comparisions of these two options can be summarized as follows:

Feature	Linking based replication	Export-Import based replication
Works for standalone non-AZ server to non-AZ server	yes	yes
Works for standalone non-AZ server to non-AZ server with RDB persistence	yes	yes
Works for non-AZ to AZ-redundant data transfer	no	yes
Works for server with persistence	no	yes
Works for server with AOF persistence	no	yes
Works for server with clustered option	no	yes
Has no dataloss	yes	no (upto 15 mins depending on the size of the cache)
Requires premium subscription	yes	yes