Converting a single instance queue manager to a multi-instance queue manager using NetServer and journal mirroring
Convert a single instance queue manager to a multi-instance queue manager. Move the queue manager data to a network share connected by NetServer. Mirror the queue manager journal to a second IBM® i server using remote journaling.
Before you begin
- The task requires three IBM i
servers. The existing IBM MQ
installation, on the server ALPHA in the example, must be at least
at Version 7.0.1.1. ALPHA is running a queue manager called
QM1
in the example. - Install IBM MQ on the second IBM i server, BETA in the example.
- The third server is an IBM i server, connected by NetServer to ALPHA and BETA. It is used to share the queue manager data. It does not have to have an IBM MQ installation. It is useful to install IBM MQ on the server as a temporary step, to set up the queue manager directories and permissions.
- Make sure that the
QMQM
user profile has the same password on all three servers. - Install IBM i NetServer; see i5/OS NetServer.
About this task
Perform the following steps to convert a single instance queue manager to the multi-instance queue manager shown in Figure 1. The single instance queue manager is deleted in the task, and then recreated, storing the queue manager data on the network share connected by NetServer. This procedure is more reliable than moving the queue manager directories and files to the network share using the CPY command.
- Create connections from ALPHA and BETA to the directory share on GAMMA that is to store the queue manager data. The task also sets up the necessary permissions, user profiles and passwords.
- Add Relational Database Entries (RDBE) to the IBM i systems that are going to run queue manager instances. The RDBE entries are used to connect to the IBM i systems used for remote journaling.
- Save the queue manager logs and definitions, stop the queue manager, and delete it.
- Recreate the queue manager, storing the queue manager data on the network share on GAMMA.
- Add the second instance of the queue manager to the other server.
- Create remote journals on both the IBM i servers for both queue manager instances. Each queue manager writes to the local journal. The local journal is replicated to the remote journal. The command, ADDMQMJRN simplifies adding the journals and the connections.
- Start the queue manager, permitting a standby instance.
In step 4 of the task, you delete the single instance queue manager, QM1
. Deleting the queue manager deletes all the persistent messages on queues. For this reason, complete processing all the messages stored by the queue manager, before converting the queue manager. If processing all the messages is not possible, back up the queue manager library before step 4. Restore the queue manager library after step 5.
In step 5 of the task, you recreate QM1
. Although the queue manager has the same name, it has a different queue manager identifier. Queue manager clustering uses the queue manager identifier. To delete and recreate a queue manager in a cluster, you must first remove the queue manager from the cluster; see Removing a queue manager from a cluster: Alternative method or Removing a queue manager from a cluster. When you have recreated the queue manager, add it to the cluster. Although it has the same name as before, it appears to be a new queue manager to the other queue managers in the cluster.
Procedure
Results
Use WRKMQM to check queue manager status:
- The status of the queue manager instance on ALPHA should be
*ACTIVE
. - The status of the queue manager instance on BETA should be
*STANDBY
.
Example
What to do next
- Verify that the active and standby instances switch over automatically. You can run the sample high availability sample programs to test the switch over; see High availability sample programs. The sample programs are 'C' clients. You can run them from a Windows or Unix platform.
- Start the high availability sample programs.
- On ALPHA, end the queue manager requesting switch over:
ENDMQM MQMNAME(QM1) OPTION(*IMMED) ALSWITCH(*YES)
- Check that the instance of
QM1
on BETA is active. - Restart
QM1
on ALPHASTRMQM MQMNAME(QM1) STANDBY(*YES)
- Look at alternative high availability configurations:
- Use NetServer to place the queue manager data on a Windows server.
- Instead of using remote journaling to mirror the queue manager journal, store the journal on an independent ASP. Use IBM i clustering to transfer the independent ASP from ALPHA to BETA.