Command Line Mirror Administration

In addition to performing actions through the LifeKeeper GUI, the mirror can also be administered using the command line. There are several commands (found in the $LKROOT/bin directory) that can be used to administer a DataKeeper resource.

Mirror Actions

mirror_action <tag> <action> [source] [target(s)]

<tag> is the LifeKeeper resource tag of the DataKeeper resource

<action> is one of: pause, resume, force, fullresync

[source] (optional) is the current source system (if source is not specified, it will use the current system the command was run from)

[target] (optional) is the target system (or list of systems) that the action should affect (if target(s) is not specified, it will use all of the applicable target(s))

*Note: When using the force action, source argument is required to specify source node and target(s) argument is unnecessary. When using the pause, resume or fullresync action, if specifying target(s) argument, source argument is also required.

Examples:

To pause the mirror named datarep-ext3:

mirror_action datarep-ext3 pause

To resume replication from adam to both eve and sophocles:

mirror_action datarep-ext3 resume adam eve sophocles

To force the mirror online on system eve (force mirror online):

mirror_action datarep-ext3 force eve

To resume replication and force a full resynchronization from adam to sophocles:

mirror_action datarep-ext3 fullresync adam sophocles

Mirror Resize

The mirror_resize command performs a mirror resize without having to recreate the resource. The underlying devices should be resized on both the source and target system before resizing the mirror. Then run the command on the source system. The size of the underlying devices will be auto-detected and used as the new mirror size. Optionally the mirror size can be specified.

With LifeKeeper v9.5.0 or later, the mirror can be resized even when the resource is in service. However, when reducing the mirror size, the resource must be out of service. Please note that some file systems do not support reducing the mirror size.

!If the resize is performed while the mirror is online it will require a full resync. Resizing when the mirror is out-of-service will ONLY synchronize data in the area that is increased.

*Note: When the command is interrupted due to an error etc., add the “-f” option and execute again. If not completed successfully, data may become inconsistent.

mirror_resize [-f] [-s <size>] <tag>

<tag> is the tag of a mirror resource

-f forces the resize without user prompts (not recommended). Adding the [-f] option also forces a full-resync.

-s <size> specifies alternate mirror size (in KB) This parameter is required.

Requirements for Mirror Resize

• Underlying devices should be a logical volume (LV)

• Only a configuration with a single target is supported

*NOTE: mirror_resize is NOT supported in multi-target configurations.

Recommended Steps for Mirror Resize with an EXT file system:

1. Perform the resize of the underlying device. Perform this on both the source and the target. (Please note that the target size must be greater than or equal to the source size.) Note: This can be done while the hierarchy is in-service and active without impacting synchronization.

2. Run mirror_resize on one server. If the data replication resource is in-service, run mirror_resize on the in-service server (source). If the resize is performed while the mirror is online it will require a full resync. This will update the internal metadata and bitmap for the mirror to reflect the newly expanded disk size.

Example: mirror_resize –s <size in KB> <tag>

3. If the data replication resource is out of service, bring only the mirror (i.e. datarep) resource in service on the server where mirror_resize was done in step 2. A resync of the newly expanded device will occur. Note: If “wait to resync” is enabled then run /opt/LifeKeeper/bin/mirror_action resume to force an immediate partial resync.

4. The file system resize can be done with the file system in-service (mounted) or out-of-service (unmounted). If you wish to do the resize with the file system mounted, bring the file system resource in-service. Note: If the file system resource is NOT brought in-service an fsck may be required.

5. Perform the file system resize on the mirror device (e.g. resize2fs /dev/mdX where X is md device number for the mirror being resized such as /dev/md0).

6. If the hierarchy is not fully in-service it may now be brought in-service. All resynchronizations must complete before a switchover to the target is allowed.

Recommended Steps for Mirror Resize with an XFS file system:

1. Perform the resize of the underlying device. Perform this on both the source and the target. (Please note that the target size must be greater than or equal to the source size.) Note: This can be done while the hierarchy is in-service and active without impacting synchronization.

2. Run mirror_resize on one server. If the data replication resource is in-service, run mirror_resize on the in-service server (source). If the resize is performed while the mirror is online it will require a full resync. This will update the internal metadata and bitmap for the mirror to reflect the newly expanded disk size.

Example: mirror_resize –s <size in KB> <tag>

3. If the resource is out of service, bring only the mirror (i.e. datarep) resource in service on the server where mirror_resize was done in step 2. A resync of the newly expanded device will occur. Note: If “wait to resync” is enabled then run /opt/LifeKeeper/bin/mirror_action resume to force an immediate partial resync.

4. If the file system resource is not in-service, bring it in-service now. The XFS file system resize must be done with the file system in-service (mounted).

5. Perform the file system resize on the file system (e.g. xfs_growfs -d /path_to_file_system).

6. If the hierarchy is not fully in-service it may now be brought in-service. All resynchronizations must complete before a switchover to the target is allowed.

Bitmap Administration

bitmap -a <num>|-c|-d|-x <size_kb>|-X <bitmap_file>

-a <num> adds the asynchronous write parameter to the bitmap file. It is needed if a synchronous mirror is upgraded to include an asynchronous target. The default value for <num> is 256. To calculate the correct value for this limit, see the Asynchronous Mirroring Information in Mirroring with SIOS DataKeeper for Linux.

-c cleans the bitmap file (zeroes all the bits). This can be used to avoid a full resync in case an exact replica of the source disk exists on the target. Use this option with extreme caution.

-d dirties the bitmap file (sets all the bits to ones). This option can be used to force a full resync, for example after a split-brain situation has occurred.

-m reads the bitmap and produces merge stream.

-X <bitmap file> examines the bitmap file and displays useful information about the bitmap and the mirror.

-x <size_kb> extends bitmap file to be valid with disk of size_kb.
(Note: This option is only used internally for mirror resizing.)

In addition, the mdadm command may also be used to administer a DataKeeper resource, as the DataKeeper resource is actually an md device. Refer to the mdadm(8) man page for details. Note: When using mdadm, be sure to use $LKROOT/bin/mdadm, not the one included with the operating system.