我们被要求提供一个中央数据库服务器继续运行的系统，即使在将安全更新应用到服务器的操作系统或数据库服务器软件时也是如此。 据我所知，这包括需要服务器重新启动的安全更新。
集群技术看起来很明显，但是如果一个服务器可以真正重新启动而集群正在使用，我有几个问题：
在定期维护期间，包括重启操作系统在内，根本没有中断 ？ Oracle RAC。 这是我能想到的唯一真正的select，当然也是我唯一相信的平行集群数据库。 即使是RAC，有时候也需要下载数据库补丁，但大部分都可以在运行时应用。
如果您可以处理至less10-15秒的停机时间，则还有其他一些选项，包括应用程序级别的集群（Veritas集群，Microsoft集群，Oracle集群件）或数据库级别的复制。 虚拟基础架构本身并没有什么帮助。 操作系统仍然不得不停下来。
还可以将复制的数据库与多宿主客户端组合起来，以实现不间断的生产，尽pipe目前无法logging任何此类客户端的名称。
我可能会补充说，你可能会想用某种* NIX来让它们重新启动到最低限度。 据我所知，在过去几年里，只有一个更新值得在RHEL和OEL上重新启动。
Oracle RAC是一个并行集群。 数据库存储在共享存储上，并且被所有节点同时访问。 如果做得对，应该在大多数情况下提高整体性能，并且在查询响应时间中几乎没有差别。 然而，这是一项复杂的技术，正确的做法远不是微不足道的。
还有一些其他的并行技术可以承诺五个九（99,999％的正常运行时间，相当于每年5分钟的停机时间），但是它们要么太旧（VAX）要么太新（NDB）。
一个可靠的系统和一个零停机时间的区别是把铝球放进低地球轨道和把人放在月球上并安全地返回。
我会看看这样做的老办法，在我看来，这是你应该看看，如果你需要它第一次工作，而不是打击预算。
旧的standbys是OpenVMS集群和Tandem（现在的HP）NonStop。 这两个都是为几台运行完全相同的数据库和相同代码的计算机而devise的。 两者都旨在提供100％的正常运行时间，即使通过操作系统和软件升级和补丁。 两者都有一个经过validation的，长达数十年的正确工作logging。
现在，有些现代的东西可以在纸上提供。 实际上，你会遇到像“ oops，我们的许可证服务器犯了一个错误，现在你的虚拟机无法启动的问题” 。 在十年之内，我确信这些技术将被testing并被certificate是可靠的，但是在那之前，如果你需要它的工作，对于你相信的故事要非常保守。
最后，使系统可靠的最重要的事情是devise好，build造好，并妥善保pipe，因为在实践中，方程中最不可靠的事情是键盘背后的人。
MySQL集群http://www.mysql.com/products/database/cluster/
有几种方法可以解决这个问题。 当你从一个节点移动到另一个节点时，操作系统级别的集群可以工作，并发生短暂的中断。 你没有指定你的操作系统平台。 大多数NIX平台都有强大的集群解决scheme。
就数据库平台而言，Oracle与RAC共享一切方法，您可以closures一个节点，一切都将移动到群集中的其他节点。 它允许您在节点上进行维护，而其他节点则继续运行并为客户端提供服务。 他们都使用相同的一组磁盘。 对性能的影响取决于硬件的大小，大多数地方将硬件规模调整到N + 1容量，以确保在执行此类活动时性能不受影响。
Informix在最新版本中有类似的东西。 DB2应该尽快得到这个。
我相信唯一的方法就是使用集群 。 您将需要将多个数据库服务器组合到一个群集中。 然后一个服务器可以自动接pipe另一个失败的服务器。 这被称为“故障转移”（或高可用性群集）。
为了解决您的问题：
哪些数据库产品可以这样做？
所有宣传“集群支持”。 我知道至less有MySQL和Oracle，但是许多其他DBMS也可能支持它。
它是如何工作的？ 它是否同时在所有服务器上存储数据库数据，还是在重新启动时将一个服务器的任务转移到另一个服务器？
都。 服务器定期同步他们的数据，所以它保留在所有服务器上。 至于哪个服务器实际响应请求，有两种select：在一个负载均衡集群中，所有服务器共享负载（这样你可以获得更好的性能），在一个高可用性集群中，一台计算机正常工作，而如果失败（故障转移），备用接pipe。
它如何影响性能，尤其是查询的延迟？
对不起，我没有这方面的经验。 通常，开销应该是最小的，但故障转移可能需要一些时间并导致超时。
我还没有听说过其他一些提到的解决scheme，所以我不能和他们比较，但是由于我没有看到我在这里熟悉的那个，所以我也会提到它。
这是在DRBD文件系统之上的MySQL 。 用这里描述的 linux心跳
我们用了几年，没有真正的停机时间。 我们唯一的问题是我们在虚拟机上运行我们的集群，它确实需要在它们之间有多条path的物理盒子（如以太网和串行电缆等）
这种方式的工作原理是，DRBD就像在多台机器上进行扫描一样，使底层文件系统在两台或多台主机之间保持连续同步，而心跳只允许文件系统/数据库一次只能在一台服务器上运行。
一旦发生故障时，故障转移速度非常快 – 如果机器之间的连接冗余且非常可靠，则可以更快地进行调整。 （这是我们使用虚拟机的问题）。 而且，通过在重新启动计划之前进行故障排除，即使这样也可以最小化。
2种方法可以做到这一点，VMware FT（尽pipe限于1个CPU），另一种是集群技术。
VMware FT具有0个延迟问题，但限制为1个CPU，而群集解决scheme通常在TCP会话故障转移到新服务器时发生大约15秒的“故障转移”时间，旧TCP会话超时，包括ARP刷新在本地networking上。
MS SQL可以跨多个服务器群集 – 需要来自不同服务器的共享磁盘。 MySQL可以跨多个节点复制具有主/从关系的数据。 Oracle RAC将创build具有多个节点的集群。 Sybase代表服务器可以跨多个服务器复制数据。
而且，是的，您可以在VMWare中运行所有内容，然后使用FT或Motion将操作系统移动到与存储在SAN中的数据一起运行的节点上。
我会说一个方法来做到这一点将是使用MySQL的主 – 主复制。 确保您的应用程序是多宿主的，如果第一个主服务器不可用，那么您可以将一个主服务器closures，而另一个则保持同时读取和写入。 当您的第二台服务器回来时，只需将其翻转即可。 表插入发生与PK值相隔2分开，而不是1分开，但这很好，这只是一个关键。
即使安装了数据库服务器软件（虚拟或物理）的计算机正在重新启动，我也寻找可以保持事务处于开放状态的解决scheme。
我认为你需要看看HA-JDBC来满足这个要求： http : //ha-jdbc.sourceforge.net/
“高可用性/容错 – HA-JDBC数据库集群可能会丢失节点，而不会失败/破坏打开的事务。”
干杯
与Windows群集的MSSQL将处理0宕机维护窗口提供您在您开始工作之前您工作的节点失败。 此外，您需要在主机上configurationNLB以确保所有连接都通过共享IP地址进行处理（否则，服务器重试dns时可能会有2秒或更长时间的停机时间等）。 为了使集群工作，您需要共享存储arrays，如iSCSI，以及2个或更多的物理主机（pipe理程序也需要升级）。
这里有一些关于什么样的环境的相当不错的信息，但是基本上如果你不能停机的话，你至less需要有一个MS SQL DBA随时待命，以确保所有的故障转移都能正确地发生，任何东西都不便宜。 打电话给微软，按照他们的书，或者更好地把你的应用程序放在Azure的云上，或者专门从事高可用性的专用服务器供应商。