Risco de iniciar o NTP no servidor de banco de dados?

Ouvi rumores de coisas ruins acontecendo nos servidores de banco de dados e correio se você alterar a hora do sistema enquanto eles estão em execução. No entanto, estou tendo dificuldades para encontrar informações concretas sobre os riscos reais.

Eu tenho um servidor Postgres 9.3 de produção rodando em um host Debian Wheezy e o tempo é baixo em 367 segundos. Posso apenas executar ntpdateou iniciar o openntp enquanto o Postgres está em execução ou isso pode causar um problema? Em caso afirmativo, qual é o método mais seguro de corrigir o tempo?

Existem outros serviços mais sensíveis a uma mudança na hora do sistema? Talvez servidores de correio (exim, sendmail, etc) ou filas de mensagens (activemq, rabbitmq, zeromq, etc)?

Os bancos de dados não gostam de etapas anteriores no tempo, portanto, você não deseja começar com o comportamento padrão de aumentar o tempo. Adicionar a -xopção à linha de comando reduzirá o tempo se o deslocamento for menor que 600 segundos (10 minutos). Na velocidade máxima de rotação, levará cerca de um dia e meio para ajustar o relógio em um minuto. Essa é uma maneira lenta, mas segura, de ajustar o tempo.

Antes de executar ntppara ajustar a hora, convém começar ntpcom uma opção como -g 2verificar o tamanho que um deslocamento está detectando. Isso definirá o deslocamento de pânico para 2 segundos, o que deve ser relativamente seguro.

Uma opção alternativa que eu usei antes que essa opção estivesse disponível era escrever um loop que redefinisse o relógio em parte de segundo a cada minuto, aproximadamente. Se você verificar se a redefinição não será alterada no segundo, isso provavelmente é seguro. Se você usar carimbos de data / hora intensamente, poderá ter registros fora de sequência.

Uma opção comum é desligar o servidor por tempo suficiente para que não haja movimento para trás do relógio. ntpou ntpdatepode ser configurado para pular o relógio para a hora correta na inicialização. Isso deve ser feito antes do banco de dados ser iniciado.

Os bancos de dados podem ser especialmente vulneráveis ​​a alterações de horário do sistema, se estiverem muito ativos e tiverem registros de data e hora nos registros internos. Em geral, se o tempo estiver atrasado, você terá muito menos problemas se saltar de repente para a frente do que se estiver à frente e de repente para trás.

Como Joffrey aponta - é muito mais frequente o aplicativo apresentar problemas com saltos repentinos de tempo do que o próprio banco de dados. A maneira mais segura de corrigir o horário é desligar o aplicativo por N + 1 minutos (onde N é o número de minutos que o relógio do sistema está adiantado) e sincronizar o horário, iniciar o NTP e reiniciar o aplicativo. Se você não aguenta tanto tempo de inatividade no aplicativo, só posso sugerir que você faça um backup do banco de dados antes da hora da sincronização e ofereça um esquilo morto ao goda do computador e aperte o gatilho. Ok, estou sendo um pouco ridículo, mas não consigo pensar em outra maneira "segura" de sofrer uma interrupção no aplicativo.

Geralmente, não é o servidor de banco de dados que está vulnerável a erros quando ocorre um salto instantâneo: são os aplicativos que usam o tempo que está.

Geralmente, existem duas maneiras de rastrear o tempo: rastrear o próprio tempo ou comparar o horário do sistema. Ambos têm algumas trocas positivas e negativas.

Rastreamento de tempo próprio

Vejo isso usado em alguns programas e sistemas embarcados em que o tempo exato não é tão crítico. Em um loop principal do aplicativo, é tratada uma maneira de rastrear um 'tick'. Este poderia ser um alarme dado pelo kernel, sleep ou select que fornece uma indicação da quantidade de tempo passado. Quando você sabe que horas são passadas, sabe que pode adicionar ou subtrair essa hora a um contador. Esse contador é o que faz o seu aplicativo de temporização acontecer. Por exemplo, se o contador for superior a 10 segundos, você poderá descartar algo ou precisará fazer algo.

Se o aplicativo não acompanhar o tempo, o contador não será alterado. Isso pode ser desejado, dependendo do design do seu aplicativo. Por exemplo, controlar quanto tempo um processo de longa execução leva para que algo seja tratado é mais fácil com um contador do que uma lista de carimbos de data / hora de início / parada.

Pró:

• Não depende do relógio do sistema
• Não vai quebrar em um grande momento skew
• Nenhuma chamada dispendiosa do sistema
• Contadores pequenos custam menos memória que um carimbo de data / hora completo

Vigarista:

• O tempo não é muito preciso
• A mudança no horário do sistema pode torná-lo ainda mais impreciso
• O tempo é relativo à execução do aplicativo, não persiste

Comparando a hora do sistema

Este é o sistema usado com mais frequência: armazene um carimbo de data e hora e compare-o com o carimbo de hora usando uma chamada de horário do sistema. Inclinações enormes no horário do sistema podem ameaçar a integridade do seu aplicativo, uma tarefa de alguns segundos pode levar horas ou terminar imediatamente, dependendo da direção do relógio.

Pró:

• Comparação precisa de tempo
• Persiste durante reinicializações e interrupções prolongadas

Vigarista:

• Faz uma chamada do sistema para obter um novo registro de data e hora para comparar com outros registros de data e hora
• O aplicativo precisa estar ciente de inclinações ou pode quebrar

Sistemas afetados

A maioria dos aplicativos utilizará o registro de data e hora para agendar tarefas. Para sistemas de banco de dados que podem ser limpezas de cache.

Todos os aplicativos que usam um banco de dados e funções de tempo de chamada no idioma da consulta serão afetados por distorções se o aplicativo não detectar e manipular adequadamente. Os aplicativos nunca poderiam parar de executar ou permitir períodos de login indefinidos, dependendo de sua finalidade.

Os sistemas de correio usarão carimbos de data e hora e / ou tempos limite para lidar com e-mails obsoletos ou não entregues. Uma inclinação do relógio pode afetar isso, mas com um impacto muito menor. Os temporizadores de retirada relativos à reconexão com os servidores podem ser perdidos, resultando em penalidades no servidor de conexão.

Eu não acho (não pesquisei) que os alarmes do kernel dispararão ao alterar a hora do sistema. Os sistemas que os utilizam podem ser seguros.

Soluções

Mova suavemente o tempo. Isso pode ser encontrado na documentação da sua solução de tempo favorita.