The pull replication model allows a ScaleOut store to pull objects from a remote datacenter as they are needed. Objects can be shared by a geographically diverse network of ScaleOut datagrids.
Pull Replication
GeoServer pull replication differs from push replication in that objects are replicated across a WAN from a remote ScaleOut store to a local store as the objects are retrieved by an client app. The local copy of an object that has been replicated from a remote SOSS store is called a proxy, and the original object on the remote store is called the primary object.
A proxy object serves as a locally cached copy of its corresponding primary object. It is accessed using the same key as the primary object and is automatically refreshed by the ScaleOut service.
Most of the concepts related to pull replication involve setting up the coherency policy for proxy objects. A coherency policy controls the strategy for how a proxy object is refreshed to reflect the latest changes made to primary objects.
Proxy objects cannot be updated directly. If an application needs to update an object from either datacenter, the primary object must be migrated to the app's local datacenter.
Coherency Policies
Three coherency policies are available. When selecting a policy, consider the needs of your application with respect to how up-to-date proxy objects need to be.
Notify
Available for bi-directional use across two datacenters, the notify coherency policy replicates all changes to proxy objects in the companion datacenter. Because changes are shipped across the WAN immediately, proxy objects reflect changes with minimal delay.
Version 5.10 of ScaleOut GeoServer® Pro enhances the notify replication mode to improve resiliency during WAN outages. A local store is preemptively notified of the creation of a new remote primary object instead of waiting for a client app to read the object before setting up its proxy. This replication model ensures that two copies of each object are always maintained and can be accessed coherently from both stores. (See the User Guide for more information.)
Poll
The polling coherency policy causes a proxy object to periodically poll the primary object for updates. This policy optimizes network traffic between datacenters. If a network failure occurs when attempting to read the primary object, the ScaleOut service marks the local proxy as stale, and local reads may return stale data until the WAN connectivity issue is resolved.
Polling Use Cases
Use polling if your proxies do not need to reflect changes to the primary object immediately: If a primary object is updated, the change will not be reflected in the proxy until its next polling interval elapses.
Bi-directional replication is not required when using the polling coherency policy. However, applications can only perform updates to primary objects.
Manual
If manual coherency is used, a proxy will be automatically created in the application's local ScaleOut store when an object is first read, but the object will not be refreshed automatically. To force the local store to update its proxy, pass the GeoServerReadMode.Remote option as an argument to individual read operations.
Migrating the Primary Object
If you have configured bi-directional GeoServer Pull replication, a primary object can migrate between two datacenters: acquiring an exclusive lock on an object (using locking methods such as ReadExclusive) will synchronously transfer primary ownership to a client application's local ScaleOut store.
Using exclusively-locked retrievals ensures that your application always sees the latest updates to an object at any location. When an object is locked, its status as the primary copy of the object is transferred to the local ScaleOut StateServer store where the request is made. The remote store which previously held the master copy converts its copy to a proxy since the master copy can only be held in one store at a time.
Note
Migrating the primary copy of an object to your app's local datacenter requires a synchronous call over the WAN to the remote datacenter, which can introduce significant latency to your read operations. Consider designing your application to minimize these migrations.