NCache Bridge provides you with two kinds of configurations:
This configuration is mostly used for creating backups for disaster recovery. In this configuration we have an active site, bridge and a passive site.
Operations are replicated to the passive site from active site through bridge. No requests are directed to the passive site.
Bridge is created at the active site to reduce bridge replication cost from source to bridge.
If the active site goes down by any cause, you can redirect your requests to your passive site by making it active. Your passive site will behave as active and treat all requests without any failures.
When your old active site is ready and restarted than you can reform your configurations as it was before. Make both sites active and this will transfer all data from old passive to old active site. When all data is transferred then you can make configurations to your passive site and redirect all requests to the active site.
This configuration is used when you have active data centers in two regions and you want to synchronize caches from those regions. It has all the active sites on both ends of bridge.
Client requests are treated by all sites so replication is bidirectional.
You can create bridge at any site because here both sites are active. Mostly bridge resides in the region of sites that have high user traffic to reduce bridge replication cost.
Communication is between two active caches so it is also possible that the same cached data is updated on both sites’ caches almost simultaneously which produce a conflict. To resolve this conflict, NCache provides configurable Conflict Resolver which resolves operation conflict on bridge time. By default, the latest operation "wins" and is applied on cache in case of conflict.
Your caches in different region can have different time zone. So for resolving conflict of time both caches synchronized their time with bridge time.
If any site goes down than you can redirect all request to other active site. When downed site is up again data is transferred from already running site to this site and can redirect that region's request to this site.
Runtime Transfer Data: You can transfer data from any site to others forcefully if you think both your caches are not synchronized. For example, if you are using 2- node partitioned cluster caches on both sides and from one site cache one node of the cluster cache goes down, your data will be lost. Now you can forcefully transfer all data from the other cache to this cache through bridge.
Runtime Switching between Configuration Modes: You can switch between your active and passive mode of any site at runtime. This means that you can change your active-passive configuration to active-active configuration and vice versa.
Connect/Disconnect bridge caches: You can easily connect or disconnect your cache from bridge at runtime in terms of replication of data without affecting client requests. When a cache is disconnected from the bridge then bridge does not send any operations to that cache for replication. Also, a disconnected cache does not send operation to the bridge. When you reconnect a disconnected cache, state transfer occurs to synchronize both caches.
Runtime Scalability: You can add or remove bridge nodes at runtime for up to 2 nodes without affecting client’s requests on your clusters.