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

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

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

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

数据库不喜欢时间上的后退，因此您不想从默认的跳过时间开始。-x如果偏移量少于600秒（10分钟），则将选项添加到命令行将改变时间。以最大摆率，大约需要一天半才能将时钟调整一分钟。这是一种缓慢但安全的时间调整方法。

在运行ntp调整时间之前，您可能希望先ntp使用一个选项-g 2来验证其检测到的偏移量。这会将恐慌偏移设置为2秒，这应该是相对安全的。

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

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

如果数据库非常活跃并且内部记录上带有时间戳，则数据库特别容易受到系统时间更改的影响。通常，如果您的时间落后了，那么如果您突然向前跳跃，则问题要少得多，而如果您前进并突然向后跳跃，那么问题就会少得多。

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

通常不是数据库服务器在发生瞬时时间飞跃时容易出错，而是使用时间的应用程序。

通常有两种跟踪时间的方法：自己的时间跟踪或比较系统时间。两者都有一些正面和负面的权衡。

自己的时间追踪

我看到在一些嵌入式编程和系统中使用了这种方法，而精确的时序并不是那么关键。在主应用程序循环中，采用了一种跟踪“刻度”的方法。这可能是内核，睡眠或选择所给出的警报，它指示经过的时间量。当您知道经过了什么时间后，便可以将此时间加或减到计数器上。该计数器是使您的计时应用程序发生的原因。例如，如果计数器高于10秒，则可以丢弃某些内容，或者您​​需要执行某些操作。

如果应用程序不跟踪时间，则计数器不会更改。根据您的应用程序的设计，这可能是理想的。例如，与开始/停止时间戳列表相比，使用计数器来跟踪长时间运行的过程花费了多长时间是容易的。

优点：

• 不依赖于系统时钟
• 不会因大的时间扭曲而中断
• 无需昂贵的系统调用
• 小计数器将比完整时间戳花费更少的内存

缺点：

• 时间不是很准确
• 系统时间的更改可能使其更加不准确
• 时间是相对于运行应用程序而言的，不会持久

比较系统时间

这是更常用的系统：存储时间戳，并使用系统时间调用将其与时间戳进行比较。系统时间的巨大偏差可能会威胁到应用程序的完整性，几秒钟的任务可能要花费数小时或立即终止，具体取决于时钟的方向。

优点：

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

缺点：

• 进行系统调用以获取新的时间戳以与其他时间戳进行比较
• 应用程序需要注意歪斜，否则可能会损坏

受影响的系统

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

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

邮件系统将使用时间戳记和/或超时来处理陈旧或未送达的邮件。时钟偏斜可能会影响这一点，但影响要小得多。与重新连接到服务器有关的退避计时器可能会丢失，从而导致连接服务器受到惩罚。

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

解决方案

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