Failover and Database Synchronization

When a primary system goes down and a secondary system takes over as the new primary. Un-replicated "in flight" transactions that do not appear in the new primary, may exist in the old primary. When the former primary comes up as the new secondary it will have transactions on its database that do not exist on the database of the new primary. To achieve database consistency, it must roll back the database to a synchronization point, or a transaction known to exist on the new primary. The transactions that are rolled off the former primary must be sent to the new primary for reconciliation.

To support rollback/recovery to a known synchronization point, the Source Server and the Update Process store records indicating the last point when the two systems were linked by replication, and the mode of each system (active or passive) at the time. This record provides the necessary information for a system that is starting as a secondary to find the synchronization point from the system that is operating as primary. When a system is in the primary role, it retains a record of the last database transaction sent to the secondary. When a system is in the secondary role, it retains a record of the last database transaction received from the primary. This information represents the last known point of synchronization.