Administering the SRL

The size of the SRL is critical to the performance of replication. When the SRL overflows for a particular Secondary, the Secondary becomes out of date until a complete resynchronization with the Primary is performed. Because resynchronization is a time-consuming process and during this time the data on the Secondary cannot be used, it is important to prevent the SRL from overflowing. Hence, when initially configuring VVR, determine an appropriate size for the SRL. The maximum size of the SRL can be derived from various criteria, however, the size of the SRL volume cannot be less than
110 MB. If the size that you have specified for the SRL is less than 110MB, VVR displays a message that prompts you to specify a value that is equal to or greater than 110 MB. For more information, refer to "Sizing the SRL" in the VERITAS Volume Replicator Planning and Tuning Guide.

It is possible that an SRL of an appropriate size overflows because of changes in the environment. This section describes how to protect from SRL overflows and administer VVR if the SRL overflows.

Protecting from SRL Overflow

To avoid complete synchronization of Secondary in the case of an SRL overflow, VVR provides autodcm or dcm mode of SRL protection. For more information, see Protection Against SRL Overflow---srlprot attribute.

To enable SRL protection, each data volume in the RDS must have an associated DCM. For more information, section Associating the Component Volumes of a Volume Set to an RDS. To change the replication setting for SRL protection, see Changing the Replication Settings for a Secondary.

Incrementally Synchronizing the Secondary After SRL Overflow

The default protection mode for the SRL is autodcm and every volume in the RVG must have a DCM. When the SRL fills up, whether the RLINK is connected or not, DCM logging is activated and a bit corresponding to the region of the update is turned on for every incoming update. When you are ready to replay the DCM, start the DCM resynchronization process. To start the resynchronization, use the command
vradmin resync. Note that you can also use the cache or cachesize parameters with the vradmin resync command. Specifying these attributes will cause the command to first create a space-optimized snapshot of the Secondary data volumes before starting the resynchronization. If the RVG on the Secondary has VxVM ISP volumes, then you cannot use the cachesize attribute. Data is transmitted to the Secondaries only after all the RLINKs taking part in the resynchronization have connected. All the Secondaries taking part in the resynchronization must remain connected for the resynchronization to continue. The resynchronization will pause if any of the Secondary RLINK is paused.

During DCM resynchronization, VVR does not maintain the order of updates to the Secondary. As a result, the Secondary remains inconsistent until the resynchronization operation is complete. Note that if the Primary becomes unavailable during the time the resynchronization is taking place, the applications cannot be restarted on the Secondary.

If the Secondary volumes are mirrored, you can break off mirrors to retain consistent (though out-of-date) copies of data until the resynchronization is complete. However, to overcome this problem, create snapshots of the Secondary volumes before the resynchronization starts by using the following commands:

1. Create the cache object for the data volumes. For more information, refer to the section Preparing the RVG Volumes for Snapshot Operation. This step is optional if you plan to use the cachesize attribute with vradmin resync command.
2. To start the resynchronization use the command:
   # vradmin -g diskgroup [-wait] resync local_rvgname \
   [cache=cacheobj | cachesize=size]

   The cache attribute specifies a name for the precreated cache object, on which the snapshots for the volumes in the specified RVG will be created. The cachesize attribute specifies a default size for the cache object with respect to the source volume. You can specify only one of these attributes at one time with the vradmin resync to create one cache object for each snapshot

   The parameters cache and cachesize are optional. If you do not specify either of these parameters then the vradmin resync command will resynchronize the Secondary volumes using the DCM replay, without creating the snapshots.

   The -wait option can be used with the vradmin resync command to wait for the synchronization process to complete.

SRL Overflow Protection With DCM---Flags and Definitions

If the SRL Overflow Protection With DCM feature has been activated, VVR sets the following flag on the corresponding RLINK and its RVG:

If the dcm_logging flag is set on an RLINK or RVG and neither the resync_started nor the resync_paused flag is set, the resynchronization (resync) has not been started. After the vradmin resync command has been issued, one or both of the following flags are set:

Prerequisite for incrementally resynchronizing the Secondary

  The RVG must have the dcm_logging flag set.

  To incrementally resynchronize the Secondary

The argument local_rvgname is the name of the RVG on the local host and represents its RDS.

Example:

  To determine the progress of the incremental synchronization

Determine the progress of the incremental synchronization after SRL overflow by issuing the following command on the Primary host:

The argument rlink_name is the name of the Primary RLINK to the Secondary.

The output shows how much data is left to send. To monitor the progress, issue the
vxrlink -i interval status rlink_name command. For example, to see the status every 5 seconds, issue the following command:

The output resembles:

Breaking Off Mirrors Before Incremental Synchronization

During DCM resynchronization, the data volumes on the Secondary are inconsistent and cannot be used to take over the Primary role. To maintain a consistent copy of the data volumes on the Secondary, break off a mirror from each data volume before starting DCM resynchronization. In the case of a disaster, these mirrors can be used to take over the Primary role. If you have FastResync license, make sure FR is set for all the volumes.

When snapshot plexes are available:

To find out if snapshot plexes are available on a data volume, use the vxprint command. The output shows the state of the plex as SNAPDONE. If a snapshot plex is available for each data volume, use the vxrvg snapshot command to take a snapshot of the data volumes in an RVG. If required, the snapshot volumes can be used to take over the Primary role. After the DCM resynchronization is complete, reattach the snapshot plexes back to the original volume using the vxrvg snapback command.

When snapshot plexes are not available:

If snapshot plexes are not available, detach mirrors on each of the data volumes on the Secondary using the vxplex command. After the DCM resynchronization is complete, reattach the plexes using the vxplex att command. To use the data on a detached plex in situations such as takeover, you must create a volume for the detached plex when snapshot plexes are not available.

Example 1---When snapshot plexes are not available

This example explains how to break off a mirror from a data volume and reattach a plex after the DCM resynchronization is complete. This example uses the volume hr_dv01 that has two plexes hr_dv01_01and hr_dv01_02.

1. On the Secondary, detach a plex from the data volume by typing:
     # vxplex -g hrdg det hr_dv01_02
2. When the RLINK reconnects, incrementally synchronize the Secondary by typing:
     # vradmin -g hrdg resync hr_rvg

   For multiple Secondary hosts, VVR simultaneously synchronizes all Secondary hosts that are operating in dcm logging mode.

3. After the DCM resynchronization is complete, reattach the plex to the data volume on the Secondary by typing:
     # vxplex -g hrdg att hr_dv01 hr_dv01_02

Example 2---When snapshot plexes are not available and a disaster occurs

If during the resynchronization process, a disaster occurs and the Secondary takes over, you can recreate the volumes as they were before the resynchronization started. The example uses the RVG hr_rvg and the volume hr_dv01 as in Example 1---When snapshot plexes are not available. All steps are performed on the former Secondary, which is now the Primary (to take over the Primary role, see Taking Over from an Original Primary).

1. Detach the Secondary RLINK.
     # vxrlink -g hrdg det rsec
2. Dissociate the original data volume from the Secondary RVG.
     # vxvol -g hrdg dis hr_dv01
3. Remove the original data volume.
     # vxedit -g hrdg -rf rm hr_dv01 
4. Create the volume for the detached plex by typing:
     # vxmake -g hrdg -U usetype vol hr_dv01 plex=hr_dv01_02

   If a volume contains a file system, specify the usetype as fsgen; otherwise, specify gen.

5. Start the data volume by typing:
     # vxvol -g hrdg -f start hr_dv01
6. Associate the data volume to its RVG.
     # vxvol -g hrdg assoc hr_rvg hr_dv01
7. The volume is no longer mirrored. To add mirrors, issue the following command:
     # vxassist -g hrdg mirror hr_dv01

Notes on using Incremental Synchronization on SRL Overflow

• Each data volume in the Primary RVG must have a DCM associated with it. You cannot use the SRL Overflow Protection With DCM feature unless every data volume in the RVG has a DCM. If any of the data volumes in the RVG do not a have a DCM, you cannot set srlprot=dcm or srlprot=autodcm. An attempt to associate a volume without a DCM to an RVG that has an RLINK with srlprot=dcm or srlprot=autodcm will also fail.
• If an RLINK is undergoing Automatic Synchronization and an attached RLINK with SRL Overflow Protection With DCM is about to overflow, the Automatic Synchronization is abandoned and SRL Overflow Protection With DCM for the overflowing RLINK becomes active.
• If an existing RLINK is using the DCM mechanism and another existing RLINK is about to overflow, the second RLINK is detached unless the DCM resynchronization for the first RLINK has not yet sent any writes. In this case, the outstanding writes of the first RLINK are also sent on the second RLINK.
• To remove a Secondary from a DCM resynchronization process, detach the corresponding Primary RLINK.
• If you try to dissociate a DCM from a data volume while the DCM is in use, the operation fails.
• If the DCM is detached because of I/O errors while the DCM is in use, the resynchronization is abandoned and all the RLINKs that are being synchronized are detached.

Resizing the SRL

The size of the SRL must be large enough to meet the constraints explained in the section "Sizing the SRL" in the VERITAS Volume Replicator Planning and Tuning Guide. These constraints can change with the changes in the business needs, application write rate, available network bandwidth, and so on. As a result, it is necessary to determine the appropriate size of the SRL again. This section includes the following tasks:

  Increasing the Size of the SRL on the Primary

  Decreasing the Size of the SRL on the Primary

  Resizing the SRL on the Secondary

Increasing the Size of the SRL on the Primary

VVR enables you to increase the size of the Primary SRL in a Replicated Data Set (RDS) using the vradmin resizesrl command, even while the application is active or while replication is in progress. The vradmin resizesrl command does not increase the size of the Secondary SRL.

Before increasing the size of the Primary SRL, do the following:

  Check whether there is enough free space in the disk group in which the SRL resides by issuing the following command:


#  vxdg -g diskgroup free 

  To increase the size of the SRL on the Primary

Issue the following command on the Primary:

The argument local_rvgname is the name of the RVG on the local host and represents its RDS.

The argument length is the desired size for the Primary SRL. The length can be specified using the standard VxVM conventions. It can be prefixed by a plus sign (+) to indicate an increase in the size of the Primary SRL by the specified amount.

Decreasing the Size of the SRL on the Primary

For instructions on decreasing the size of the SRL on the Primary, see Decreasing the Size of the SRL on the Primary.

Resizing the SRL on the Secondary

Note that you do not have to stop the applications while resizing the Secondary SRL.

  To resize the SRL on the Secondary

1. Detach the RLINK:
   #  vxrlink -g diskgroup det rlink_name
2. Dissociate the SRL from the RVG.

   ---

     Note    Any checkpoints that you have created will be lost after dissociating the SRL.

   ---

   
   #  vxvol -g diskgroup dis srl_name
3. Resize the SRL using the vxassist command. For example, to increase the size of the SRL:
   #  vxassist -g diskgroup growto srl_name new_length

   ---

     Note    We recommend that the SRL reside on disks that are not being used for the data volumes. We also recommend that the Primary and the Secondary SRLs be the same size. See the vxassist(1M) manual page for more information.

   ---

4. Reassociate the SRL with the RVG:
   #  vxvol -g diskgroup aslog rvg_name srl_name
5. Attach the RLINK:
   #  vxrlink -g diskgroup att rlink_name