| When a system crashes, things are very messy . We can get corruption in filesystems, databases need rollback recovery, and our mirror volumes need sorting out. By default, VxVM will know only that there is a difference between the plexes in a volume. When a write is happening, a dirty-bit is set for the volume. When writes to the volume complete, the dirty-bit is reset. If all writes to the volume occur before the crash, the dirty-bit will be off and the volume doesn't need resynchronizing. If a write was pending, then we have a problem . After the reboot, the volume will have plexes that are out of sync . We need to ensure that all plexes in the volume contain the same data ”an important part of being a mirror. To achieve this, VxVM will initiate a read from the plex that is in the read-policy and write to other plexes in the volume. In this way, we can be sure that all plexes contain the same data. This is happening in the background, so user IO is still allowed. The problem here is that with large volumes this can take some considerable time, because we are resynchronizing the entire volume. To assist this fast recovery in LVM, we have the Mirror Write Cache, which monitors activity at the Logical Track Group level. The equivalent in VxVM is called Dirty Region Logging (DRL). It is accomplished by creating an additional plex for a mirror volume. This plex doesn't store user data but is a log plex ; it contains two bitmaps of dirty regions within the volume. A dirty region is an area of the volume whose data has changed. For any write operation to the volume, the regions being written are marked dirty in the log before the data is written. If a write causes a log region to become dirty when it was previously clean, the log is synchronously written to disk before the write operation can occur. On system restart, VxVM recovers only those regions of the volume that are marked as dirty in the Dirty Region Log . As with MWC, there is a slight online degradation in performance because the Dirty Region Log issues a high-priority write to disk in order to track the changes to specific dirty regions . VxVM uses two bitmaps: an active and a recovery bitmap. The active bitmap is reset after a reboot and VxVM uses a mathematical/logical OR operation with the recovery bitmap after a system restart in order to work out which regions are still marked as dirty . If we want to be super safe, we can mirror the Dirty Region Log to provide redundancy for the DRL itself. When setting up a volume that will utilize a DRL, it's a good idea to use ordered allocation so you can specify specifically which disk is to be used for the DRL. It's a good idea to put DRLs on least-used disks to avoid adverse impacts on IO when the high-priority synchronous write to the DRL occurs. We can specify a size for the DRL; however, that's not necessary because VxVM will establish the size based on the size of the volume. In this example, I am adding a DRL to an existing volume ( data2 ).
root@hpeos003[] vxassist -g ora1 addlog data2 logtype=drl ora_disk1 root@hpeos003[] vxprint -g ora1 -ht data2 V NAME RVG KSTATE STATE LENGTH READPOL PREFPLEX UTYPE PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE DC NAME PARENTVOL LOGVOL SP NAME SNAPVOL DCO v data2 - ENABLED ACTIVE 4194304 SELECT - fsgen pl data2-01 data2 ENABLED ACTIVE 4194304 STRIPE 2/64 RW sd ora_disk1-03 data2-01 ora_disk1 8738144 2097152 0/0 c0t4d0 ENA sd ora_disk3-02 data2-01 ora_disk3 3495264 2097152 1/0 c4t12d0 ENA pl data2-02 data2 ENABLED ACTIVE 4194304 STRIPE 2/64 RW sd ora_disk2-03 data2-02 ora_disk2 3597664 2097152 0/0 c0t5d0 ENA sd ora_disk4-03 data2-02 ora_disk4 5345280 2097152 1/0 c4t13d0 ENA pl data2-03 data2 ENABLED ACTIVE LOGONLY CONCAT - RW sd ora_disk1-02 data2-03 ora_disk1 3495264 66 LOG c0t4d0 ENA root@hpeos003[]
The option to vxassist to make a new volume with DRL enabled is simply the logtype=drl option we saw above. Other options to DRL (Sequential DRL and SmartSync Recovery Accelerator) apply to specific situations; for example, SmartSync is used in conjunction with Oracle database software, and Sequential DRL applies only to volumes that are accessed sequentially, such as redo logs. Use of these options needs to be carefully considered . We see the benefits of DRL only when we experience a system crash and need to resynchronize stale plexes. |
