I agree that in one sense having 4 full repos's is unecesary, the reason for the redundancy is that each group needs to be able to operate in the event of the loss of the other group (loss of a data center for instance). This way each group always has two full repos's available.
tonyB. > -------- Original Message -------- > Subject: Re: Disappearing cluster queues > From: "Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]> > Date: Tue, September 21, 2004 1:12 pm > To: [EMAIL PROTECTED] > > If all these QMs are in 1 cluster, then all you need is 2 Full Repositories, > with manual CLUSSNDRS defined between them. Those extra Full Repositories > are just that, extra. No need for them, unless you put FR #1 and FR #2 on > servers that are both down frequently, but why would you do that? > > > > -----Original Message----- > From: Tony Boggis [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 21, 2004 3:15 PM > To: [EMAIL PROTECTED] > Subject: Re: Disappearing cluster queues > > > So in my cluster, I have 2 groups (each group is in a separate data > center) of 12 queue managers. Each group has 2 full repos's defined, > with channels defined across groups to ensure that the cluster works as > a whole. > > If I understand correctly, does this mean that on Repos-A, I have to > define a CLUSSDR to Repos-B,C & D? Similarly on Repos-B, do I have to > define a CLUSSDR to Repos-A,C & D... and so on? > > tonyB. > > > -------- Original Message -------- > > Subject: Re: Disappearing cluster queues > > From: "Wyatt, T Rob" <[EMAIL PROTECTED]> > > Date: Mon, September 20, 2004 6:49 pm > > To: [EMAIL PROTECTED] > > > > Tony, > > > > Information flows between repositories only on explicitly defined > channels. Do all four of your repositories have explicitly defined CLUSSDRS > to each other? When your queues go missing, do they go missing on the > partial repository only? If they are in the full repositories, are they in > *ALL* of them? > > > > If there is a problem in the distribution of repository information, the > repositories get out of synch. The partials will reflect whichever of the > full repositories they are talking to at the moment. So if the repositories > get out of synch, the partials may change from time to time as they talk to > different fulls. > > > > From the manual: > > > http://publibfp.boulder.ibm.com/epubs/html/csqzah06/csqzah060u.htm#HDRCSQ684 > 1 > > "The CLUSSDR definitions made on the full repository queue managers are > special. All the updates exchanged by the full repositories flow exclusively > on these channels. The administrator controls the network of full > repositories explicitly. The administrator must make the CLUSSDR definitions > on full repository queue managers manually and not leave them to be > auto-defined." > > > > So you should have explicitly defined CLUSSDR channels from each repos to > each other repos. You should not need to create explicit defs to the leaf > nodes if the repositories are fully in synch. > > > > Hope that helps, > > -- T.Rob > > > > > > -----Original Message----- > > From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Tony > > Boggis > > Sent: Monday, September 20, 2004 9:18 PM > > To: [EMAIL PROTECTED] > > Subject: Disappearing cluster queues > > > > > > Puzzling situation... > > > > Environment: Solaris, WMQ 5.3 CSD05. > > > > I have a cluster with about 24 queue managers each on it's own host. All > > are "sharing" one or more queues in the cluster, eaching being unique, > > giving 200+ queues. > > > > Periodically cluster queues "disappear" on some hosts, leaving me > > getting 2085 errors, even from amqsput. Manually refreshing the cluster > > (REFRESH CLUSTER) usually does the trick. Usually. > > > > All my CLUSSDR/CLUSRCVR channels are configured and none are > > Binding/Retrying, etc. I have 4 full-respository managers defined, all > > are up and running. > > > > This is not 60+ days or anything that would obviously point to cluster > > expiration. > > > > tonyB. > > > > Instructions for managing your mailing list subscription are provided in > > the Listserv General Users Guide available at http://www.lsoft.com > > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > Instructions for managing your mailing list subscription are provided in > > the Listserv General Users Guide available at http://www.lsoft.com > > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > This communication, including attachments, is for the exclusive use of > addressee and may contain proprietary, confidential or privileged > information. If you are not the intended recipient, any use, copying, > disclosure, dissemination or distribution is strictly prohibited. If > you are not the intended recipient, please notify the sender > immediately by return email and delete this communication and destroy all copies. > > Instructions for managing your mailing list subscription are provided in > the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
