在数据库服务器上启动NTP的风险？

Question

我听说如果您在运行时更改系统时间，数据库和邮件服务器会发生坏事的传言。但是，我很难找到有关实际风险的任何具体信息。

我有一个在 Debian Wheezy 主机上运行的生产 Postgres 9.3 服务器，时间减少了 367 秒。我可以ntpdate在 Postgres 运行时运行或启动 openntp，还是可能会导致问题？如果是这样，纠正时间的更安全方法是什么？

是否有其他服务对系统时间的变化更敏感？也许是邮件服务器（exim、sendmail 等）或消息队列（activemq、rabbitmq、zeromq 等）？

Answer 1

数据库不喜欢时间倒退，因此您不想从跳过时间的默认行为开始。-x如果偏移量小于 600 秒（10 分钟），则将选项添加到命令行将缩短时间。在最大转换速率下，将时钟调整一分钟需要大约一天半的时间。这是调整时间的一种缓慢但安全的方法。

在运行ntp以调整时间之前，您可能需要从ntp一个选项开始，例如-g 2验证它检测到的偏移量有多大。这会将恐慌偏移设置为 2 秒，这应该是相对安全的。

在此选项可用之前，我使用的另一个选项是编写一个循环，每分钟左右重置秒的时钟部分。如果您检查以确保重置不会改变第二个，这可能是安全的。如果您大量使用时间戳，则可能会有乱序记录。

一个常见的选择是关闭服务器足够长的时间，以免时钟向后移动。 ntp或者ntpdate可以配置为在启动时将时钟跳转到正确的时间。这应该在数据库启动之前完成。

Answer 2

如果数据库非常活跃并且在内部记录上有时间戳，则它们特别容易受到系统时间更改的影响。一般来说，如果你的时间落后了，你突然向前跳跃的问题比你领先又突然向后跳跃的问题要少得多。

正如 Joffrey 指出的那样 - 与数据库本身相比，出现时间突然跳跃问题的应用程序更常见。更正时间的最安全方法是关闭应用程序 N+1 分钟（其中 N 是系统时钟提前的分钟数），然后同步时间、启动 NTP 并重新启动应用程序。如果您不能在应用程序中花费那么多的停机时间，我只能建议您在同步时间之前备份数据库，然后向计算机世界的上帝提供一只死松鼠，然后扣动扳机。好吧，我有点开玩笑，但除了停止应用程序之外，我想不出任何其他“安全”的方法。

Answer 3

当发生即时时间跳跃时，通常不是数据库服务器容易出错：它是使用时间的应用程序。

跟踪时间一般有两种方式：自己的时间跟踪或比较系统时间。两者都有一些积极和消极的权衡。

自己的时间跟踪

我看到在一些嵌入式编程和系统中使用了这种方法，在这些系统中，精确的时间安排并不那么重要。在主应用程序循环中，会处理跟踪“滴答”的方法。这可能是内核、睡眠或选择发出的警报，指示已过的时间量。当您知道经过了多长时间时，您就知道可以在计数器中添加或减去此时间。这个计数器是使您的计时应用程序发生的原因。例如，如果计数器高于 10 秒，您可以丢弃某些东西，或者您需要做一些事情。

如果应用程序不跟踪时间，则计数器不会改变。这可能是需要的，具体取决于您的应用程序设计。例如，与开始/停止时间戳列表相比，使用计数器更容易跟踪长时间运行的进程处理某事所花费的时间。

亲：

• 不依赖系统时钟
• 不会因大的时间偏差而中断
• 没有昂贵的系统调用
• 小计数器将比完整时间戳花费更少的内存

骗局：

• 时间不是很准确
• 系统时间的变化可能会使其更加不准确
• 时间与运行应用程序有关，不会持久

比较系统时间

这是更常用的系统：存储时间戳并使用系统时间调用将其与时间戳进行比较。系统时间的巨大偏差可能会威胁到应用程序的完整性，根据时钟的方向，几秒钟的任务可能需要几个小时或立即结束。

亲：

• 准确的时间对比
• 持续重启和长时间停机

骗局：

• 进行系统调用以获取新的时间戳以与其他时间戳进行比较
• 应用程序需要注意偏差或可能会中断

受影响的系统

与计划任务相比，大多数应用程序将使用时间戳。对于可以进行缓存清理的数据库系统。

如果应用程序没有进行相应的检测和处理，所有使用数据库和查询语言调用时间函数的应用程序都将受到偏差的影响。根据其目的，应用程序永远不会停止运行或允许无限期的登录期。

邮件系统将使用时间戳和/或超时来处理陈旧或未投递的邮件。时钟偏差可能会影响这一点，但影响要小得多。可能会错过有关重新连接到服务器的回退计时器，从而导致对连接服务器的惩罚。

我不认为（没有研究过）更改系统时间时内核警报会响起。使用这些的系统可能是安全的。

解决方案

轻轻地移动时间。这可以在您最喜欢的时间解决方案的文档中找到。