| Author |
Message
|
| bhanukiran |
 Posted: Fri Jan 23, 2009 3:21 pm Post subject: How to replicate two different Websphere Mq servers..... |
 |
|
Novice
Joined: 23 Jan 2009
Posts: 10
|
I am trying to replicate an Websphere MQ server with another......
I am running two virtual machines(vm/xp) on a host(xp)..
What I am trying to do is......if I send a message from A to B.....then the massage should be replicated and also be sent over to macine C. I am trying to set up a failover MQ(machine C) for machine (B)...
My efforts:
I tried to go through Q replication...but I figured out that it is used to replicate DB using MQ..but it does not replicate MQ..
am I supposed to do some thing else or is Q replication itself the solution....???
Any suggestions would make me feel happy on my weekend  thank you....
I dont know if this is a crazy idea.....if it is, then my boss told me to do it.
Thank you in advance |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sat Jan 24, 2009 1:30 am Post subject: Re: How to replicate two different Websphere Mq servers..... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bhanukiran wrote: |
I dont know if this is a crazy idea.....if it is, then my boss told me to do it.
|
It's a crazy idea. There are various techniques for duplicating messages, all of which have been discussed on the forum at one time or another and the search feature (top right this page) will get you started.
The issue here seems more fundamental. A message arrives on a queue on machine B, and is replicated (by a method of your choice) onto C. The message on B is processed, whatever happens then happens (database is updated, another message sent, etc, etc) and there is joy.
What clears the message off C? What mechanism removes it so you don't get duplicates when you failover, or indeed C doesn't fill up with all these messages.
You'd need to build an application or processe to clear off successfully processed messages on B once the downstream process has completed. You'd need one of these for every queue you replicate on B, and build another for every new queue you ever build on B. Very complex, very resource expensive and you'd spend ages making sure of message integrity (that each message on B went to C and was only deleted when the message on B was processed). Cost a fortune as well; team of programmers every time something changed.
Or you could buy a SAN disc, put it between the B & C machines, buy commercial, reliable, tested HA software to handle all the failover issues for you and walk off whistling a happy tune.
I know what I'd do.... 
If your boss goes white when you mention spending money, look up "backup queue manager" in the WMQ info center. Not quite what you're wanting, but free with the product.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bhanukiran |
| Posted: Sat Jan 24, 2009 3:17 pm Post subject: |
|
|
Novice
Joined: 23 Jan 2009
Posts: 10
|
thank you for the reply.....
would'nt q replication provide the necessary solution....coz machine B would direct whatever messages sent to it to macine C and the same database that is behind B would also be present behind macine C......is'nt that a potential solution??
would'nt that provide proper back up.
or do you think of a process that runs in the background for backing up the query manager in machine B every time a message is sent to and processed at machine B. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Jan 25, 2009 3:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bhanukiran wrote: |
| would'nt q replication provide the necessary solution....coz machine B would direct whatever messages sent to it to macine C and the same database that is behind B would also be present behind macine C......is'nt that a potential solution?? |
What's clearing the replicated messages off C? How does the database determine, on failover, which of the messages held on C have already been processed from B?
Yes, it's a potential solution. Similar to the one I described above. Just moves the anti-duplication from the queue manager to the database. I still think it's crazy, but it's your system.
| bhanukiran wrote: |
| or do you think of a process that runs in the background for backing up the query manager in machine B every time a message is sent to and processed at machine B. |
I think you have a system much less busy than I'm used to. 
It, again, would work but it's slightly crazy and certainly wouldn't scale too well. How long would the backup take? How much time is the queue manager out of action while the backup runs? How much time does that leave for messages to arrive?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bhanukiran |
| Posted: Sun Jan 25, 2009 11:16 am Post subject: |
|
|
Novice
Joined: 23 Jan 2009
Posts: 10
|
I am in a deep thought now................
I am totally new to MQ and stuff...........according to my boss I am supposed setup a failover server for our client.........but my problem is nobody at our office has any idea about...........MQ server.....I am trying to gain knowledge about MQ server so.......I dont know what to tell my boss and how to approach the problem....I am ready to put all my efforts to setup a failover but it looks like there apparently is a solution.
 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Jan 25, 2009 12:49 pm Post subject: Re: How to replicate two different Websphere Mq servers..... |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
Or you could buy a SAN disc, put it between the B & C machines, buy commercial, reliable, tested HA software to handle all the failover issues for you and walk off whistling a happy tune.
I know what I'd do....
If your boss goes white when you mention spending money, look up "backup queue manager" in the WMQ info center. Not quite what you're wanting, but free with the product. |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Jan 25, 2009 1:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bhanukiran wrote: |
| I dont know what to tell my boss and how to approach the problem |
You've had my suggestion. Spend the money, get a traditional HA solution, walk away.
One final thought. If you (and the rest of your office) is this new and inexperienced with WMQ, the last thing you want to be using is the mirrorq exits. Exits are an advanced topic and the risks (even for experienced users) are very real.
But you're the only one who really knows your situation, your client and your boss.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| masteringmq |
| Posted: Sun Jan 25, 2009 6:56 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
To replicate or to create a copy of the message you can use the MSGEXIT option. You need to create a .exe program and specify this .exe program in the MSGEXIT as a value. So when a message is being put on a channel the program will create a duplicate copy of the message and send it over to where ever you need to sent the duplicate message. This concept is a good idea when you intend to handle message tracking for example  |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 26, 2009 12:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| masteringmq wrote: |
| To replicate or to create a copy of the message you can use the MSGEXIT option. |
We've already (in this thread) discussed the possible use of exits, along with the advantages and disadvantages. It's pointless posting if you've nothing new to add.
| masteringmq wrote: |
| So when a message is being put on a channel the program will create a duplicate copy of the message and send it over to where ever you need to sent the duplicate message. |
You're confusing channel exits with queue exits. It's also mildly irresponsible to suggest exits as a solution to a poster by his own admision inexperienced; much like suggesting to a small child he can swat a fly with a loaded gun. Yes, it would work but it's not the most appropriate tool and contains risks not apparent to the end user!
| masteringmq wrote: |
| This concept is a good idea when you intend to handle message tracking for example |
No it isn't. Firstly the concept of message tracking is anti-pattern to WMQ's concept of assured delivery - the point of paying IBM the license fee for the software is that you don't need to track messages; you know they'll arrive. Secondly, such misguided auditing is often what mirrorq is used for and there are many, many posts in here on why this is a bad design solution.
Thirdly, this poster doesn't want to track messages but back them up as a failover solution. This is radically different is concept to a static list of messages through a choke point.
Aside from that, your post is right on the money. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
