我正在寻找一种解决方案，以确保我的网站在长期内尽可能保持可访问性，我可能需要的只是一个简单的 DNS 管理解决方案（我不知道，但我希望得到您的帮助）。
我们有一个主服务器
我们计划执行 r-sync（同步文件）并采用另一种解决方案同步（备份）MYSQL 数据库。
如果我们的网站出现故障，我们已经设置了即时短信/电子邮件通知。
因此，我正在寻找最佳解决方案，以便几乎立即切换到备份服务器。
我知道我可以设置多个名称服务器，但据我所知，它们可能会超时或者需要 2-5 秒才能加载，这两种情况我都想避免。
那么对于我来说最好的解决方案是什么？
另外，一旦主服务器可用，我如何确保它获取在备份服务器上完成的数据库/文件编辑？
谢谢
答案1
您所要求的绝不是简单、一成不变的事情。您不可能只是从货架上取下一些东西，就能奇迹般地拥有 5 个 9 的正常运行时间。
对于纯静态内容的网站，您可以使用冗余 DNS 服务器和冗余内容服务器（或 CDN）轻松完成一些工作。我不会说纯静态内容网站的 5 个 9 的正常运行时间是微不足道的，但肯定不会太难。
但我无法想象你有一个包含静态内容的网站。
当您问“...我如何确保它获取在备份服务器上完成的数据库/文件编辑？”时，您的问题就变成了一个巨大的、不平凡的问题。有些人靠回答您针对不同数据库平台、Web 框架和现成应用程序的问题为生。
答案2
这个问题有很多问题。通常在 SLA 中提供这种正常运行时间的服务具有大量冗余，从发电机到网络交换机和其他设施中的数据中心等，不胜枚举。一切都必须是冗余的。
你有很多 9，伙计！但请记住，这并不是每个人都想要的，还要从其他方面考虑你的服务质量。无论如何，要获得这种正常运行时间，我认为每个故障点都需要至少两次故障转移。哦，你还需要一个庞大的系统管理员团队，他们会夜以继日地修复任何问题……
答案3
如果您有大量的数据，只需等待 rsync 构建文件列表就会超过 99.999% 预期允许的 5 分钟停机时间窗口。
也就是说，对于静态文件，您有几个选择。您可以使用分布式文件系统来处理到其他站点的复制（其中有很多：http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_parallel_fault-tolerant_file_systems）或者您可以使用 DRBD 进行同步。
对于 MySQL，您需要设置多主复制，或者使用 DRBD 同步底层文件系统并设置心跳来处理两个站点之间的故障转移。
鉴于您提供的信息量很少，这确实都是值得解释的。