T.Rob, i think you misread my mail, i never said you would run it on same qmgr as your application, but you can "run it in any critical box that has got mq already (to avoid pay the license)". By box I really meant server and we do run repository qmgr alongside other "critical" qmgrs , critical - to avoid long downtime of server.
... and i don't find it difficult to resolve....but saw issues happened
before. In the environment with continuous stream of messages , if the
repository information lost and need to be re-gained, certain amount of
messages may go to DLQ with "cluster resolution" error. I'm sure there
could be all sort of other issues as well.
The point i was trying to convey - that I can think of very few reasons
why you would want to reduce FR to one considering "potential" impact.
Alexander Gerasimenko
(a.k.a. Sasha)
Application Integration Analyst
Application Messaging &
Integration Team, ISW , *120, x.6629
Information Services
International, (part of Mars Inc.)
DDI: +44 (0) 118 9446629
mobile: +44 (0) 7966920715
mailto:
[EMAIL PROTECTED]
web: www.mars.com
T-Rob <[EMAIL PROTECTED]>
Sent by: MQSeries List <[email protected]>
05/12/2006 11:00
Please respond to MQSeries List
To:
[email protected]
cc:
Subject:
Re: Cluster, Repository, SPOF
> a problem arises only when a cluster object is created or changed?
S. - Well, sort of. The problem is not so much what happens when you
don't have a repository for a little while, the problem comes when you
need to change something while it is down, or worse, decide that you
single repository is not recoverable. If you have two repositories and
lose one permanently, you can seamlessly add another. But if you have
only one, it does and you need to add another, even if only for a short
time, you are essentially creating a new cluster from scratch. You will
need to make it a repository and then go to each partial, delete it's
CLUSSDR, create a new one and do a REFRESH. So, yes you can run with no
repository for a while, but the consequences if you ever need to replace
it or make a change while it is down are substantial.
> One
> thing I learned - cluster works perfectly when it does, once you get
> an issue - it could be very difficult to resolve. Personally don't
> think it is worth doing , nor that it save you anything. FP are very
> lightweight and you can run it in any critical box that has got mq
> already (to avoid pay the license).
Alexander - Your statement concerning where to run the full repositories
may partially explain why you found cluster problems difficult to resolve.
The command to fix a full repository (RESET CLUSTER) and the command you
use to fix a partial repository (REFRESH CLUSTER) are mutually exclusive.
The RESET command with FORCEREMOVE cannot be used on a partial repository
and the REFRESH is not recommended to be used on a repository. So when
your application and repository are on the same QMgr, issuing these
commands can result in unanticipated (but utterly explainable)
consequences. This is one reason it is recommended to host repositories
on a stand-alone QMgr.
You could create a second QMgr for the repository to isolate it from the
application but this too has its problems. If you have a cluster problem
which requires application of maintenance, this should not need to wait
for the application team's availability to test on the new version. Since
there can never be more than one version of WMQ on a host, this means that
creating a second or third QMgr to host the repository on the same box as
an application does not provide the necessary separation.
I will admit that clusters can be challenging and are a deep subject
within WMQ. However, once you have learned the internals and made sure
that your configurations are not contributing to the problem, resolving
problems is usually not that difficult. I would encourage people to go to
the conference and sit in on some of the sessions that teach internals and
advanced cluster concepts.
-- T.Rob
T.Robert Wyatt, Consulting IT Specialist
IBM Software Services for Websphere
email: [EMAIL PROTECTED]
704-719-2107 Access Line
MQSeries List <[email protected]> wrote on 12/04/2006
04:32:09 AM:
>
> I beleive that full repository contacted when object accessed first
> time - regardless of whether it is new or old object. There are also
> updates going to full repositories when object changed. I think
> there is also some refresh of the object information going on b/w
> partial and full repositories to ensure that unused objects removed.
>
> I guess it will work if repository down but you may have issues when
> you recover full repository and all partial will try to resync. One
> thing I learned - cluster works perfectly when it does, once you get
> an issue - it could be very difficult to resolve. Personally don't
> think it is worth doing , nor that it save you anything. FP are very
> lightweight and you can run it in any critical box that has got mq
> already (to avoid pay the license).
>
>
> Alexander Gerasimenko
> (a.k.a. Sasha)
> Application Integration Analyst
> Application Messaging &
> Integration Team, ISW , *120, x.6629
> Information Services
> International, (part of Mars Inc.)
> DDI: +44 (0) 118 9446629
> mobile: +44 (0) 7966920715
> mailto: alexander.
> [EMAIL PROTECTED]
> web: www.mars.com
>
>
>
>
>
>
>
> [EMAIL PROTECTED]
> Sent by: MQSeries List <[email protected]>
> 04/12/2006 09:19
> Please respond to MQSeries List
>
> To:
>
> [email protected]
>
> cc:
>
> Subject:
>
> Cluster, Repository, SPOF
>
>
>
>
> hi!
>
> the ibm doc recommends to always use at least two full repositories
> in a cluster, because just on fp would be a single point of failure.
>
> is't really so important to have two fp?
>
> what happens if i use only one fp and it crashes?
> there is no interrupt in normal operation, because every cluster-
> node has a partial repository that should up to date. is that
> correct? if a cluster-node doesn't know about a cluster object, it
> requests that information at the fp and subscribes to subsequent
> information concerning that object. in normal operation the partial
> repos should be up to date.
>
> a problem arises only when a cluster object is created or changed?
>
> thanx for help
>
>
> --
> "Ein Herz für Kinder" - Ihre Spende hilft! Aktion:
www.deutschlandsegelt.de
> Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's
Cup-Yacht!
>
> To unsubscribe, write to [EMAIL PROTECTED] and,
> in the message body (not the subject), write: SIGNOFF MQSERIES
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
To unsubscribe, write to [EMAIL PROTECTED] and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
jpgvCyI2rwFvu.jpg
Description: JPEG image
