Mike,
It is
the *Partial* repositories that publish to only two other nodes. The Full
repositories will publish to all repositories they know about and that have
explicit CLUSSDR channels defined. This is the basis for IBM's
recommendation to explicitly define CLUSSDRs between ALL full repositories in
the cluster.
From
the manual at: http://publibfp.boulder.ibm.com/epubs/html/csqzah06/csqzah0617.htm#HDRCSQ6849
"The full repositories
republish the publications they receive through the manually-defined CLUSSDR
channels, which must point to other full repositories in the cluster. You
must make sure that a publication received by any full repository
ultimately reaches all the other full repositories. You do this by manually
defining CLUSSDR channels between the full repositories. The more
interconnection of full repositories you have, the more robust the
cluster."
--
T.Rob
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED]On Behalf Of Mike Davidson
Sent: Wednesday, September 22, 2004 9:27 AM
To: [EMAIL PROTECTED]
Subject: Re: Disappearing cluster queues
One important point that should be made concerning the decision to go with more than 2 Full Repositories is that - out of the box MQ will only publish and subscribe cluster object information to 2 Full Repositories. Any more than 2 will require manual intervention to update the extras of any changes/additions/deletions that are taking place within the cluster.
Mike Davidson
TSYS MQ Tech Support
IBM Certified System Administrator - WebSphere MQ V5.3
IBM Certified Solution Designer - WebSphere MQ V5.3
[EMAIL PROTECTED]
"Potkay, Peter M (ISD, IT)" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[EMAIL PROTECTED]>09/21/2004 04:12 PM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject: Re: Disappearing cluster queues
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
The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you
