| Author |
Message
|
| PeterPotkay |
 Posted: Wed Jan 14, 2004 12:51 pm Post subject: Image backup of a Full Repository QM. Then a restore. Uh-oh |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
QM1FULL and QM2FULL are full repositories for CLUSTER1.
QM3PART is a partial repository in CLUSTER1.
All are on separate servers.
Windows 2000 SP3
MQ 5.3 CSD04
On Day 1, full image backups are taken of all servers.
On Days 2 and 3, new cluster queues are created on QM3PART. Both QM1FULL and QM2FULL see these as expected and all is working good.
On Day 4, the server housing QM2FULL is restored from an image from Day 1, and QM2FULL is restarted.
All the changes to QM3PART done since Day 1 are no longer reflected in QM2FULL's full repository. Puts to these new queues on QM2FULL are now failing with 2087.
What is the right way to get QM2FULL to get itself up to date????
REFRESH CLUSTER(CLUSTER1) REPOS(NO) did not do it.
I don't think changing QM2FULL to be a partial repository so that I could use REPOS(YES) would help, as I think this would only have the now partial QM2FULL tell QM1FULL about itself, and being a partial would have no reason to suck over all of the full repositories info.
Luckily there were not that many queues in question, so I simply went to QM3PART and altered the queue description of every queue that was in CLUSTER1, as well as the CLUSRCVR on QM3PART. his caused QM3PART to send update info to both QM1FULL and QM2FULL, and all was good.
There has to a proper (easier) way to do this.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Wed Jan 14, 2004 1:30 pm Post subject: Re: Image backup of a Full Repository QM. Then a restore. Uh |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
I don't think changing QM2FULL to be a partial repository so that I could use REPOS(YES) would help, as I think this would only have the now partial QM2FULL tell QM1FULL about itself, and being a partial would have no reason to suck over all of the full repositories info. |
Peter,
better stop trusting your instinct... 
Manual says:
REPOS(YES)
Specifies that in addition to the REPOS(NO) behavior, objects representing full repository cluster queue managers are also refreshed. This option must not be used if the queue manager is itself a full repository, if it is a full repository, you must first alter it so that it is not a full repository for the cluster in question. The full repository location is recovered from the manually defined CLUSSDR definitions. After the refresh with REPOS(YES) has been issued, the queue manager can be altered so that it is once again a full repository, if required.
Michael |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 14, 2004 7:38 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I still don't see how issuing that command, even after making it a partial and using the repos yes option, would give me what I want.
Consider a cluster with 1000 partial repositories and 2 full. If I made a new QM that is a partial and issued the REFRESH command, even with repos YES, that new QM would not suck in all the info for all 1000 QMs held in the full repositories. It would only push out its own info to the fulls. And it would only get new info on queues on those 1000 other QMs as it needed them.
I need a particular QM (QM2FULL) to suck in ALL the info from another QM's full repository (QM1FULL). The refresh command does not do that. It pushes info our rather than pulling info in.
Its almost as if I need a SYNC type command, to tell one QM to get all the Full repository info from another QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Jan 15, 2004 12:39 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
you've got me puzzled aswell... 
maybe we should not read the partial and full to strict?
I hope someone from IBM can shed some light on this...
What happens when you simply stop and start the restored QM2FULL, shouldn't it then synchronise with QM1FULL on reconnection to the cluster?
Michael |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 15, 2004 5:02 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
What happens when you simply stop and start the restored QM2FULL, shouldn't it then synchronise with QM1FULL on reconnection to the cluster?
|
That's what I had hoped would happen, but it did not.
I guess it almost makes sense that it didn't. Full repositories do not constantly talk to each other for no reason. They just update each other when there is new info to share. When QM2FULL was restored, QM1FULL just saw that event as his buddy coming back up, not a new QM that needed to be told everything.
Since QM2FULL was the exact QM, why would QM1FULL need to push everything over again? How would QM1FULL know that QM2FULL was out of sync? Maybe QM1FULL was out of sync. And how would it even know how long it has been out of communication with its partner QM? These questions make me believe that the full repositories do not keep pulsing info back and forth. And why perhaps a "SYNC from QM1 to QM2" type command is needed for Full Repositories?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Jan 15, 2004 10:54 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Since your qm seems to be in down state and you want the repository info to be refreshed, why dont you just start this QM(taken from backup), remove from cluster and then add to the cluster as a full repository. That way you get all the info that you need from the other full repository.
Reason this seems safe to me is:
1) you can get the qm down
2) since this qm is out of sync you want it to get the latest info from the other full repos and update its own
Hope this helps.
Cheers
Kumar |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 16, 2004 8:47 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Hmmmm, interesting idea!
Would reintroducing this QM again as a "new" full repository work, and cause the other full repository to push everything over? Or would I corrupt the cluster with duplicate entries for that QM, even though the QMID stayed the same?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqonnet |
| Posted: Fri Jan 16, 2004 9:12 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Frankly speaking i havent done this and i am here all theoretical only. Of course, with valid reasonings. :)
When you rejoin the 2nd QM(which was previous a full repos within this same cluster), the only full repos qm that is there would accept this 2nd qm as if it were any other "new" qm that is trying to join. It would not keep any cached info about it from earlier.
Theoretically, whenever you join/rejoin a qm into an existing cluster, the only thing that happens is the full repos shares all info that it has in its cluster with the new full repos qm via subscription messages. I dont think it does have or keep any info of either other full repos qms that are connected or were removed earlier. Reason being, a full repos in itself is a master, it doesnt really care and shouldnt about other masters. Its the responsibility of all the masters though, to keep themselves in sync.
Since your case involved you having to restore a qm from an "outdated" version of the QM(old repos info), its the responsibility of the user to resolve this. MQ wouldnt do this unless MQ has corrupted something. Thats the reason refresh did not work for you. Since MQ thinks there was nothing that it needs to refresh with all the participating(full repos) qms within the cluster.
Hope this helps.
Cheers
Kumar |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jan 20, 2004 12:17 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I tested this thoroughly and it works great.
1- Alter QM2FULL REPOS(' ') //so you can do step 2
2- REFRESH CLUSTER(CLUSTER1) REPOS(YES) // push out all the old info from the repository, and only populate it with fresh info about yourself
3- Alter QM2FULL REPOS(CLUSTER1) // build your full repository to be 100% accurate. I assume it gets all the info for the cluster from the other full repository(s). If this was the last / only repository, you would be sunk.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqonnet |
| Posted: Tue Jan 20, 2004 12:26 pm Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Glad that it worked out.
Under the circumstances that you were in, i guess its always the best to reintroduce the qm in the cluster, all fresh, so that it gets the latest info into its own cache.
Cheers
Kumar |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Jan 20, 2004 2:03 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
| I tested this thoroughly and it works great. |
glad to see it's WAD!
Michael |
|
| Back to top |
|
|
|
|
