Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking for a solution to make sure my site stays accessible as much as possible on a long term basic, what i might need is just a simple DNS management solution (I don't know but i would like your help).

  • We have a Primary Server

  • We plan to do r-sync (to synchronize the file) and also another solution to sync(backup) the MYSQL database.

  • IF our site goes down we've setup instant SMS/Email notification.

So i'm looking for the best solution to switch to the backup server almost instantaneously.

I know that i can setup multiple name-servers but as far as i understand they can timeout or it can take 2-5 sec to load which in both cases i want to avoid.

So what's the best solution for me to use?

Also once the primary server becomes available how can I make sure it get's the db/file edits that were done on the backup server?


share|improve this question

closed as not constructive by Shane Madden, Iain, Evan Anderson, womble, Holocryptic Aug 19 '11 at 21:03

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.… – mailq Aug 19 '11 at 20:56
five 9s = 5 minutes and 15 seconds of acceptable downtime per year. Google's uptime isn't that high. – Chris S Aug 19 '11 at 21:26

What you're asking for is by no means a simple, cut-and-dried thing. You can't just pull something off the shelf and magically have 5-nines of uptime.

For a site with purely static content you could do something easy with redundant DNS servers and redundant content servers (or a CDN). I wouldn't say that 5-nines of uptime for a site with purely static content would be trivial, but it certainly wouldn't be too hard.

I can't imagine you have a site with static content, though.

When you ask " can I make sure it get's the db/file edits that were done on the backup server?" you turn your question into a huge, non-trivial problem. There are people who make their entire living answering your question for different database platforms, web frameworks, and off-the-shelf applications.

share|improve this answer

There are a lot of problems with this question. Usually services that offer that sort of uptime in their SLA's have lots of redundancy, everything from power generators to network switches and datacenters in other facilities, etc, etc... the list goes on. Everything has to be redundant.

You have a lot of nines there buddy! But remember thats really not what everyone is after, think about the quality of your services in other ways also. To get that sort of uptime regardless, every point of failure needs to have at least two fail-overs in my opinion. Oh and also you need a huge team of sysadmins that'll wake up and night and fix anything...

share|improve this answer

If you have a non-trivial amount of data, simply waiting for rsync to build a file list is going to put you over the 5minute downtime window allowed by a 99.999% expectation.

That said, for static files, you have a few options. You can use a distributed file system to handle replication to your other sites ( of which there are many: ) or you could use DRBD to sync.

For MySQL, you'll need to either setup multi-master replication, or use DRBD to sync the underlying file systems and setup a heartbeat to handle failover between the two sites.

And given the scant amount of information you've provided, that's really all that's worth explaining.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.