Glossary

asynchronous

Asynchronous mode queues writes persistently and holds them at the Primary for later transmission. This mode can deal with temporary outages of the network or the Secondary node without impacting the application. Asynchronous mode is useful when it is acceptable for the Secondary not to be up to date.

Automatic Synchronization

A feature of VVR that automatically synchronizes the Secondary without interrupting the Primary.

buffer space

The memory used by VVR to process writes and perform replication.

checkpoint

A feature of VVR that synchronizes the Secondary using a block-level backup and restore method without interrupting the Primary.

^ Return to Top  

checkpoint end

Denotes the end point of the data for a Primary checkpoint. After a checkpoint attach of the RLINK, the Secondary becomes consistent when the checkpoint end is reached.

checkpoint start

Denotes the starting point of the data for a Primary checkpoint. After the checkpoint attach of the RLINK, VVR starts sending writes performed after the checkpoint start.

consistent

A flag indicating that data is recoverable by the system or application using it. For example, if the data contains a file system, the data is consistent if fsck can be run successfully on it. If the data contains a database, the data is consistent if the database recovery program can be run successfully and the database restarted.

Data Change Map (DCM)

An object containing a bitmap that can be optionally associated with a data volume on the Primary RVG. The bits represent regions of data that are different between the Primary and the Secondary.

data volume

A volume that is associated with an RVG and contains application data.

^ Return to Top  

heartbeat protocol

The heartbeat protocol ensures that the nodes in an RDS will detect any network outage or a node crash. Once the Primary detects an outage, it begins a periodic attempt to reestablish a connection which continues until successful. Upon success, replication resumes automatically unless some interim administrative command or error prevents it.

inconsistent flag

A flag used for the following conditions:




Inconsistent data on the Secondary, which indicates that the Secondary is not a viable takeover candidate.

An RLINK in the FAIL state. Either the Secondary must be restored from a checkpoint or a full resynchronization must be performed.




This flag is set during the DCM replay or a Primary checkpoint; it is cleared automatically when the DCM replay completes or the checkpoint end is reached.

latency high mark

Specifies the maximum number of waiting updates in the SRL before latency protection becomes active and writes stall or fail depending on the mode of the latency protection.

latency low mark

Specifies the number of writes in the SRL when latency protection becomes inactive and writes proceed without waiting.

latency protection

For RLINKs operating in asynchronous mode, which may fall behind, the latency protection attribute (latencyprot) of the RLINK is used to limit the maximum number of outstanding write requests. If latency protection is enabled, the maximum number of outstanding write requests cannot exceed the value set in latency_high_mark.

^ Return to Top  

latencyprot

See latency protection.

modes of replication

VVR replicates in asynchronous and synchronous modes. Each mode uses a different process to replicate data, and each deals differently with network conditions. See asynchronous and synchronous for more details.

Primary checkpoint

A method for synchronizing a Secondary with the Primary without stopping the application. A command marks the start of the checkpoint. All Primary data volumes are backed-up and then the end of the checkpoint is marked. The data is restored on the Secondary and the Primary can then begin from the start of the checkpoint. The Secondary becomes consistent when the end of the checkpoint is reached.

Primary node

The node on which the Primary RVG resides.

Primary node SRL overflow

Because the Primary SRL is finite, prolonged halts in update activity to any RLINK can exceed the SRL's ability to maintain all the necessary update history to bring an RLINK up to date. When this occurs, the RLINK is marked as STALE and requires manual recovery before replication can proceed.

^ Return to Top  

Primary Replicated Volume Group

In the VVR replication scheme, one copy of each replicated volume is designated the Primary volume, and the other copies are called Secondary volumes. Secondary volumes reside on different network hosts. Each Secondary volume group is represented on the Primary node by a single RLINK object, which serves as a proxy on the Primary node for the Secondary volume. Thus, when the Primary RVG needs to write data to a Secondary volume, it performs a write to the corresponding RLINK object. That object is then responsible for sending the request to the Secondary node. The RLINK object also provides an interface that allows for the sending of control messages to the remote RVG.

RDS

See Replicated Data Set

readback

Volume Replicator allocates memory for application writes from voliomem pool and frees the memory when the write request is written to the Primary and all Secondary data volumes. When the memory pool space becomes low, VVR frees some memory space for new write requests by postponing sending the data across asynchronous RLINKs. Later, these write requests are read back from the SRL when the RLINK is ready to send them. Such reads are called readbacks.

Replicated Data Set

The group of the RVG on a Primary and its corresponding Secondary hosts.

Replicated Volume Group

A component of VVR that is made up of a set of data volumes, one or more RLINKs, and an SRL.

^ Return to Top  

Resynchronization

The process of making the data on the Secondary identical to the data on the Primary. Resynchronization can be done without stopping the application by using a primary checkpoint or by using the Auto Synchronization feature.

RLINK

An RLINK represents the communication link to the counterpart of the RVG on another node. At the Primary node a replicated volume object has one RLINK for each of its network mirrors. On the Secondary node a Replicated Volume Group has a single RLINK object that links it to its Primary.

RVG

See Replicated Volume Group

Secondary checkpoint

A method for backing up a Secondary to allow for quick recovery in the event of a data volume failure on the Secondary.




Allows volume-level backups of the RVG to be taken at the Secondary node.

Secondary node

The node to which the Primary data volumes are replicating.

^ Return to Top  

Secondary Replicated Volume Group

See Replicated Volume Group.

Secondary SRL volume failure

Secondary SRL volume failure is not a serious error because all the data is still available on the Primary. The failure will, however, cause the RLINK to be placed in a PAUSED state, just as if a system administrator had paused the volume.

SRL

See Storage Replicator Log.

SRL overflow protection

For RLINKs with latency protection disabled, a final degree of protection is provided by SRL overflow protection (srlprot). When SRL overflow protection is enabled, the RLINK is protected from having so many outstanding write requests that it would overflow its SRL and require a full resynchronization.

STALE

If an RLINK is STALE, the corresponding Secondary requires a full resynchronization to make it usable. RLINKS can enter the STALE state when they are detached manually by issuing the vxrlink det command or as a result of a Primary failure. In addition, when an RLINK is associated for the first time, its state changes from UNASSOC to STALE.

^ Return to Top  

Storage Replicator Log (SRL)

Writes to the Primary RVG are saved in an SRL on the Primary side. The SRL is used to aid in error recovery, as well as to buffer writes when the system operates in asynchronous mode. Each write to a data volume in the RVG generates two write requests: one to the Secondary SRL and another to the Primary SRL.

synchronous

In synchronous mode, the Secondary is kept up to date with the Primary by waiting for each write request to reach the Secondary before the application sees the successful completion of the write on the Primary.

throttling

A mechanism that delays incoming writes.

update

Data from the Primary corresponding to the application writes sent to the Secondary for replicating the writes is referred to as an update.

Volume Replicator Objects

The objects used for replication such as Replicated Volume Group, Storage Replicator Log (SRL), RLINK, and Data Change Map (DCM).