By temporarily detaching slices from mirror volumes, you can create snapshots (replications) of the volumes. In other words, by use of detached slices, volume data at the moment can be accessed.
Detached slices are logical devices separated from volumes, and other applications that use the detached slices can run simultaneously with service applications that use the volumes. For example, backup applications can be executed concurrently with service applications.
For volumes shared on multiple nodes, by separating nodes running service applications that use the volumes from ones running applications that use detached slices, an operation mode where process loads do not influence on each other can also be established.
After applications that use detached slices end, it is necessary to reattach the detached slices to volumes in order to create snapshots again. At this point, copying will be performed to synchronize data on the slices and the volumes in order to create snapshots again. For this copying, GDS uses JRM (Just Resynchronization Mechanism) for slices to realize high-speed resynchronization by copying only the portions that were updated while slices were detached.
Figure 1.31 Snapshot by Slice detachment
Note
Ensuring Consistency of Snapshot Data
If you create a snapshot while an application is accessing the volume, the data consistency may not be ensured, as the volume data may be incomplete.
To ensure the consistency of your snapshot data, you must stop the application that is accessing the volume in advance. After creating the snapshot, start the application again.
For example, when using the volume as a file system such as GFS or ufs, unmount the volume with the umount(1M) command before creating a snapshot, and mount it with the mount(1M) command afterwards. Then, you can ensure the consistency of the snapshot data.
To create a snapshot while running the application, the file system or database system you are using to manage the data must be able to ensure data integrity.
Note
JRM for Slices
JRM for slices speeds up the resynchronization process when attaching a detached slice again to the volume. GDS records the changes made on the volume and slice in the memory while the slice is being detached. The resynchronization copy performed when the detached slice is reattached copies the updated portions only to realize high-speed resynchronization.
JRM for slices becomes effective when a slice is detached while the jrm attribute of the slices is on. However, if a system is stopped or if the slice is taken over by the sdxslice -T command while the slice is detached, just resynchronization is not conducted when the temporarily detached slice is attached again. Resynchronization is performed by copying the entire data, not only the updated portions.
Therefore, if you plan to shut down the system, or have a slice taken over, attaching the slice to the volume in advance is highly recommended.
Information
What is JRM?
JRM stands for Just Resynchronization Mechanism, a feature that only allows duplication of the damaged part of data.
Information
Three Types of JRM
There are three types of Just Resynchronization Mechanism (JRM): for volumes, for slices and for proxy. For details, see "A.2.21 Just Resynchronization Mechanism (JRM)."
