Resizing the filesystem for a DR RDQM queue manager

To resize the filesystem for an existing disaster recovery (DR) replicated data queue manager (RDQM) you back up its persistent data, then restore the data to a newly created RDQM queue manager that has the same name but a filesystem of a different size.

About this task

DR replicated data queue managers require a dedicated logical volume (filesystem) and the configuration of disk replication. These components are only configured when a new queue manager is created. The filesystem cannot be resized after it has been created because it must have the same size on each node. To resize the filesystem for an existing replicated data queue manager (RDQM) you can back up its persistent data, then restore the data to a newly created RDQM queue manager that has the same name but a filesystem of a different size. This procedure preserves the queue manager configuration, state, and persistent messages at the time the backup was created.

Procedure

  1. Back up the existing RDQM queue manager on the primary RDQM node:
    1. Determine the primary RDQM node for the queue manager. For information about how to determine the primary node, see rdqmstatus (display RDQM status) .
    2. On the primary RDQM node, if the RDQM queue manager is started, stop it by using the endmqm -w or endmqm -i command.
    3. Determine the location of the queue manager data directory by viewing the IBM® MQ configuration file, mqs.ini. On Linux, this file is located in the /var/mqm directory. For more information about mqs.ini, see IBM MQ configuration file, mqs.ini.
      Locate the QueueManager stanza for the queue manager in the file. The queue manager data directory is the value of the key named DataPath. For more information about the QueueManager stanza, see QueueManager stanza of the mqs.ini file.
    4. Create a backup of the queue manager data directory. On Linux®, you can do this by using the tar command. For example, to back up the data directory for a queue manager you can use the following command. Note the last parameter of the command, which is a single period (.) character:
      tar -cvzf qm-data.tar.gz -C queue_manager_data_dir .
    5. Determine the location of the queue manager log directory by viewing the IBM MQ queue manager configuration file qm.ini. This file is located in the queue manager data directory. For more information about the file, see Queue manager configuration files, qm.ini.
      The queue manager log directory is defined as the value of the LogPath key in the Log stanza. For information about the stanza, see Log stanza of the qm.ini file.
    6. Create a backup of the queue manager log directory. On Linux, you can do this by using the tar command. For example, to back up the log directory for a queue manager you can use the following command. Note the last parameter of the command, which is a single period (.) character:
      tar -cvzf qm-log.tar.gz -C queue_manager_log_dir .
    7. Delete the existing RDQM queue manager.
  2. Restore the queue manager with a filesystem of the required size:
    1. Create a new RDQM queue manager with the same name as the queue manager that you backed up. Ensure the filesystem allocated for the RDQM queue manager by crtmqm is the size you require, and it is big enough to contain the data, primary logs, and secondary logs for the existing queue manager, plus some additional space for future expansion. For information about how to create an RDQM queue manager, see Creating a disaster recovery RDQM.
    2. Determine the primary RDQM node for the queue manager. For information about how to determine the primary node, see rdqmstatus (display RDQM status).
    3. On the primary RDQM node, if the RDQM queue manager is started, stop it by using the endmqm -w or endmqm -i command.
    4. On the primary RDQM node, determine the new location of the data and log directories for the RDQM queue manager (use the methods described in steps 1c and 1e).
    5. On the primary RDQM node, delete the contents of the RDQM queue manager data and log directories, but not the directories themselves.
    6. On the primary RDQM node, restore the backup of the queue manager data directory to the empty data directory for the new RDQM queue manager, ensuring that file ownership and permissions are preserved. If the backup was created using the example tar command in step 1d then the following command can be used by the root user to restore it:
      tar -xvzpf qm-data.tar.gz -C queue_manager_data_dir
    7. On the primary RDQM node, restore the backup of the queue manager log directory to the empty log directory for the new RDQM queue manager, ensuring that file ownership and permissions are preserved. If the backup was created using the example tar command in step 1f then the following command can be used by the root user to restore it:
      tar -xvzpf qm-log.tar.gz -C queue_manager_log_dir
    8. On the primary RDQM node, edit the restored queue manager configuration file, qm.ini, in the data directory for the new RDQM queue manager. Update the value of the LogPath key in the Log stanza to specify the log directory for the new RDQM queue manager that you determined in step 2d. Review other file paths that are defined in the configuration file and update them if necessary. For example, you might need to update the following paths:
      • The path for error log files that are generated by diagnostic message services.
      • The path for exits that are required by the queue manager.
      • The path for switch load files if the queue manager is an XA transaction coordinator.
    9. Verify that the queue manager is displayed by the dspmq command and its status is reported as ended. The following example shows sample output for an RDQM DR queue manager:
      $ dspmq -o status -o dr
      QMNAME(QM1) STATUS(Ended normally) DR(Primary)
    10. Verify that the restored queue manager data has been replicated to the secondary RDQM node by using the rdqmstatus command to display the status for the queue manager. The DR status should be reported as Normal on each node. The following example shows sample output for an RDQM DR queue manager on the primary node:
      $ rdqmstatus -m QM1
      Queue manager status:                   Running
      CPU:                                    0.00
      Memory:                                 123MB
      Queue manager file system:              51MB used, 1.0GB allocated [5%]
      DR role:                                Primary
      DR status:                              Normal
      DR type:                                Synchronous
      DR port:                                3000
      DR local IP address:                    192.168.20.1
      DR remote IP address:                   192.168.20.2
      
      The following example shows sample output for an RDQM DR queue manager on the recovery node:
      Queue manager status:                   Ended immediately
      DR role:                                Secondary
      DR status:                              Normal
      DR port:                                3000
      DR local IP address:                    192.168.20.2
      DR remote IP address:                   192.168.20.1
    11. Start the queue manager on the primary RDQM node.
    12. Perform a switchover of the queue manager to the recovery node to ensure the required configuration has been established successfully, see Switching over to a recovery node.