Article 174580 of comp.os.vms: In article <01bc91fc$d98b9180$84ae20cc@philssystem>, "Phillip C. Thayer" writes: > > Richard B. Gilbert wrote in article: > >> close all the files on the shadow set; e.g., shut down all the applications >> that use it and dismount the entire shadow set!!! Now you are assured that >> all buffers have been flushed and that all the disks in the shadow set are >> truly identical. >> > > You don't need to dismount the entire shadow set. All you need to do is > remove the secondary member. As long as there are not files being > accessed. Once the secondary member is removed, then you can startup your > application on the primary and do a backup from a known snapshot of the > application data. There's always a worry that file data may be cached at the time the shadow set is split. I don't know the parameters for host based shadow sets. The documentation for our HSJ50's states that cached data will always be written to disk within 30 seconds, if not sooner, so on modern controllers you can have some confidence in this method (of course, modern controllers also support the "clone" function which does this). I'd still be worried with a host based shadow set if you were to split the shadow set too soon after closing all files. On a not-too-busy system, there may not be a problem... >> Now you can remount all but one member of the shadow set and resume >> your application. The shadow set is offline for five or ten minutes instead >> of three or four hours. Backup the disk you removed from the shadow set. >> Then mount it again. The system will automatically bring it up to date via >> a "shadow merge" or a "shadow copy". > > Three of four hours? The most I've ever seen happen in the situation where > a secondary is removed for a period of time and then added back into the > shadow set is a "mini-merge". Which only takes about 30 minutes. No, a mini-merge takes a few _seconds_! Literally. If a merge starts and isn't complete in a few seconds (basically all you see are the OPCOM messages), then a mini-merge is _not_ being done. Secondly, it is frequently the case (in our experience) that a full shadow _copy_ will complete much more quickly than a merge operation, the difference being on the scale quoted: some fraction of an hour for a full copy, but many hours (on a busy system and/or with many merges in progress) for a full merge. At least part of the reason is that the "urgency" to complete a merge is much less than that of a full copy because both members of the merge are considered equally valid (and it is an _arbitrary_ choice which member's data is used if an inconsistency _is_ detected by the merge process). Therefore, the host-based shadowing software automatically "throttles" itself so that "useful work" can continue on a system doing a lot of merges. As the merge proceeds, both members can be read behind the "merge line", while only the designated shadow "master" will supply read data ahead of the merge line (both members get written for all writes). The other factor is that more data is read, and the data is compared, for a merge, while a shadow copy simply reads from one member and writes to the other. Thirdly, in response to Richard's last sentence above, under ALL circumstances in which one member is dropped from a shadow set, a full shadow _copy_ must be performed to add that member back into the shadow set. A merge can only be performed if both members are still mounted after the event, typically a cluster transition, that triggers the merge. > Also if > you do controller based shadowing then your shadow set is not offlline. It > will function just the same as normal (with a slight performance > degradation). In this case even if it did do a complete "shadow merge" or > "shadow copy" the disk is still functional and not offline. Some of the This is true of host-based shadow sets also. Have I missed your point? > Some of the > applications that I've seen use this technique have been highly critical > military command, control and communications systems and several different > installations dealing with time critical data delivery in corporate > environments. It IS a common practice with NO risk of data loss of > corruption (As long as the applications are shutdown.) You can also have three-member shadow sets (host based) or mirror sets (controller based) in order to insure that you have full online redundancy when you drop one of the three members from the set. The real issue is assuring that the dropped member is an exact current copy of the mounted shadow/mirror set, which depends on knowing that all cached write data have been written to disk (all members) before dismounting the "clone", or to-be-backed-up member. Recent controllers can, I believe, assure this. I don't believe host-based shadowing can. A dismount of the _entire_ shadow set _does_ assure that all cached data has been written to all disks before they're dismounted. -Ken -- Kenneth H. Fairfield | Internet: Fairfield@Slac.Stanford.Edu SLAC, P.O.Box 4349, MS 46 | DECnet: 45537::FAIRFIELD (45537=SLACVX) Stanford, CA 94309 | Voice: 415-926-2924 FAX: 415-926-3515 ------------------------------------------------------------------------- These opinions are mine, not SLAC's, Stanford's, nor the DOE's...