我一直在为数据中心之间的MySQL研究高可用性（HA）解决scheme。 对于位于同一物理环境中的服务器，我倾向于使用主动被动方法的心跳（浮动VIP）双主控。 心跳通过串行连接以及以太网连接。 最终，我的目标是保持相同的可用性级别，但是在数据中心之间。 我希望在两个数据中心之间进行dynamic故障切换而无需人工干预，并仍然保持数据完整性 上面会有BGP。 两个地点的networking集群，这将有可能通过双方之间的数据库。 如果在站点1上的Internet连接断开，则如果两个站点之间的链接仍处于运行状态，则客户端将通过站点2路由到Web群集，然后再到站点1中的数据库。 在这种情况下，由于缺乏物理链接（系列），更有可能分裂大脑。 如果广域网在两个站点之间发生故障，那么VIP将在两个站点上结束，在这两个站点上，各种令人不快的情况可能会导致asynchronous。 我看到的另一个潜在问题是，将来这个基础设施难以扩展到第三个数据中心。 networking层不是重点。 在这个阶段架构是灵活的。 同样，我的重点是维护数据完整性的解决scheme以及MySQL数据库的自动故障转移。 我可能会围绕这个devise其余的。 你能推荐一个经过validation的解决scheme吗？ 感谢您抽出时间来阅读。 我期待着阅读你的build议。
我很熟悉BBWC（电池支持的写入caching）打算做什么 – 以前曾在我的服务器中使用它们，即使是使用良好的UPS。 有不可预料的失败，它不提供保护。 我很好奇它是否真的在实践中提供了实际的好处。 （注意，我特别寻找那些有BBWC的人的反应，并且有崩溃/失败，以及BBWC是否帮助恢复） 更新 经过这里的反馈，我越来越怀疑BBWC是否增加了任何价值。 为了对数据完整性有信心，文件系统必须知道数据何时被提交到非易失性存储器（不一定是磁盘 – 我将回到这一点）。 值得注意的是，当数据被提交到磁盘时，大量的磁盘都是谎言（ http://brad.livejournal.com/2116715.html ）。 虽然认为禁用磁盘caching可能会使磁盘更加诚实似乎是合理的，但仍然不能保证也是如此。 由于BBWC中的缓冲区很大，因此屏障可能需要将更多的数据提交到磁盘，从而导致写入延迟：一般的build议是在使用非易失性回写高速caching时禁用屏障（并禁用片上caching）磁盘caching）。 然而，这似乎破坏了写入操作的完整性 – 仅仅因为在非易失性存储中维护更多的数据并不意味着它会更加一致。 实际上，逻辑交易之间可以说没有划分，似乎没有机会确保一致性。 如果BBWC在数据input到非易失性存储（而不是承诺磁盘）的时候承认存在障碍，那么它似乎满足数据完整性要求，而不会有性能损失 – 这意味着应该仍然启用障碍。 然而，由于这些设备通常performance出与将数据刷新到物理设备（显着慢于屏障）和广泛的禁用屏障的build议一致的行为，因此它们不能以这种方式performance。 为什么不？ 如果操作系统中的I / O被build模为一系列stream，那么当写caching由OSpipe理时，有一定范围可以最小化写屏障的阻塞效应 – 因为在此级别只有逻辑事务（单个stream）需要承诺。 另一方面，不知道哪些数据位构成事务的BBWC将不得不将其整个caching提交到磁盘。 在实践中，内核/文件系统是否真正实现了这一点，需要比我现在想要投资的更多的努力。 磁盘组合告诉fib什么已经承诺和突然失去权力无疑会导致腐败 – 和一个Journalling或日志结构的文件系统，在停电后不能完全fsck不太可能检测到腐败，更不用说了试图修复它。 就故障模式而言，根据我的经验，大多数突然断电都是由于主电源断电（容易通过UPS进行缓解以及pipe理关机）而发生的。 人们把错误的电缆从机架中拉出来意味着数据中心的不良（标签和电缆pipe理）。 有些types的突然掉电事件不会被UPS阻止 – 在PSU或VRM故障时，带有障碍的BBWC将在这里出现故障时提供数据完整性，但是这种事件有多普遍？ 在这里没有回应，这是非常罕见的。 当然，将堆栈中的容错移动到更高的位置是比BBWC更昂贵的 – 但是，将服务器作为群集来实现，对于性能和可用性还有很多其他好处。 另一种减轻突然断电影响的方法是实施一个SAN-AoE，使其成为一个实际的主张（我在iSCSI中并没有真正看到这一点），但是成本更高。
我为SSL证书创build了一个RSA密钥对，并将私钥存储在/etc/ssl/private/server.key 。 不幸的是，这是我拥有的唯一私钥。 然后我不小心覆盖了磁盘上的文件（是的，我知道）。 Apache仍在运行，仍在服务于SSL请求，这让我相信恢复私钥有希望。 （也许在/proc或某个地方有一个符号链接？） 该服务器运行Ubuntu 12.04 LTS。
我负责领导一个关于更新旧有的灾难恢复计划的项目。 现在我们只是想把DR的IT方面整理出来。 上一次他们这样做时，他们设定了一个单一的灾难（数据中心被洪水淹没），并计划排除所有其他灾难types。 我想采取更全面的方法。 我知道这是一个解决的问题，其他组织已经制定了灾难恢复计划。 我们的计划是采取我们的IT灾难恢复计划，然后继续说：“嘿，这是我们在IT灾难恢复计划中所需要的，是否与大学的其他部分相匹配？是否有恢复服务的重要性我想改变一下吗？“ 我们有一个很好的主意，其余的计划是什么，我们期待这样的结果。 我正在寻找的是如何规划灾难恢复计划的指导以及我应该考虑的问题。 您是否拥有与灾难恢复计划发展相关的资源，书籍和培训？
服务器A曾经是一个NFS服务器。 服务器B正在挂载一个导出。 一切（曾经）都很好。 然后A死了。 刚刚关掉。 不见了。 消失了。 然而，该文件夹仍然安装在B.我显然不能cd到它或任何东西。 然而， umount /mnt/myfolder只是挂起，不会卸载。 无论如何卸载它，而无需重新启动B？ 客户端和服务器都是Linux机器。
我们最近经历了一场飓风，我们的服务器房间被淹了。 万岁保险。 无论如何，我需要从尽可能多的硬盘上保存尽可能多的数据。 是的，它在两天的好时间里被淹没了。 我是否需要打开驱动器并确保它是免水的？ 我应该把底板取下，然后把泡沫擦干？ 我需要什么 任何build议将是有益的。 提前致谢！
我们正在通过RFP程序来改变我们大部分服务器（~10个function相当强大的主机和数据库服务器）的托pipe公司。 当select现有的公司时，我不在公司，过去也没有与托pipe公司合作过（在以前的公司中总是有现场硬件）。 我们将在接下来的几周内为每家公司进行实地考察。 你通常寻找什么types的东西？ 问他们现场的工作人员等？ 任何可以帮助我评估和比较的东西。 大多数托pipe公司维护VM Ware农场，通过光纤连接DR站点。
用户不能收到他们的电子邮件，首席执行官不能到达公司的主页，而你的传呼机只是以“911”代码进行。 一切都爆炸了，你做什么？
我们的build筑位于约。 距爆炸物100米。 他们每天发生好几次，真的很震动整个build筑物。 这将持续很多天，爆炸事件应该会变得更强。 我们的服务器房间没什么特别的; 其中一个架子全部用硬质混凝土制成，而另一个则有一个活动地板（让电缆穿过地板）。 有没有人有任何提示，对策或最佳做法？ 目前我们正在考虑采取以下对策： 每日报告服务器机房状态指示灯（HD灯，电源等）。 每晚检查最重要的服务器上的磁盘扫描 额外供应备用硬盘 编辑：这里有很多好的答案！ 但是需要被接受。 在这个编辑的时候，最高票数的答案会被接受。