Hello Andrew, > > Cheers, I forgot to say _by hand_. > You can do this with 'vos convertROtoRW', but it's intended to be more > of a tool for disaster recovery (when you've permanently lost the RW, > and all you have are ROs). Not generally for keeping up availability > while a server is temporarily down.
> Note that if A goes down, you convertROtoRW on B, and A comes back up, > you'll now have 2 copies of the RW. The one on B will be the one used, > but A has another copy that may contain data you want. This can get > rather confusing if you try to sync the VLDB with the list of volumes > that are on each server. Thank you, good to know this, it would be used as the last resort. > Automatic failover has been done using multiple servers sharing the same > backend storage; I don't think anyone's done it with separate storage, > but we're not stopping you from doing so. You could in theory do > something like that with some other HA software, and writing some > scripts to issue 'vos' commands to do the conversions. Cheers, it is quite possible some servers would get hooked into SAN, so it is an option. > But it's usually a lot easier if you can just treat RO volumes as > high-availability, and RW volumes not. Makes sense, it looks having multiple RW volumes would not scale that well - writes would have to go to each volume, + synchronisation would get messy I guess... Thank you all, I have done the replicas. Do I understand it correctly (observation), a read-only replica placed on the same partition as the read-write volume does not "cost" much in terms of disc-space? I have released few replicas and the disc usage did not go up. Is it along the principle of LVM snapshots? Kind regards, Vladimir ------ > because it reverses the logical flow of conversation + it is hard to follow. >> why not? >>> do not put a reply at the top of the message, please... Please access the attached hyperlink for an important electronic communications disclaimer: http://www.lse.ac.uk/collections/planningAndCorporatePolicy/legalandComplianceTeam/legal/disclaimer.htm _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
