| Author |
Message
|
| issac |
 Posted: Mon May 07, 2012 11:40 pm Post subject: newbie question about backup qmgr |
 |
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Hello,
The infocenter requires the backup qmgr to have the same name of the primary QMGR, but this would forbid it from being on the same host of the primary one.
If so, they should be of different IPs, then should I modify my application so it tries for the backup IP if the backup qmgr is activated and started?
So I think a complete procedure to make use of the backup QMGR would be:
CREATE THE BACKUP QMGR:
1) prepare for another host;
2) create the backup qmgr on another host, then do as what infocenter says;
3) periodically update the backup qmgr;
USE THE BACKUP QMGR IF THE PRIMARY FAILS:
1) activate and start the backup qmgr as the infocenter says;
2) ask applications to switch to the backup IP to continue using the QMGR.
am i right? Thank you in advance.
_________________
Bazinga! |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue May 08, 2012 12:13 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Please do not DOUBLE POST!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| issac |
| Posted: Tue May 08, 2012 12:23 am Post subject: |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Sorry, I didn't mean to post there. I tried creating a new topic but mistakenly created a reply, then found it's not possible to delete the reply. Sorry again. 
_________________
Bazinga! |
|
| Back to top |
|
|
| exerk |
| Posted: Tue May 08, 2012 12:26 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
No worries. I'll delete it for you.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| issac |
| Posted: Tue May 08, 2012 1:05 am Post subject: |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Any idea about my question please?
The infocenter mentioned the backup qmgr should be of the same name, but have not mentioned if another host is required.
But it seems no way to create 2 qmgrs of the same name on one host. If it indeed requires 2 hosts like HACMP, I don't know if WMQ has already created a good way to acknowledge client applications that they now should connect to another IP.
If it does require 2 hosts, is there any article comparing the backup qmgr with HACMP?
_________________
Bazinga! |
|
| Back to top |
|
|
| exerk |
| Posted: Tue May 08, 2012 1:21 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| issac wrote: |
| The infocenter mentioned the backup qmgr should be of the same name, but have not mentioned if another host is required. |
There's not much point to having a back-up queue manager on the same host because if you lose the host, you lose both the queue managers.
| issac wrote: |
| But it seems no way to create 2 qmgrs of the same name on one host. |
Correct. And there never has been that facility.
| issac wrote: |
| If it indeed requires 2 hosts like HACMP, I don't know if WMQ has already created a good way to acknowledge client applications that they now should connect to another IP. |
From WMQ V7.0.1 onward there is the ability for WMQ client applications to chain CONNAMEs, for binding applications the answer is self-evident.
| issac wrote: |
| If it does require 2 hosts, is there any article comparing the backup qmgr with HACMP? |
Possibly. Highly-Available queue managers (a la HACMP) are different animals to Back-Up queue managers, which are about service restoration.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| issac |
| Posted: Tue May 08, 2012 3:34 am Post subject: |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Hello, thank you very much!
We're still at V6.0.2.11 for now, and we want a way to backup QMGR data periodically without stopping the QMGR. If the concept of backup qmgr brings about the IP change when the backup is used, we would go for other options.
But I still have one question. At the event when the primary QMGR fails, what if I copy data from the backup QMGR into the primary one?
I mean, I would copy both logs and qmgr data back into the primary QMGR from the backup one when the primary one fails.
Could I restore the primary this way? Would this possibly bring me some kind of risk? I've not seen it documented in the infocenter, though I think it might work.
_________________
Bazinga!
Last edited by issac on Tue May 08, 2012 3:37 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue May 08, 2012 3:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you want an MQ supplied way for a queue manager to recover from a failure and continue processing work on a different host/IP, and have client applications automatically be able to connect to the recovered queue manager on the new host, then you should be using a multi-instance queue manager, not a backup queue manager.
In neither case can you create the secondary instance on the same host as the primary instance.
In the case of a multi-instance queue manager, you put both ip addresses in the conname of the svrconn that the client applications are using, and you make a very very minor change to the client applications to add the right MQCONN option to allow retry.
Or you create a shell script that can move a virtual IP from one machine to another, and use an MQ service to run the shell script at qmgr startup. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue May 08, 2012 3:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Think of it as a loop:
1. Copy primary queue manager data/logs -> back-up queue manager;
2. Primary queue manager fails, activate back-up queue manager;
3. Delete/redefine primary queue manager, then copy back-up queue manager data/logs -> primary queue manager;
4. Activate primary queue manager;
5. Delete/redefine back-up queue manager then copy primary queue manager data/logs -> back-up queue manager.
Of course you'll need outages, but if you want state restoration rather than just service restoration, then that's the bullet you'll have to bite. Alternatives are SAN replication (entire system) or the use of one of the products offered by one of the sponsors of this site.
EDIT: Having just seen mqjeff's post - I am making the assumption in my post that you are exploring back-up queue managers as a Disaster Recovery solution.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Last edited by exerk on Tue May 08, 2012 3:44 am; edited 1 time in total |
|
| Back to top |
|
|
| issac |
| Posted: Tue May 08, 2012 3:43 am Post subject: |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
Thank you, mqjeff.
We've looked into the multi-instance approach, but we're worrying if someday data of the QMGR corrupts due to a bug or something. We had such experience when at V6.0.1.1, when the entire cluster stopped forwarding messages, and IBM guys instructed us to clear the queue of S.C.REPOSITORY.Q and blah blah a lot of we-never-would-do-again stuff.
We have already setup HACMP, but it would help when the AIX box crashes. What we're worried now is if anything inside the data, for example repository info inside S.C.REPOSITORY.Q, corrupts, in which case whichever host we take over the service would not make difference since the data is corrupted already.
That thought leads us to make backups, especially ones that does not require stopping the QMGR to carry out...
_________________
Bazinga! |
|
| Back to top |
|
|
| issac |
| Posted: Tue May 08, 2012 3:51 am Post subject: |
|
|
Disciple
Joined: 02 Oct 2008
Posts: 158
Location: Shanghai
|
| exerk wrote: |
EDIT: Having just seen mqjeff's post - I am making the assumption in my post that you are exploring back-up queue managers as a Disaster Recovery solution. |
Aha, you're right. I indeed am exploring the backup approach as a Disaster Recovery solution. 
Thank you for the loop concept. I think that's the ideal way to use backup qmgrs, and perhaps the way when Hursley "eggheads" designed this feature for.  I'll try it out.
_________________
Bazinga! |
|
| Back to top |
|
|
|
|
