Glossary

ACTIVE

On a Secondary RLINK, the ACTIVE state indicates that it is ready to receive updates from the Primary.

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.

can_sync

If the inconsistent and can_sync flags are set, there is enough information in the Secondary SRL to make it consistent again. In this case, the RLINK does not need to be fully resynchronized and is still a suitable candidate for takeover.

^ Return to Top  

cant_sync

If the RLINK flag is cant_sync, the RLINK is inconsistent and the Secondary needs a full synchronization before it can take part in replication again.

checkpoint

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

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.

CLEAN

If the Primary RVG is in the CLEAN ACTIVE state, the RLINK must be attached.

^ Return to Top  

copy-on-write

A technique for preserving the original data. Before data is modified by a write operation, the original copy of data is copied to a different location.

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 volumes

Volumes that are associated with an RVG and contain application data.

disaster recovery

Disaster Recovery (DR) has a wide scope, which ranges from the storage of backup tapes off site to the setup and maintenance of a duplicate remote standby node. VVR aids disaster recovery by providing timely replication of data to a remote site.

^ Return to Top  

distributed command

A command or task that can be performed on an RDS from any host in the RDS environment; a related task is performed in sequence on all hosts in the RDS, if appropriate.

EMPTY

If the Primary RVG state is EMPTY, an RLINK can be attached with no special options.

FAIL

A Secondary RLINK can enter the FAIL state when the Secondary data volume has an error or when an ACTIVE Secondary RLINK is paused with the -w option. A Primary RLINK enters the FAIL state when the corresponding Secondary RLINK enters the FAIL state.

failover

Failover is a term associated with the VERITAS Cluster Server environment. See Primary takeover for a description in the VVR environment.

FastResync

A feature that is used to perform quick and efficient resynchronization of stale mirrors, and to increase the efficiency of the snapshot mechanism. Also see Persistent FastResync and Non-Persistent FastResync.

^ 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.

IBC

See In-Band Control Messaging.

In-Band Control Messaging

A facility that enables applications to inject control messages in the replication stream. The contents of the control message itself are application-defined and opaque to the replication process.

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 DCM replay or a Primary checkpoint; it is cleared automatically when the DCM replay is complete 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.

^ Return to Top  

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.

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.

nmcom pool

The amount of buffer space available for updates coming in to the Secondary over the network.

^ Return to Top  

Non-Persistent FastResync

A form of FastResync that cannot preserve its maps across reboots of the system because it stores its change map in memory.

object recovery

The process of making an object usable after a system crash.

Passthru

Typically, writes to a Primary RVG are written to the SRL first, and then to the RLINKs and data volumes. If there is no SRL or the SRL is detached, writes are no longer written to the SRL and the RVG is in PASSTHRU mode. No replication takes place.

Persistent FastResync

A form of FastResync that can preserve its maps across reboots of the system by storing its change map in a DCO volume on disk.

plex

A copy of a volume and its data in the form of an ordered collection of subdisks. Each plex is a copy of the volume with which it is associated. The terms mirror and plex can be used synonymously.

^ Return to Top  

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 pause

An administrator at the Primary volume node may pause updates to any particular RLINK of an RVG. During a pause, the Primary continues to keep a history of volume updates, but active update of the RLINK ceases and the network connection between the Primary and Secondary is broken. A Primary pause is intended as a maintenance feature and allows certain configuration changes to be made, such as a change to the network connecting two nodes.

Primary migration

The Primary role of a volume can be migrated from a Primary node to a Secondary node, within certain restrictions. The process is manual and requires cooperative administrative action on the Primary and all Secondary nodes. During this process, update of the former Primary must be halted and cannot be resumed on the new Primary until the migration is complete.




The Primary role can only be migrated to an up-to-date RLINK that is consistent and is not in an error state. Any out-of-date Secondaries must be fully resynchronized with the new Primary.

Primary node

The node on which the Primary RVG resides.

Primary node crash

If a Primary node crash occurs, the Primary SRL and all data volumes in the RVG must be recovered. Both are recovered using VVR specific recovery, rather than the usual Volume Manager volume recovery.

^ Return to Top  

Primary node data volume failure

If there is an error accessing a Primary data volume, the data volume and the RVG are automatically detached, and the RVG state changes to FAIL. RLINKs are not affected. If the SRL volume was not empty at the time of the volume error, the updates continue to flow from the SRL to the Secondary RLINKs.

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.

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.

Primary SRL failure

See Passthru

Primary takeover

The Primary role can be arbitrarily taken over by a Secondary node. This process is similar to a Primary role migration but presumes that the old Primary is inoperable and unable to participate in the migration process.




Primary takeover is intended to support disaster recovery applications. Only a limited number of error scenarios prior to loss of the Primary node can prevent a takeover because they leave the RLINK in an inconsistent state. All such scenarios require the hardware failure of a data volume or SRL.

^ Return to Top  

RDS

See Replicated Data Set

readback

Volume Replicator allocates memory for application writes from the RVIO 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.

readback memory pool

The amount of buffer space available for 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

RLINKs represent 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 has a single RLINK object that links it to its Primary.

RVG

See Replicated Volume Group

RVIO memory pool

The amount of buffer space allocated within the operating system to handle incoming writes.

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

^ Return to Top  

Secondary data volume failure

Secondary data volume failure causes the RLINK to be put in the FAIL state. The Primary stops sending requests to the RLINK, but logging continues on the Primary node. When the failure has been corrected, it can be restored from a backup made earlier using a Secondary checkpoint.

Secondary pause

An administrator at the Secondary node can pause updates to the RLINK. Unlike a Primary pause, the Primary-Secondary network connection is maintained. This enables the Secondary to notify the Primary when it wants updates of the RLINK to continue. A Secondary pause can be effected even when the Primary and Secondary have lost contact.

Secondary node

The node to which the Primary data volumes are replicating.

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.

^ Return to Top  

snapshot

A point-in-time image of a volume or file system that can be used as a backup.

snapshot volume

An exact copy of a volume, at a specific point in time. The snapshot volume is created by breaking a snapshot plex from the original volume and placing it in a new volume, which is then used for online backup purposes.

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.

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.

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  

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.

unrecoverable errors

Some errors, in particular hard errors such as media failures, require manual intervention to repair. The chances of such failures can be minimized by using standard VxVM setups to maintain mirrored copies of each data volume and the SRL.

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).

write-order fidelity

A feature of VVR that applies writes on the Secondary in the same order as they are received on the Primary. This ensures that the data on the Secondary is consistent with the data on the Primary.