| Author |
Message
|
| bobbee |
 Posted: Tue Nov 19, 2019 11:05 am Post subject: DR Channel Fail back |
 |
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
| Channel with stacked IP. When the primary fails MQ switches to the DR. Is there a way to have the QMGR fail the Server channel back to the primary. Clustering is, maybe, not an option. The Prim and DR QMGRS are at an outside customer aand DR is always up. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Nov 19, 2019 12:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Stop and start the channel. Be easy enough to write a cron tab / QMGR service that pinged the primary IP and, if it was back up, issue the relevant commands.
Personally, I'd not want this done automatically. I'd want to control fail back manually so I could ensure data continuity. It's one thing to lose transactions / data because you had to fail over in an emergency; it's quite another to lose stuff when you got it all back working.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bobbee |
| Posted: Tue Nov 19, 2019 12:09 pm Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
yeah, that is on the table. They wanted to avoid that. On suggestion was to set the DisInt to 1,2 seconds and catch the window when no traffic was going and let it drop the channel.
Question, they were testing and the DR QMGR is a different QMGR with a different name. when he stops and starts the channel to switch back, they do not get a Seq num Error. Is that because MQ ignores it because of the Stacked IP in the Conn field? |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Nov 19, 2019 3:03 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bobbee wrote: |
| ...On suggestion was to set the DisInt to 1,2 seconds and catch the window when no traffic was going and let it drop the channel... |
Setting DISCINT to a very low value could create a lot of overhead and delays in MQ due to continuously ending and starting the channel, particularly if it is below the average time between batches of messages.
In general, I would be very careful about setting it below say 60 seconds. Typically we use a minimum of 300 secs. Higher values up to 3600 are common, depending on the average message volume.
_________________
Glenn |
|
| Back to top |
|
|
| bobbee |
| Posted: Tue Nov 19, 2019 5:16 pm Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
| agreed, I am trying to understand their message volume to make some kind of decision. |
|
| Back to top |
|
|
| hughson |
| Posted: Tue Nov 19, 2019 8:18 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| bobbee wrote: |
| Question, they were testing and the DR QMGR is a different QMGR with a different name. when he stops and starts the channel to switch back, they do not get a Seq num Error. Is that because MQ ignores it because of the Stacked IP in the Conn field? |
No it's because MQ channels will keep different state for each queue manager partner. State includes sequence number. You can see this state with the DISPLAY CHSTATUS(name) SAVED command.
It will behave differently if you have the same named queue manager.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bobbee |
| Posted: Wed Nov 20, 2019 2:16 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
| Thanks M. Hope your doing well up there. Miss you!! |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Nov 20, 2019 2:47 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| bobbee wrote: |
| Thanks M. Hope your doing well up there. Miss you!! |
Thanks B. Although I think of it as down rather than up 
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 20, 2019 6:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bobbee wrote: |
| agreed, I am trying to understand their message volume to make some kind of decision. |
I'm going to bang on one more time about data consistency. I didn't mean "losing a transaction" because you dropped the channel on the message's head, I meant you lose the transaction because you process it on the DR site after the live one's come back up and other systems have failed back.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 20, 2019 6:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hughson wrote: |
| bobbee wrote: |
| Thanks M. Hope your doing well up there. Miss you!! |
Thanks B. Although I think of it as down rather than up |
Nothing and no-one around you can ever be "down" 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bobbee |
| Posted: Mon Nov 25, 2019 6:31 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
The customer is entertaining the idea of putting a cluster at the receiving side with the receiving Queue clustered and let Work Load Balancing do it's think. I had the configuration for this at a prior customer which I applied. I cannot seem to get it to work the SAME.
QMGRS: CL1 & CL2
Cluster Queues - CL1, 'Receiver' (CWLRANK =3), CL2, 'Receiver' (CWLRANK = 2)
Client, CDDT Conn=CL1, Cl2
Connect to CL1, msgs go to Receiver, Stop CL1, client reconnects, msgs go to System.Cluster.Queue. Restart CL1, all messages move to 'Receiver' on CL1.
How do I get msgs to route to CL2 'Receiver' Queue when CL1 is down? I did try CLWPRTY. Is this possible in Client mode. |
|
| Back to top |
|
|
| bobbee |
| Posted: Mon Nov 25, 2019 6:54 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
I am going crazy, I read a write up on RANK & PRTY and I saw that RANK does not consider Channel status. So. as I did before, I switched back to PRTY as I want the Q checked and Channel status. Now it works. The God of MQ is messing with me.
Thanks. |
|
| Back to top |
|
|
| Joseph88 |
| Posted: Mon Dec 02, 2019 12:25 pm Post subject: Re: DR Channel Fail back |
|
|
Guest
|
| bobbee wrote: |
Channel with stacked IP. When the primary fails MQ switches to the DR. Is there a way to have the QMGR fail the Server channel back to the primary. Clustering is, maybe, not an option. The Prim and DR QMGRS are at an outside customer aand DR is always up.
|
By the way, did you get the answer you wanted? |
|
| Back to top |
|
|
| bobbee |
| Posted: Tue Dec 03, 2019 3:58 am Post subject: |
|
|
Knight
Joined: 20 Sep 2001
Posts: 545
Location: Tampa
|
| I found my old mega multiplex clustering config I did for a large retailer. I used RANK and it worked perfectly. The customer said the external customer has agreed to clustering the two servers so I can go to the bar and have a drink. Solution found. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 03, 2019 9:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bobbee wrote: |
| I found my old mega multiplex clustering config I did for a large retailer. I used RANK and it worked perfectly. The customer said the external customer has agreed to clustering the two servers so I can go to the bar and have a drink. Solution found. |
Hooray for you! Just don't forget the umbrella (for the drink!)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
