Persistence Service Sets: Primary and Standby
To prepare for disaster recovery, each persistence cluster divides its services into two parallel sets: primary and standby.
- Primary Set
- Application processes interact with the leader of the primary set. The leader replicates persistence data to the other members of the primary set. The leader also replicates its data to the leader of the standby set.
- Standby Set
- The leader of the standby set receives data from the leader of the primary set, and replicates it to other members of the standby set. Application processes do not interact with members of the standby set.
Usage
During cut-over to the disaster recovery site, administrators redefine the primary sets, so the standby set becomes primary.
The same redefinition can facilitate migration to a new main site.
Status
In this example, the realm defines six persistence services, divided into two sets. The three services in _setA run at the main site. The three services in _setB run at the disaster recovery site.
(In an actual enterprise, each persistence service would run on a separate and distinct host computer for fault tolerance. However, in this simplified example, the servers all share a host computer.)
The two clusters of FTL servers at the primary and disaster recover sites are separate, as are the two sets of persistence services that they manage. Each FTL server cluster displays the status of only those persistence services at its local site.
Conversely, an FTL server does not receive monitoring data from the persistence services at other sites. The FTL server GUI displays the status of the remote persistence services as offline, indicating that those remote persistence services are defined in the realm, but are not client services at the local site.