ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexGeneral IBM MQ SupportDR Channel Fail back

Post new topicReply to topic Goto page 1, 2  Next
DR Channel Fail back View previous topic :: View next topic
Author Message
bobbee
PostPosted: Tue Nov 19, 2019 11:05 am Post subject: DR Channel Fail back Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 419
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
View user's profile Send private message Send e-mail AIM Address
Vitor
PostPosted: Tue Nov 19, 2019 12:01 pm Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25858
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
View user's profile Send private message
bobbee
PostPosted: Tue Nov 19, 2019 12:09 pm Post subject: Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 419
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
View user's profile Send private message Send e-mail AIM Address
gbaddeley
PostPosted: Tue Nov 19, 2019 3:03 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2040
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
View user's profile Send private message
bobbee
PostPosted: Tue Nov 19, 2019 5:16 pm Post subject: Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 419
Location: Tampa

agreed, I am trying to understand their message volume to make some kind of decision.
Back to top
View user's profile Send private message Send e-mail AIM Address
hughson
PostPosted: Tue Nov 19, 2019 8:18 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1283
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
View user's profile Send private message Visit poster's website
bobbee
PostPosted: Wed Nov 20, 2019 2:16 am Post subject: Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 419
Location: Tampa

Thanks M. Hope your doing well up there. Miss you!!
Back to top
View user's profile Send private message Send e-mail AIM Address
hughson
PostPosted: Wed Nov 20, 2019 2:47 am Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1283
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
View user's profile Send private message Visit poster's website
Vitor
PostPosted: Wed Nov 20, 2019 6:47 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25858
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
View user's profile Send private message
Vitor
PostPosted: Wed Nov 20, 2019 6:51 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25858
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
View user's profile Send private message
bobbee
PostPosted: Mon Nov 25, 2019 6:31 am Post subject: Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 419
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
View user's profile Send private message Send e-mail AIM Address
bobbee
PostPosted: Mon Nov 25, 2019 6:54 am Post subject: Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 419
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
View user's profile Send private message Send e-mail AIM Address
Joseph88
PostPosted: Mon Dec 02, 2019 12:25 pm Post subject: Re: DR Channel Fail back Reply with quote

Newbie

Joined: 02 Dec 2019
Posts: 5

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
View user's profile Send private message
bobbee
PostPosted: Tue Dec 03, 2019 3:58 am Post subject: Reply with quote

Chevalier

Joined: 20 Sep 2001
Posts: 419
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
View user's profile Send private message Send e-mail AIM Address
fjb_saper
PostPosted: Tue Dec 03, 2019 9:01 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20138
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
View user's profile Send private message Send e-mail
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexGeneral IBM MQ SupportDR Channel Fail back
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.