| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| repository redundancy question |
« View previous topic :: View next topic » |
| Author |
Message
|
| bduncan |
 Posted: Wed May 16, 2001 11:06 am Post subject: |
 |
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
We have had so many problems when machines would get rebooted, especially when our repository would go down and not necessarily be the first machine to restart. Well I was thinking. If you take a normal node in a cluster, a non-repository, and reboot it, when it comes back up, it queries the repository for information. Let's say when it comes back up, neither of the repositories are up. I've noticed that none of the virtual channels exist. It seems like the queue manager rebuilds all of it's virtual channels whenever it reboots, and rebuilding them obviously depends on the repository being available. Now, let's say we do the same thing, but this time, one of the two repositories is available. More specifically, let's say that the "main" repository (the one we actually defined the channels for) is down, but the "backup" repository is not. I have a feeling that because the channels to this other repository are virtual, the queue manager will try to query the OTHER repository for these definitions (which is down) and therefore won't be able to connect to the backup repository. So in essence the backup repository is doing us no good. The solution to this would obviously be for every node in the cluster we actually define 4 channels, not 2. A sender and receiver to each of the two repositories, this way, the queue manager has the channel definitions available all the time, so it should be able to connect to either repository if the other is down. Does this sound reasonable or am I missing the concept completely?... Any tips?
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
 |
| bduncan |
| Posted: Mon May 21, 2001 9:31 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Though it looks like I'm replying to myself, I actually got what appears to be the answer from some people at IBM Hursley... Take a look:
> The non repository hardens its knowledge of the cluster so when it
> is shut down and restarted there is no need for it to have contact with the
> full repositories. The channels to and from the full repositories will only
> need to run when something changes that the queue manager needs to be told
> about, or when the queue manager needs to know about something new, like a
> queue that it is opening for the very first time.
>
> If you run the commands
>
> DISPLAY CLUSQMGR(*)
> DISPLAY QC(*)
>
> you should still see the full repositories are known about even though
> channels to them are not running.
>
>
> All full repositories are treated equally, there is no concept of a main
> and a backup. Information about changed objects always flows to and from
> two full repositories. If no full repositories are available at the time
> of the change, the message representing the change waits on a transmit
> queue.
>
>
> Hope this helps.
>
> Andrew Banks
> MQSeries Development
> Hursley Park
> Winchester
> Telephone (0044) 1962 816123
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| rajesh_avrs |
| Posted: Sun Feb 20, 2005 3:28 pm Post subject: |
|
|
Apprentice
Joined: 18 May 2001
Posts: 31
|
In our production, whenever we encounter a problem with some of the applications on the MQServer (the full repository), we shutdown the whole server and the rest of the cluster seem to be working fine. We have Windows 2000 and OS390 Queue Managers in the cluster.
_________________
****************
MQSeries is cool
**************** |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
