Synchronizing the Secondary and Starting Replication

This section explains how to synchronize the Secondary and start replication.

Methods to Synchronize the Secondary

You can synchronize the Secondary using the network, using block-level tape backup or by physically moving disks to the Secondary. Use one of the following methods to synchronize the Secondary depending on your environment:

• Using the network
• Automatic synchronization
• Full synchronization with checkpoint
• Difference-based synchronization with checkpoint
• Using block-level tape backup
• Block-level tape backup and checkpointing
• Moving disks physically
• Disk Group Split and Join

The following tables explain when and how to use the different synchronization methods:

Using the Network

You can synchronize the Secondary over the network either when the application is active or inactive.

Using Block-level Tape Backup

Moving Disks Physically

Using the Automatic Synchronization Feature

The Automatic Synchronization feature enables you to transfer the data on the Primary to the Secondary over the network. You can synchronize the Secondary using automatic synchronization either when the application is active or inactive.

The Automatic Synchronization procedure transfers data in the Primary data volumes to the Secondary by reading the Primary data volumes from start to finish and sending the data to the Secondary.

The Secondary becomes consistent after the automatic synchronization completes. To use Automatic Synchronization successfully, the network must be sized appropriately. Note that the synchronization will complete only if the Primary receives writes at a lesser rate than they can be sent to the Secondary. If the Primary receives writes at a faster rate than they can be sent to the Secondary, the synchronization might never complete, especially if the writes are dispersed widely in the volume.

This feature enables you to synchronize multiple Secondary hosts at the same time. When performing automatic synchronization to multiple Secondary hosts, synchronization proceeds at the rate of the slowest network.

VVR pauses synchronization if the Secondary fails or the network disconnects. If the Primary fails while synchronization is in progress, the synchronization continues from the point at which it had stopped when the Primary recovers.

Prerequisite for using Automatic Synchronization

• Each data volume in the Primary RVG must have a DCM associated to it. If data volumes do not have DCMs, an attempt to automatically synchronize a Secondary fails.

The vradmin startrep command when used with the option -a enables you to start replication and automatically synchronize the Secondary data volumes with the Primary data volumes in an RDS; it brings the Secondary data volumes up-to-date with the Primary data volumes. You can use this command to synchronize the Secondary when the data volumes contain data and when the application is active or inactive. Replication to another Secondary can be started only after this automatic synchronization completes.

The vradmin startrep command can be issued from any host in the RDS. To check the status and progress of the automatic synchronization, use the vxrlink status command on the Primary RLINK. For more information, see Displaying the Status of a Secondary.

To synchronize the Secondary and start replication using automatic synchronization, issue the following command:

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

The argument sec_hostname is the name of the Secondary host displayed in the output of the vradmin printrvg command. If the RDS contains only one Secondary, the sec_hostname is optional.

Example---Using the Automatic Synchronization Feature

In this example, the data volumes in the Primary RVG hr_rvg on host seattle contain valid data and the application is active. To start replication and synchronize the Secondary RVG hr_rvg on host london, issue the following command:

Notes on Using Automatic Synchronization

• If you associate a new volume to an RDS while automatic synchronization is in progress, VVR does not automatically synchronize the newly associated data volume.
• In an RDS containing multiple Secondaries that have SRL overflow protection set to dcm, more than one Secondary may require the use of the DCM. If one Secondary is undergoing automatic synchronization and the RLINK of another Secondary is about to overflow, the Automatic Synchronization is abandoned and the DCM becomes active for the overflowing RLINK.
• If you try to automatically synchronize a new RLINK while an existing RLINK is using the DCM mechanism, the automatic synchronization fails.
• 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 the RLINKs that are being synchronized are detached.

Using the Full Synchronization Feature

This section explains how to use the Full Synchronization feature of VVR to synchronize the Secondary completely and start replication. Full synchronization compresses zeroes while processing the data and hence proves beneficial when a large part of the Primary data volumes contain zeroes. However, we recommend that you use Automatic Synchronization to synchronize the Secondary because its performance is better than Full Synchronization. Automatic Synchronization also handles network outages efficiently and continues even after the system reboots.

Full synchronization synchronizes the Secondary over the network when the Primary data volumes contain data and when the application is active or inactive. After the Primary and Secondary are synchronized, replication must be started.

By default, the vradmin syncrvg command synchronizes Secondary data volumes using difference-based synchronization. To perform a full synchronization, specify the -full option.

We recommend that you always use the -c option with the vradmin syncrvg command to synchronize the Secondary using full synchronization. The -c checkpoint option starts a checkpoint, synchronizes the data volumes, and ends the checkpoint after the synchronization completes. After the vradmin syncrvg command completes, use this checkpoint with the vradmin startrep command to start replication. To delete the Primary checkpoints, use the vxrvg checkdelete command.

The SRL must be large enough to hold the incoming updates to the Primary data volumes while the synchronization is in progress. The SRL might fill up and the checkpoint might overflow if the number of writes to the Primary data volumes is high when the Secondary is being synchronized.

A checkpoint that has overflowed becomes invalid and cannot be used to start replication. If the checkpoint overflows while synchronization is in progress, the vradmin syncrvg command must be issued again.

The vradmin syncrvg command can be used to synchronize multiple Secondaries at the same time. The vradmin syncrvg command displays the progress of the synchronization.

  To synchronize the Secondary RVG with the Primary RVG using full synchronization with checkpoint

1. Verify that the RLINKs are detached to ensure that replication is stopped.
2. To synchronize the Secondary RVG, issue the following command:
     # vradmin -g diskgroup -full -c checkpt_name syncrvg \ 
       local_rvgname sec_hostname....

   Note that you can use the -c option with the vradmin syncrvg command when performing full synchronization, to automatically start a checkpoint with the specified name. After the data volumes are synchronized the checkpoint is ended. This checkpoint can then be used to start replication using the vradmin startrep command.

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

   The argument sec_hostname... is a space-separated list of the names of the Secondary hosts as displayed in the output of the vradmin printrvg command.

   The argument checkpt_name specifies the name of the Primary checkpoint of your choice.

3. After the synchronization completes, start replication to the Secondary with the checkpoint:
   # vradmin -g diskgroup -c checkpt_name startrep local_rvgname \
   sec_hostname

   After the RLINKs are attached, the Secondary remains inconsistent until it has received all of the accumulated updates up to the checkend. While the Secondary is inconsistent, the inconsistent flag is set on the Secondary RLINK. After all updates up to the checkend have been received and applied at the Secondary, the inconsistent flag is cleared.

   To view the status of synchronization, see Displaying the Status of a Secondary.

Example---Synchronizing the Secondary Using Full Synchronization with Checkpoint

This example explains how to synchronize the Secondary RVG hr_rvg on the Secondary host london with the Primary RVG on host seattle.

  To synchronize the Secondary RVG hr_rvg on london with its Primary RVG on seattle using full synchronization

1. Verify that the RLINKs are detached to ensure that replication is stopped.
2. Issue the following command from any host in the RDS:
     # vradmin -g hrdg -full -c checkpt_presync syncrvg hr_rvg london

   Note that you can use the -c option with the vradmin syncrvg command when performing full synchronization, to automatically start a checkpoint with the specified name. After the data volumes are synchronized the checkpoint is ended. This checkpoint can then be used to start replication using the vradmin startrep command.

   The name checkpt_presync is the Primary checkpoint that you will create.

3. After the synchronization is complete, issue the following command to start replication using the checkpoint:
   # vradmin -g hrdg -c checkpt_presync startrep hr_rvg london

Using Block-level Backup and Checkpoint

This method is useful for low bandwidth networks or very large data sets. You can use the block-level backup and checkpoint method to synchronize the Secondary when a backup of the data is available and a checkpoint has been started on the Primary. You do not have to use the network to transfer the data. This method does have a risk of SRL overflow.

Make sure that the SRL is large enough to contain all the writes made by the application while synchronization is in progress. For instructions on how to resize the SRL, see Resizing the SRL.

For detailed instructions, see Example---Synchronizing the Secondary Using Block-level Backup.

  To synchronize the Secondary using backup and Primary checkpoint

1. Start a Primary checkpoint using the vxrvg checkstart command:
     # vxrvg -g diskgroup -c checkpt_name checkstart local_rvgname
2. Perform a block-level backup of the data volumes in the Primary RVG.
3. End the checkpoint in the SRL when the backup is complete by using the vxrvg checkend command:
     # vxrvg -g diskgroup checkend local_rvgname
4. Restore the backup to the Secondary data volumes.
5. Start replication using the checkpoint after the restore on the Secondary completes:
     # vradmin -g diskgroup -c checkpt_name startrep local_rvgname \
          sec_hostname

   After the RLINKs are attached, the Secondary remains inconsistent until it has received all of the accumulated updates up to the checkend. While the Secondary is inconsistent, the inconsistent flag is set on the Secondary RLINK. After all updates up to the checkend have been received and applied at the Secondary, the inconsistent flag is cleared.

Example---Synchronizing the Secondary Using Block-level Backup

This example explains how to synchronize the Secondary RVG hr_rvg on the Secondary host london with the Primary RVG on host seattle using block-level backup and checkpoint.

1. Start a Primary checkpoint on seattle:
     # vxrvg -g hrdg -c checkpt_presync checkstart hr_rvg
2. Perform a block-level backup of the data volumes in the Primary RVG.
3. End the Primary checkpoint when the backup is complete:
     # vxrvg -g hrdg checkend hr_rvg
4. Restore the backup to the Secondary data volumes.
5. Start replication using the checkpoint after the restore is complete:
     # vradmin -g hrdg -c checkpt_presync startrep hr_rvg london

Using the Disk Group Split and Join Feature

The Disk Group Split and Join feature of VERITAS Volume Manager enables you to synchronize the Secondary. For more information on the Disk Group Split and Join feature, refer to the VERITAS Volume Manager Administrator's Guide. To set up replication using this method, ensure that you have a valid Disk Group Split and Join license on your system. For detailed instructions, see Example 4---Setting Up Replication Using Disk Group Split and Join.

  To synchronize the Secondary using Disk Group Split and Join

Perform the following steps on the Primary:

1. Create a snapshot plex for each data volume in the Primary RVG by issuing the following command on the Primary:
     # vxassist -g diskgroup snapstart dv_name

   You can use the -b option with the vxassist snapstart command to run the command in the background. Note that if you use the -b option of the vxassist snapstart command, you must wait for the snapshot plexes for all the data volumes in the RVG to be created and synchronized completely before you proceed to the next step. When the plex synchronization completes, the output of the vxprint command displays the state of the new snapshot plex as snapdone.

2. Start a Primary checkpoint by issuing the following command on the Primary:
     # vxrvg -g diskgroup -c checkpt_name checkstart local_rvgname
3. Take a snapshot of each data volume in the Primary RVG by issuing the following command on the Primary:
     # vxrvg -g diskgroup snapshot local_rvgname
4. End the checkpoint by issuing the following command on the Primary:
     # vxrvg -g diskgroup checkend local_rvgname
5. Split the snapshot volumes into a new disk group by issuing the following command on the Primary:
     # vxdg split diskgroup new_diskgroup SNAP-dv_name ...
6. Rename each snapshot volume in the new disk group with the same name as the corresponding data volume in the Primary RVG by issuing the following command on the Primary:
     # vxedit -g new_diskgroup rename SNAP-dv_name dv_name
7. Deport the split-off disk group, rename it to the same name as the disk group of the Primary RVG, and change the ownership of the split-off disk group to the Secondary host so that it may be automatically imported on the Secondary on reboot.
     # vxdg -n diskgroup -h sec_hostname deport new_diskgroup

   The argument sec_hostname is the name of the Secondary host displayed in the output of the uname command.

8. Physically remove the disks contained in the deported disk group by following the procedures recommended by the disk manufacturer; then attach the disks to the Secondary host.
9. On the Secondary, import the disks that were moved over from the Primary if not already imported:
     # vxdg import diskgroup
10. Add the Secondary to the RDS by issuing the following command on the Primary:
      # vradmin -g diskgroup addsec local_rvgname pri_hostname    \ 
         sec_hostname
11. Start replication by issuing the following command from any host in the RDS:
      # vradmin -g diskgroup -c checkpt_name startrep local_rvgname  \
          sec_hostname

    The argument sec_hostname is the name of the Secondary host displayed in the output of the vradmin printrvg command. If the RDS contains only one Secondary, the sec_hostname is optional.

Using Difference-Based Synchronization

You can synchronize the Secondary using difference-based synchronization when there is little difference between the Primary and Secondary data volumes in an RDS. Difference-based synchronization can be used to transfer data over the network when the application is active or inactive.

In difference-based synchronization, the syncrvg command generates MD5 checksums for the data blocks on the Primary data volume and the corresponding Secondary data volume and compares these checksums. The syncrvg command then transfers over the network only those blocks for which checksums do not match. These steps are repeated for the entire Primary data volume and Secondary data volume.

MD5 checksum is generated using the RSA Data Security, Inc. MD5 Message-Digest Algorithm.

Difference-based synchronization is useful in situations such as:

• Storage Replicator Log (SRL) Overflow--- To synchronize the Secondary when the SRL protection has not been set to use the Data Change Map (DCM).
• Failing Back to the Original Primary---To synchronize the original Primary data volumes with the new Primary data volumes.

The vradmin syncrvg command enables you to synchronize the Secondary RVG with the Primary RVG based on differences. You can issue the vradmin syncrvg command from any host in the RDS. The vradmin syncrvg command synchronizes the data volumes associated with the Secondary RVG in an RDS with the corresponding data volumes associated with its Primary RVG. The vradmin syncrvg command can be used to synchronize multiple Secondaries at the same time.

  To synchronize Secondary RVG with Primary RVG based on differences

Before issuing this command, verify that the RLINKs are detached. Use the
-c checkpoint option with the vradmin syncrvg command as follows:

Note that you can use the -c option with the vradmin syncrvg command when performing difference-based synchronization, to automatically start a checkpoint with the specified name. After the data volumes are synchronized the checkpoint is ended. This checkpoint can then be used to start replication using the vradmin startrep command.

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

The argument sec_hostname is a space-separated list of the names of the Secondary hosts as displayed in the output of the vradmin printrvg command.

The argument checkpt_name specifies the name of the Primary checkpoint of your choice.

Example---Synchronizing the Secondary Based on Differences

This example explains how to synchronize the Secondary RVG hr_rvg on the Secondary host london with the Primary RVG on host seattle.

  To synchronize the Secondary RVG, hr_rvg, on london with its Primary RVG on seattle based on differences

Before issuing this command, make sure that the RLINKs are detached.

Note that you can use the -c option with the vradmin syncrvg command when performing difference-based synchronization to automatically start a checkpoint with the specified name. After the data volumes are synchronized the checkpoint is ended. This checkpoint can then be used to start replication using the vradmin startrep command.

The name checkpt_presync is the Primary checkpoint that you will create.