Implementing Off-Host Processing Solutions

By importing snapshot volumes on a lightly loaded host, CPU- and I/O-intensive operations for online backup and decision support do not degrade the performance of the primary host that is performing the main production activity (such as running a database). If the snapshot volumes are configured on disks that are attached to different host controllers than the disks in the primary volumes, it is possible to avoid contending with the primary host for I/O resources.

The following sections describe how you can apply off-host processing to implement regular online backup of a volume in a private disk group, and to set up a replica of a production database for decision support. Two applications are outlined in the following sections:

• Implementing Off-Host Online Backup
• Implementing Decision Support

These applications use the Persistent FastResync and disk group move, split and join features of VxVM in conjunction with full-sized instant volume snapshots. It is assumed that you have configured a data storage pool containing the application volumes, and a clone storage pool containing prepared empty volumes for any snapshots. You must also have associated a data change object (DCO) and DCO volume with all these volumes.

Implementing Off-Host Online Backup

This section describes a procedure for implementing off-host online backup for a volume in a private disk group. The intention is to present an outline of how to set up a regular backup cycle by combining the Persistent FastResync and disk group split and join features of VxVM. It is beyond the scope of this guide to describe how to configure a database to use this procedure, or how to perform the backup itself.

To back up a volume in a private disk group, use the following procedure.

1. Create a full-sized instant snapshot volume, snapvol, using the following command on the primary host:
   # vxsnap -g volumedg make source=volume/snapvol=snapvol

   This command uses the specified prepared snapshot volume, snapvol, to form the snapshot volume. (See Creating a Volume for Use as a Full-Sized Instant Snapshot for details.)

   If a database spans more than one volume, you can specify all the volumes and their snapshot volumes using one command, as shown in this example:

   
   # vxsnap -g dbasedg make source=vol1/snapvol=snapvol1 \
     source=vol2/snapvol=snapvol2 \
     source=vol3/snapvol=snapvol3

   ---

     Note    This step sets up the snapshot volumes ready for the backup cycle, and starts tracking changes to the original volumes. When you are ready to make a backup, proceed to step 2.

   ---

2. On the primary host, suspend updates to the volume that contains the database tables. The database may have a hot backup mode that allows you to do this by temporarily suspending writes to its tables.
3. On the primary host, refresh the plexes of the snapshot volume using the following command:
   # vxsnap [-g diskgroup] refresh snapvol source=volume sync=yes

   For a database, multiple snapshots can be refreshed in parallel, as shown in this example:

   
   # vxsnap -g dbasedg refresh snapvol1 source=vol1 snapvol2 \
     source=vol2 snapvol3 source=vol3 sync=yes
4. On the primary host, if you temporarily suspended updates to the volume by a database in step 2, release all the tables from hot backup mode.
5. The snapshot volume must be completely synchronized before you can move it into another disk group. You can use the vxsnap syncwait command to wait for the synchronization to complete as shown here:
   # vxsnap -g volumedg syncwait snapvol

   The vxsnap syncwait command exits with an exit code of zero when the snapshot volume has been synchronized with the parent volume.

   If required, you can use the following command to verify whether the V_PFLAG_INCOMPLETE flag is set on a volume:

   
   # vxprint [-g diskgroup] -F%incomplete snapvol

   This command returns the value off if synchronization of the volume, snapvol, is complete; otherwise, it returns the value on.

6. On the primary host, use the following command to split the clone storage pool containing the snapshot volume into a separate disk group, snapvoldg, from the original disk group, volumedg:
   # vxdg split volumedg snapvoldg clonepool
7. On the primary host, deport the snapshot volume's disk group using the following command:
   # vxdg deport snapvoldg
8. On the OHP host where the backup is to be performed, use the following command to import the snapshot volume's disk group:
   # vxdg import snapvoldg
9. The snapshot volume is initially disabled following the split. Use the following commands on the OHP host to recover and restart the snapshot volume:
   # vxrecover -g snapvoldg -m snapvol
   # vxvol -g snapvoldg start snapvol
10. On the OHP host, back up the snapshot volume. If you need to remount the file system in the volume to back it up, first run fsck on the volume. The following are sample commands for checking and mounting a file system:
    # fsck -F vxfs /dev/vx/rdsk/snapvoldg/snapvol
    # mount -F vxfs /dev/vx/dsk/snapvoldg/snapvol mount_point

    Back up the file system at this point, and then use the following command to unmount it.

    
    # umount mount_point
11. On the OHP host, use the following command to deport the snapshot volume's disk group:
    # vxdg deport snapvoldg
12. On the primary host, re-import the snapshot volume's disk group using the following command:
    # vxdg import snapvoldg
13. On the primary host, use the following command to rejoin the snapshot volume's disk group with the original volume's disk group:
    # vxdg join snapvoldg volumedg
14. The snapshot volume is initially disabled following the join. Use the following commands on the primary host to recover and restart the snapshot volume:
    # vxrecover -g volumedg -m snapvol
    # vxvol -g volumedg start snapvol

    The contents of the snapshot volume are now ready to be refreshed.

Repeat steps 2 through 14 each time that you need to back up the volume.

Implementing Decision Support

This section describes a procedure for implementing off-host decision support for a volume in a private disk group. The intention is to present an outline of how to set up a replica database by combining the Persistent FastResync and disk group split and join features of VxVM. It is beyond the scope of this guide to describe how to configure a database to use this procedure.

To set up a replica database using the table files that are configured within a volume in a private disk group, use the following procedure.

1. Prepare the OHP host to receive the snapshot volume that contains the copy of the database tables. This may involve setting up private volumes to contain any redo logs, and configuring any files that are used to initialize the database.
2. Create a full-sized instant snapshot volume, snapvol, using the following command on the primary host:
   # vxsnap -g volumedg make source=volume/snapvol=snapvol

   This command uses the specified prepared snapshot volume, snapvol, to form the snapshot volume. (See Creating a Volume for Use as a Full-Sized Instant Snapshot for details.)

   If a database spans more than one volume, you can specify all the volumes and their snapshot volumes using one command, as shown in this example:

   
   # vxsnap -g dbasedg make source=vol1/snapvol=snapvol1 \
     source=vol2/snapvol=snapvol2 \
     source=vol3/snapvol=snapvol3

   ---

     Note    This step sets up the snapshot volumes, and starts tracking changes to the original volumes. When you are ready to create a replica database, proceed to step 3.

   ---

3. On the primary host, suspend updates to the volume that contains the database tables. The database may have a hot backup mode that allows you to do this by temporarily suspending writes to its tables.
4. On the primary host, refresh the plexes of the snapshot volume using the following command:
   # vxsnap [-g diskgroup] refresh snapvol source=volume sync=yes

   The sync=yes attribute starts a synchronization of the snapshot in the background.

   For a database, multiple snapshots can be refreshed in parallel, as shown in this example:

   
   # vxsnap -g dbasedg refresh snapvol1 source=vol1 snapvol2 \
     source=vol2 snapvol3 source=vol3 sync=yes
5. On the primary host, if you temporarily suspended updates to the volume by a database in step 3, release all the tables from hot backup mode.
6. The snapshot volume must be completely synchronized before you can move it into another disk group. You can use the vxsnap syncwait command to wait for the synchronization to complete as shown here:
   # vxsnap -g volumedg syncwait snapvol

   The vxsnap syncwait command exits with an exit code of zero when the snapshot volume has been synchronized with the parent volume.

   If required, you can use the following command to verify whether the V_PFLAG_INCOMPLETE flag is set on a volume:

   
   # vxprint [-g diskgroup] -F%incomplete snapvol

   This command returns the value off if synchronization of the volume, snapvol, is complete; otherwise, it returns the value on.

7. On the primary host, use the following command to split the clone storage pool containing the snapshot volume into a separate disk group, snapvoldg, from the original disk group, volumedg:
   # vxdg split volumedg snapvoldg clonepool
8. On the primary host, deport the snapshot volume's disk group using the following command:
   # vxdg deport snapvoldg
9. On the OHP host where the replica database is to be set up, use the following command to import the snapshot volume's disk group:
   # vxdg import snapvoldg
10. The snapshot volume is initially disabled following the split. Use the following commands on the OHP host to recover and restart the snapshot volume:
    # vxrecover -g snapvoldg -m snapvol
    # vxvol -g snapvoldg start snapvol
11. On the OHP host, check and mount the snapshot volume. The following are sample commands for checking and mounting a file system:
    # fsck -F vxfs /dev/vx/rdsk/snapvoldg/snapvol
    # mount -F vxfs /dev/vx/dsk/snapvoldg/snapvol mount_point
12. On the OHP host, use the appropriate database commands to recover and start the replica database for its decision support role.

When you want to resynchronize the snapshot volume' s data with the primary database, you can refresh the snapshot plexes from the original volume as described below:

1. On the OHP host, shut down the replica database, and use the following command to unmount the snapshot volume:
   # umount mount_point
2. On the OHP host, use the following command to deport the snapshot volume's disk group:
   # vxdg deport snapvoldg
3. On the primary host, re-import the snapshot volume's disk group using the following command:
   # vxdg import snapvoldg
4. On the primary host, use the following command to rejoin the snapshot volume's disk group with the original volume's disk group:
   # vxdg join snapvoldg volumedg
5. The snapshot volume is initially disabled following the join. Use the following commands on the primary host to recover and restart the snapshot volume:
   # vxrecover -g volumedg -m snapvol
   # vxvol -g volumedg start snapvol

   The contents of the snapshot volume are now ready to be refreshed.

You can then resume the procedure from step 3. The snapshot volume can be split from the disk group when synchronization is again complete.