This example assumes that the RDS has been created using the procedure Creating a Replicated Data Set for the examples. You can synchronize the Secondary using block-level backup and checkpointing when the application is active or inactive.
vxrvg -g hrdg -c
Note down the checkpoint name you use, that is,
vxrvg -g hrdg
cplistcommand on the Primary to check whether the checkpoint you created is still valid. If the checkpoint has overflowed, repeat step 1 to step 4.
The output resembles:
Name MBytes % Log Started/Completed
checkpt_presync 10 9 Completed
vradmin -g hrdg
startrep hr_rvg london
consistentflag is set on the Primary RLINK using the
vxprintcommand. The RLINK becomes
consistentonly after the data contained in the checkpoint is sent to the Secondary. Wait and then issue the following command on the Primary:
vxprint -g hrdg -l rlk_london_hr_rvg
If the Secondary is consistent, the synchronization was successful.
If the checkpoint overflows before the Secondary becomes consistent, the synchronization process has failed. Increase the size of the SRL, and then restart the procedure beginning at step 1. To resize the SRL, see Resizing the SRL.
It is likely that there might be writes beyond the checkpoint that are yet to be sent to the Secondary after
consistent flag is set on the RLINK. Use the
status command to check whether the RLINK is up-to-date:
vxrlink -g hrdg status rlk_london_hr_rvg
The same backup and the corresponding checkpoint can be used to set up additional Secondary hosts while the checkpoint is still valid. If a checkpoint has overflowed, its corresponding backup cannot be used to resynchronize the Secondary. Eventually, any checkpoint that becomes STALE is unusable. There is no warning to indicate that this has occurred. However, the
cplist command indicates that the checkpoint has overflowed and hence is unusable. For more information, see the section Displaying a list of checkpoints.