WAN Replication through Bridge

For large scale applications, distributed caches are used to improve performance, reliability and runtime scalability of your applications. So distributed caches can be a very important part of your disaster recovery plan, a disaster ranging from natural disasters to internal hardware disasters or software failure.

The best and most used disaster recovery plan is live data replication to other backup sites. So when needed, you can redirect your live users to your backup site without any error. However, this requires making sure that your active and backup caches are both synchronized at any time. If they are not synchronized, then that can affect your applications’ cache clients.

Data replication also solves the problem for you if you not only have disaster recovery plans but also want to deploy your application on geographically separated regions for widely spread customers. Here you can have two or more active sites which will deal with users of related regions and also can be used as backup of other region sites.

NCache provides you WAN replication through the Bridge feature. A bridge is created between two cluster caches and data is replicated from the source to the other site through that bridge.

Pluggable Caching Architecture: Caches are not aware of each other; they just know about the bridge and replicate their data to bridge. Due to this loose coupling, you can configure bridge between any two caches irrespective of their cache topology. You can freely remove caches configured with bridge.

Data Integrity: Operations performed at source cache are en-queued by the bridge maintaining the actual order in which they were performed at source cache. Bridge performs operations on target cache in the same order. Conflicts are resolved on target cache. In this way, caches eventually become consistent.

Dedicated Bridge Service: Bridge is also a stand-alone and dedicated service like cache service so your cache operations will not be affected if bridge operations are delayed due to latency in the network.

Configuring Bridge: You can configure your bridge on the same server where your cluster cache resides or you can create it on separate server node. Then you can add both of your cluster caches into bridge and data will be replicated between them.

Disaster Recovery: You can configure bridge between an active and passive data center for disaster recovery.

Dealing Geographically Spread Customer: You can have two active sites which will deal users of related regions and also can be used as backup of other region sites.

Asynchronous Replication: For WAN replication, asynchronous replication is used so that cache operations will not suffer in case of delays in bridge operations.

Queue Backup: Bridge is basically a two node clustered queue in which one node is active and other is passive having a backup of active queue to avoid data loss on bridge.

Connection Retries: Bridge also tries to replicate all operations by retrying when any connection failure occurs.

Configurable Queue Size: Bridge replicator queue size is configurable. You should configure the size of bridge queue by analyzing your cache load because every update will be replicated to the bridge queue and if it has less size, then your queue can end up full which can cause data loss.

Bridge Caches: You can use any topology for cluster caches that will be part of bridge. You can also use two different topology caches on each site in one bridge. However, the same topology on both sides is mostly used.

Note

It is recommended that bridge caches have the same configurations other than topology to avoid issues. For example, if the data source is configured on one cache you should configure it on other cache too. This is because the same operation specifications from one site cache will be replicated to the other site.

In This Section

Bridge Configurations
Explains the two kinds of Bridge configurations provided in NCache.

Implementing Bridge Conflict Resolver
Explains how to implement and use Bridge Conflict Resolver in NCache.