Replication > Replication Overview

Replication Overview

Replication provides a method for copying data from one location to another. Replication applies to the services themselves, not individual data records. The advantages of replication are two-fold:

  1. Replication provides a backup; and
  2. Replication can be used to centralize data.

Centralizing data can be especially beneficial when the data would otherwise have to be accessed from remote sites that have low-bandwidth, high-latency data links such as satellites or dial-up modems.

Keep in mind that service replication processes results in increased network traffic and system load. See Service Replication for more information.

What Data is Replicated?

Replication provides a method for copying data from one location to another. When replication is enabled, any new value (whether the value is the result of an edit, addition, or delete) is written to a change queue by the source service, which is stored in memory. Our replication model includes replication of all service data including values written to each service's change queue.

Delayed CAS alarms and GNS notifications records are replicated from a source site to a destination site. In the event of a failover these records will be available on the standby site after the failover is complete.

The following sentences should be added if these features get implemented. See the story number.

Other types of CygNet data that is replicated includes semi-static files that don't change very often, such as the CygNetTimeZones.xml file in the ARS service directory (CR-29) and the Admin.sec file in the ACS service directory (CR-28). In the past it was challenging to manage replication for these types of files because you had to manually edit these files in multiple places.

Another replicated metadata-type file that changes infrequently is the CvsMetadata.xml file (CR-30), which defines the configuration for point schemes, colors, alarm priority categories, point state definitions, status bits, and point state instances for a CygNet domain. When failover occurs from an active server to a backup server all CVS metadata settings will be in place ensuring expected behavior for your point scheme running on the backup server.

Also replicated is the queue of current value records used to calculate alarms (CR-35), which lives in the memory of the UIS and is used to calculate alarms that are only triggered if certain conditions are met over a period of time.

Another replicated item is the list of UIS executing commands triggered by an MSS (CR-41). CygNet monitors the set of commands currently executing in the UIS, and if a failover is performed, and any commands get lost, all commands will be re-executed once the UIS and MSS start back up.

Also: DB Scripts (CR-47), CygNet.lic (CR-31), pending CAS alarms (CR-36), pending GNS Notifications (CR-37), pending VHS data (CR-39), pending data forwarding queues (CR-51), CAS alarm history queue (CR-161), ARS directory services registry keys (CR-162), MSS - aborted commands on startup (CR-42), Windows Scheduled tasks (CR-149), AUD/ELS internal queues of disk writes (CR-169).

CygNet also provides a ReplValidator utility to help you compare records between source and replicated services. See ReplValidator Utility for more information.

Replication Terminology

The following terms describe the replication process for CygNet Software.

Item Description

Change queue

When replication is enabled, any new value (whether the value is the result of an edit, addition, or delete) is written to a change queue by the source service. The change queue is stored in memory. Each item in the change queue is given a unique sequence number (ID) by the source service.

The CHANGE_QUEUE_SIZE configuration keyword specifies the size of the change queue.

The CHANGE_QUEUE_NEWEST info item represents the sequence number of the last change on the change queue. The info item will return a blank if there are no entries on the change queue. This behavior matches the behavior of the value returned when asking for the last replicated sequence number, represented by the REPL_LAST_SEQ info item, which also returns blank if there are no change queue entries. These info items are used to determine the need to perform a full sync after a failover.

Change queue mapping

Each replicated service creates and stores a bidirectional change queue map, which is used to translate the sequence IDs in its own change queue with those in the change queue of its source. The last sequence number used in an incremental replication cycle is always mapped and is represented by REPL_LAST_SEQ.

The change queue maps are themselves replicated and stored alongside the change queue map of the replicated service. The mapping is persisted on shutdown and restored on startup.

Data sync

Upon start up, a replicated service performs a full data synchronization with its source. All data in the service is replicated.

Destination service

An unlimited number of replicated service destinations can be configured to pull data from the source service. Contact your Account Manager or CygNet Sales for licensing information.

Read/Write status

Replicated services are always read-only.

Replicated service

The destination service pulling data from the source service.

Replicated service name and Domain ID

The replicated service pulling the data must have the same name as the source service but must reside on a different host server, running under a different Domain ID.

Replicating service

The source service from where the data is pulled.

Replication method

A replicated service pulls data from the source service.

Resynchronization (ReSync)

If a replicated service or its source service is shut down, or the change queue rolls over, a full resynchronization of all records is performed, with one exception: the VHS never performs a full resynchronization.

Source service

The service from where replicated data is pulled. The REPL_SOURCE keyword specifies the name of the source service.

Note: For replication to function correctly, you must configure the Preferred ARS for the domain ID of the source service where replicated data is being pulled. The Preferred ARS is configured in the CygNet Domain Connection utility.


More:

Back to top

Let us know how we can improve this topic.

CygNet at weatherford.com

© 2020 Weatherford. All rights reserved.