SLUG Mailing List Archives
Re: [SLUG] today's scary thought
- To: slug@xxxxxxxxxxx
- Subject: Re: [SLUG] today's scary thought
- From: Jamie Wilkinson <jaq@xxxxxxxxxxxxxx>
- Date: Thu, 15 Jul 2010 09:11:13 -0700
On 14 July 2010 23:14, Daniel Pittman <daniel@xxxxxxxxxxxx> wrote:
> Sadly, I can't right now advise a better solution than these, however,
> it is the main problem I face in trying to bridge two data-centers and
> coherent and sensible file access.
I think you're going to be out of luck without some fat short pipes to
satisfy fast atomic commits to both sides. The cloud way is to have your
applications understand there's a replication delay and know how to deal
with conflict resolutions, drop the atomicity and integrity constraints to
gain some speed.
I suspect from your mention of "file access" then you're not dealing with
*an* application, but *all of them* and your storage layer API is just
POSIX, in which case I wish you well in your pipe procurement endeavours.
Random tangential brainstorm: if your application knew that your POSIX
filesystem was being slowly replicated between two DCs, and knew to look in
*both* for the same data, and was robust enough to handle the loss of one
DC, then it ought to be able to pick up where it left off in the other DC
modulo some journalling. Again I suspect this isn't going to help you in
the slightest, not knowing anything about your app :)