CODEWITHSUNDEEP
ibm-mqmq
wing2ofsky
wing2ofsky

Reputation: 934

what does the queue manager data and log refer during the backup operation?

According to the information center from IBM MQ, we can backup queue manager data in order to Backup and restore QMGR. One of the step is to take the copy of qmgr data and log file directories. My question is what the data and log file directories specially mean? is it my below understanding correct?

data directory ---- /var/mqm/qmgrs/QMGR01/
log  directory ---- /var/mqm/log/QMGR01/

Another one is MQ has the non-persistent and persistent message type. As for the non-persistent, is the message only being stored in memory? Once whatever crash, it can not be recovered.Rgt? However, the persistent message can survive that crash. But where is the persistent message stored normally?

Please help me out. Thanks very much

Upvotes: 2

Views: 2845

Answers (1)

T.Rob
T.Rob

Reputation: 31852

Yes, you have the directories correct. Just make sure that if you take a filesystem backup that the QMgr is shut down at the time.

Be aware that point-in-time backups are usually not a good strategy for backing up a QMgr. Whatever messages are on the QMgr at the time will be redelivered when the QMgr is restored, unless you take measures to stop that from happening. If the QMgr is in a cluster, it will be out of synch with the cluster when restored.

Generally the approach to backing up a QMgr is to save the object definitions, the access control lists, any exits and their parm files. Restoring the QMgr is a matter of using crtmqm to create a new instance and running in all the definitions.

Non-persistent messages are stored in memory until they overflow memory and then they are stored to the queue file on disk. If the queue is marked as NPMCLASS(HIGH) then the QMgr will attempt to save and restore non-persistent messages through an orderly shutdown and restart but will discard them if the QMgr crashes.

Persistent messages are hardened to both the queue and log files before control is returned to the calling program if written out of syncpoint. If persistent messages are written under syncpoint, WMQ allows lazy cached writes of the messages but insures they are all flushed before returning control from the COMMIT command.

Upvotes: 1

Related Questions