| Author |
Message
|
| jonny |
 Posted: Thu Oct 13, 2005 4:36 am Post subject: Backup and Recovery - SAVEQMGR vs Backup of file system |
 |
|
Acolyte
Joined: 03 Jul 2003
Posts: 57
|
Hi,
As far as I understand it, there are two ways for backing up and recovering MQ:
1)- Backing up the MQ file system on Solaris, that's /var/mqm/. This requires stopping the queue manager.
2)- Using scripts, SAVEQMGR support pacc(MS03) could be used or an inhouse script. In addition to the MQ objects, another script to create any required ACL's (setmqaut).
The first option requires stopping the queue manager, and manageing messages that might have been on queues when backup was taking. But no script will be required to recreate MQ objects and ACL's
The second option means queue managers can be running 24\7, but manual intervention will b required to reset channels. (mind you, resetting channels might also be required for option 1, if only some queue managers were recovered). Even if queue manager used by a WBIMB had to be recreated, this method will still work as long as the SYSTEM.BROKER* queues are recreated, so the broker doesn't have to be recreated.
So the question is: Will I hit problems if I opted for the second option??
Using WMQ 5.3 CSD08, WBIMB 5 CSD06, Solaris
Thanks
Now when a queue manager is to be recovered,
1- Using SAVEQMGR we will simply recreate it and then recreate all MQ objects using SAVEQMGR, then we will run |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Oct 13, 2005 4:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Do you care about messages that may be on queues when things break?
Most people do, and therefore most people do BOTH option 1 and option 2.
It's the difference between backing up a database and backing up the database DDL.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Thu Oct 13, 2005 4:51 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
| but manual intervention will b required to reset channels. |
Not if you use the -R option on saveqmgr 
_________________
-wayne |
|
| Back to top |
|
|
| jonny |
| Posted: Thu Oct 13, 2005 5:02 am Post subject: |
|
|
Acolyte
Joined: 03 Jul 2003
Posts: 57
|
Thanks wschutz.
Jeff,
When things break up and there are messages on queues, then if you're using the file system backup to recover, it will not recover thos messages if the backup was taken before thos messages arrived on queues.
I can't see why most people would go for both options. It's one or the other.
Database is normally used to store information, whereas MQ is used to pass information (messages) so it's not exactly the same.
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 13, 2005 5:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Right, but persistent messages will still be there.
If you delete and recreate the qm from scratch, you'll lose persistent messages.
The point is that the two options do different things and meet different needs.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Oct 13, 2005 5:10 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
Database is normally used to store information, whereas MQ is used to pass information (messages) so it's not exactly the same.
|
In theory you are correct, but check out the CONTENTS of some of the SYSTEM. queues  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 13, 2005 5:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kevinf2349 wrote: |
| Quote: |
Database is normally used to store information, whereas MQ is used to pass information (messages) so it's not exactly the same.
|
In theory you are correct, but check out the CONTENTS of some of the SYSTEM. queues |
Right... his option 2 should also include amqoamd...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jonny |
| Posted: Thu Oct 13, 2005 6:54 am Post subject: |
|
|
Acolyte
Joined: 03 Jul 2003
Posts: 57
|
Kevin,
You're right, and I think the only queues that are used to store info are:
SYSTEM.AUTH.DATA.QUEUE and
SYSTEM.CLUSTER.REPOSITORY.QUEUE
For the authority queue, as long the acl's are scripted, it will be possible to regenerate those messages
The cluster repository queue (we don't use clustering) can be saved using an MQ tool, which can the be loaded back onto the queue.
There is also the Channel synchronization queue (SYSTEM.CHANNEL.SYNCQ), I think if the channels will be reset, it is not necessary backing up this queue.
Jeff,
If you take MQ system backup, say, on a daily basis, and let's say at the time of the backup was taken there were 100 messages on a queue, then next day these messages would have been processed )most likely) unless you're using the queues for storage purpose, hence the database scenario. We simply use MQ to process messages as soon as they arrive, and we don't use it as a storage. I agree with you that the two options can meet different need.
You mentioned the amqoamd command, but I though if I have all of ACL's in a script (setmqaut), this should have the same effect as running the amqoamd.
Thanks to you both |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 13, 2005 6:56 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jonny wrote: |
| You mentioned the amqoamd command, but I though if I have all of ACL's in a script (setmqaut), this should have the same effect as running the amqoamd. |
Yes, but with amqoamd, you don't need to write and maintain the script. It's the same reason one uses saveqmgr, to avoid having to write and maintain an mqsc script to recreate one's qm.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Oct 13, 2005 7:05 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| jonny wrote: |
| The cluster repository queue (we don't use clustering) can be saved using an MQ tool, which can the be loaded back onto the queue. |
No need really, just recreate the QM and it will query concerning shared queues when needed, and fill up said queue; or simply refresh cluster...
| jonny wrote: |
| There is also the Channel synchronization queue (SYSTEM.CHANNEL.SYNCQ), I think if the channels will be reset, it is not necessary backing up this queue. |
Correct, reset chl is enough.
I'm with jeff on this one, if you have a built-in mq command, you'd bloody well use it, and be forever thankful  |
|
| Back to top |
|
|
|
|
