Hacker News Reader

Comment by atom_enger | Hacker News Reader

You're definitely not mirroring your infrastructure any time soon :). Not to say that it's impossible because I don't believe in impossible, but that's quite a stack to replicate.

We have much the same stack at Reverb.com and I focus more on creating a disaster recovery plan than tackling a mirror of our infra. I'm focusing on bringing up our stack in another region of AWS if we would ever need to rather than mirroring everything.

Sometimes a mitigation plan is far more useful than building in excessively complicated redundancy.

View on HN

That's interesting and probably more in line with what I need to do. It wouldn't be difficult for me to bring the entire stack online in another datacenter, but if all of your customer data resides on (for simplicity) a master SQL node in Linode-Dallas and that datacenter goes offline, how can you bring that backup node online when you can no longer access the Dallas machines?

Are you suggesting to have a slave ready to become master in the 2nd datacenter? If that's the case, my main area of uncertainty is: if you promote a slave to master in a 2nd datacenter and that new master accepts writes, you then have a brutal problem of propagating writes to the old master when he comes back online.

The whole thing may exceed my capability right now but I think having a disaster recovery is far better than a mirror now that I think through it.

I'm curious about the stuff that's hard to replicate. Don't most of them store their stuff in files? Could those users perhaps use a distributed filesystem for replication? Clustered filesystems were used in supercomputers, are used by Google, and similar methods go back to VMS systems on VAXen.

I'm not saying something off-the-shelf will work or out of the box. Just seems like there would be a clear path for admins or developers of such software to integrate it with... something [1]... that did that.

[1] Example: http://sector.sourceforge.net/

Reply on news.ycombinator.com