Reference: Rick Cochran's note of Thu, 11 Aug 1994 10:49:12 -0400 (EDT) We have a similar configuration, and originally thought that we would get read-only capabilities when some part of our cell is isolated from a quorum of database servers. We were very disappointed when we discovered the same thing as Rick - clients can't do ANY AFS work if they can't reach a database server that's part of a quorum. More specifically, the authentication and protection servers will give out read-only information but the volume-location server refuses to make any data available when a quorum does not exist. I agree that the existing design is unfortunate. From the perspective of our clients machines, our distributed Unix service is completely down if AFS isn't working. So we lose everything if we experience a network partition between our two main sites or if the site that has the majority of database servers loses power long enough to run the UPS batteries dry. Since we put user homedirs on file servers in the site where they work, our users could often do much useful work even if the database servers only gave out data, refusing all updates, in the case of these kinds of failures. We think that any security and operational holes in such a scenario are minor, easily handled, and clearly worthwhile in order to make our service more robust. We have asked Transarc about such changes and have received no satisfactory response.
database server behavior during network partition
Mark H. Linehan (8-863-7860) Thu, 11 Aug 1994 13:54:33 -0400
- database server behavior during network parti... rick
- Re: database server behavior during netw... Rens Troost
- Re: database server behavior during ... Marcus Watts
- Re: database server behavior during netw... Mark H. Linehan (8-863-7860)
- Re: database server behavior during ... Michael Niksch
- Re: database server behavior during netw... Mark Giuffrida
- Re: database server behavior during ... Rens Troost
- Re: database server behavior during ... Perry E. Metzger
- Re: database server behavior dur... Bruce Howard
- Re: database server behavior... Lyle_Seaman
- Re: database server beh... John Hascall
- Re: database server... Michael Niksch
- Re: database server beh... Rens Troost
- Re: database server beh... Perry E. Metzger
