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 Index » Clustering » Partial Repository without any current FR's

Post new topic  Reply to topic
 Partial Repository without any current FR's « View previous topic :: View next topic » 
Author Message
smeunier
PostPosted: Wed Jan 02, 2019 1:21 pm    Post subject: Partial Repository without any current FR's Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont

In a classic cart before the horse scenario...............

Two servers (AIX V7.5) were scheduled for decommissioning. These servers held the FR's for a cluster. Two z/os servers(V8.0) were PR's in this cluster.

The servers with the FR's were decommissioned without due diligence being performed to remove the two PR from the cluster beforehand. Now that the FR's are gone, I'm finding it increasingly difficult to clean/remove the PR's from the cluster (that really does not exist any longer). I have performed all the normal action for removing a QMGR from a cluster on the PR's. The actions are taken and by all appearance it seems that the PR QMGRS were out of the cluster. However, I'm now getting messages that the CLUSTER SDR channels to the FR are failing to start (of course, the servers are gone and the channels deleted!), even though the manually defined channels have been deleted. It appears that the cluster went ahead an created auto cluster SDR channels to complete communications back to the FR, which again are no longer in service.

How can I clean up this mess and remove these PR's from the cluster(that really no longer exists in nature, but MQ seems to think it still does)?!

If I did a REFRESH CLUSTER with REPOS(YES), this will clear the local cluster cache(PR) specifically the channels AUTO/MANUAL defined? It won't be able to communicate with the FR to rebuild, as it does not exist, so I'm not sure what the state would be. I have an opportunity to perform this action in the next week or so when one of the PR's will be offline.

The desired state, is for the PR's to no longer be a part of or know about the cluster as if it never belonged to it. With the FR's gone, it is becoming difficult to get this clean up.

Thoughts?
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Jan 02, 2019 1:27 pm    Post subject: Re: Partial Repository without any current FR's Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

smeunier wrote:
Thoughts?


You're


Find the genius who took out the FRs and take him out before they get you. It won't help but you'll feel better.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Jan 02, 2019 1:29 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

If it was me (and it isn't), I'd make sure all the PRs had their CLUSTER attribute blanked out, endure 90 days of error messages and hope that it all came right when the repository data automatically expired.


Hosed up clusters are the worst to fix.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Jan 02, 2019 1:33 pm    Post subject: Re: Partial Repository without any current FR's Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

smeunier wrote:
(of course, the servers are gone and the channels deleted!)


Could you put a temporary server on the IP address / hostname of the missing FRs, do a refresh and then decommission the cluster correctly?

You might still get problems because the FRs don't have the QMIDs of the originals but it's an alternative.......
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Wed Jan 02, 2019 2:03 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

Quote:
Remove a queue manager from a cluster, in scenarios where, because of a significant system or configuration issue, the queue manager cannot communicate with any full repository in the cluster.

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.con.doc/q017530_.htm
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Jan 02, 2019 3:12 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Vitor wrote:
If it was me (and it isn't), I'd make sure all the PRs had their CLUSTER attribute blanked out, endure 90 days of error messages and hope that it all came right when the repository data automatically expired.


Hosed up clusters are the worst to fix.

IMHO, most hosed up clusters are self-inflicted wounds. This one certainly qualifies.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Jan 03, 2019 1:14 am    Post subject: Re: Partial Repository without any current FR's Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

smeunier wrote:
If I did a REFRESH CLUSTER with REPOS(YES), this will clear the local cluster cache(PR) specifically the channels AUTO/MANUAL defined? It won't be able to communicate with the FR to rebuild, as it does not exist, so I'm not sure what the state would be.

A REFRESH CLUSTER on a PR removes all the information it has received from FRs, so therefore the next time it needs to know where Q-blah lives it asks the FRs again. Adding REPOS(YES) to the command means it ALSO deletes the details about the FRs and has to start again as if it had never been in the cluster before.

To put another way, REFRESH CLUSTER REPOS(YES) means you have to start again from scratch with manual channel defs. If you have deleted said manual channel defs then there is nothing to start again from and so the PR will not be repopulated.

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
smeunier
PostPosted: Thu Jan 03, 2019 7:28 am    Post subject: Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont

Quote:
If it was me (and it isn't), I'd make sure all the PRs had their CLUSTER attribute blanked out, endure 90 days of error messages and hope that it all came right when the repository data automatically expired.


The cluster attribute points to another cluster. The two z/os qmgrs were partial repositories for 2 other clusters. They are also FR for another cluster. So QMGRA and QMGRB are PR for CLUSTER1 and CLUSTER2. The are FR to CLUSTER3

QMGRA/B were successfully removed from CLUSTER1. CLUSTER2, which had its FR's blown away, still has residual CLUSTER2 artifacts on QMGRSA/B. CLUSTER3 is to remain intact and is just fine. QMGRA/B are the FR's for this cluster.
Back to top
View user's profile Send private message
smeunier
PostPosted: Thu Jan 03, 2019 7:46 am    Post subject: Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont

Morag,

Quote:
To put another way, REFRESH CLUSTER REPOS(YES) means you have to start again from scratch


As I mentioned in previous reply, these z/os QMGRS are PR's for this cluster(CLUSTER2), but they are also FR's for another cluster(CLUSTER3).

I need to insure that if I issue: REFRESH CLUSTER(CLUSTER2) REPOS(YES) that CLUSTER3 information/configuration is not disturbed. I assume that only CLUSTER2 information will be touched. I also need to insure that any of the cluster queues it thinks it has are not deleted. The cluster attributes to those queues were altered last week to '', but the CLUSTER2 repository still believes it owns them(or cluster to it). The goal is to rid CLUSTER2 from the PR's and leave CLUSTER3 untouched. We have a window of opportunity where these z/os QMGRS will be offline (2 day rotating interval). If refresh to CLUSTER2 is the magic key for final clean up, then that is when it will get done.

I originally had this step(REFRESH) as part of my script to clean this up, but after post clean up everything looked good. So I nix'ed it. Looks like it should have been done.
Back to top
View user's profile Send private message
smeunier
PostPosted: Thu Jan 03, 2019 8:05 am    Post subject: Reply with quote

Partisan

Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont

Quote:
IMHO, most hosed up clusters are self-inflicted wounds. This one certainly qualifies.


And nothing worse then having to be the medic for someone else's self-inflicted wound
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Jan 03, 2019 7:37 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

smeunier wrote:
Morag,

Quote:
To put another way, REFRESH CLUSTER REPOS(YES) means you have to start again from scratch


As I mentioned in previous reply, these z/os QMGRS are PR's for this cluster(CLUSTER2), but they are also FR's for another cluster(CLUSTER3).

I need to insure that if I issue: REFRESH CLUSTER(CLUSTER2) REPOS(YES) that CLUSTER3 information/configuration is not disturbed. I assume that only CLUSTER2 information will be touched. I also need to insure that any of the cluster queues it thinks it has are not deleted. The cluster attributes to those queues were altered last week to '', but the CLUSTER2 repository still believes it owns them(or cluster to it). The goal is to rid CLUSTER2 from the PR's and leave CLUSTER3 untouched. We have a window of opportunity where these z/os QMGRS will be offline (2 day rotating interval). If refresh to CLUSTER2 is the magic key for final clean up, then that is when it will get done.

I originally had this step(REFRESH) as part of my script to clean this up, but after post clean up everything looked good. So I nix'ed it. Looks like it should have been done.

REFRESH CLUSTER(CLUSTER2) REPOS(YES) should only touch resources in the PR that are for CLUSTER2.

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
fjb_saper
PostPosted: Fri Jan 04, 2019 10:18 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

I believe for your PRs at this point it's no longer a refresh cluster that you need as the cluster no longer exists but a RESET CLUSTER command with the QMGR and or the QMID...

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
hughson
PostPosted: Sun Jan 06, 2019 3:07 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

fjb_saper wrote:
I believe for your PRs at this point it's no longer a refresh cluster that you need as the cluster no longer exists but a RESET CLUSTER command with the QMGR and or the QMID...

Have fun

RESET CLUSTER will not empty the data from the PR. That's what REFRESH CLUSTER does.

Please expand on what you think RESET CLUSTER will achieve on a disconnected PR.

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
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » Partial Repository without any current FR's
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.