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

Question

Eu ouvi rumores de coisas ruins acontecendo com bancos de dados e servidores de e-mail se você alterar a hora do sistema enquanto eles estão em execução. No entanto, estou tendo dificuldade em 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 de inatividade é de 367 segundos. Posso apenas executar ntpdate ou iniciar o openntp enquanto o Postgres está sendo executado 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 alteração na hora do sistema? Talvez servidores de correio (exim, sendmail, etc) ou filas de mensagens (activemq, rabbitmq, zeromq, etc)?

    

Answer 1

Bancos de dados não gostam de retrocessos no tempo, então você não quer começar com o comportamento padrão de saltar o tempo. Adicionar a opção -x à linha de comando irá reduzir o tempo se o deslocamento for menor que 600 segundos (10 minutos). Na taxa de variação máxima, levará cerca de um dia e meio para ajustar o relógio por um minuto. Esta é uma maneira lenta mas segura de ajustar o tempo.

Antes de executar ntp para ajustar a hora, você pode querer iniciar ntp com uma opção como -g 2 para verificar o tamanho de um deslocamento que está detectando. Isso definirá o deslocamento do pânico para 2 segundos, o que deve ser relativamente seguro.

Uma opção alternativa que eu usei antes de esta opção estar disponível era escrever um loop que redefinisse o relógio parte posterior do segundo a cada minuto, aproximadamente. Se você verificar para garantir que a redefinição não mudará na segunda, isso provavelmente é seguro. Se você usa timestamps pesadamente, você pode ter registros fora de seqüência.

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

    

Answer 2

Bancos de dados podem ser especialmente vulneráveis a mudanças de hora do sistema se eles forem muito ativos e tiverem registros de data e hora em registros internos. Em geral, se você estiver com tempo, você terá muito menos problemas se de repente pular para frente do que se estiver à frente e, de repente, pular para trás.

Como Joffrey aponta - é muito mais frequente o aplicativo que tem problemas com saltos de tempo repentinos do que o próprio banco de dados. A maneira mais segura de corrigir o tempo é desligar o aplicativo por N + 1 minutos (onde N é o número de minutos que o relógio do sistema está adiantado) e depois sincronizar o tempo, iniciar o NTP e reiniciar o aplicativo. Se você não pode levar tanto tempo de inatividade no aplicativo, só posso sugerir que você faça um backup do banco de dados antes de sincronizar o tempo, depois ofereça um esquilo morto para o goda do computerdom e apenas aperte o gatilho. Ok, estou sendo um pouco brincalhão, mas não consigo pensar em nenhum outro modo "seguro" do que em interromper a aplicação.

    

Answer 3

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

Geralmente, existem duas maneiras de acompanhar o tempo: rastreamento de tempo próprio ou comparação do tempo do sistema. Ambos têm algumas compensações positivas e negativas.

Acompanhamento de tempo próprio

Eu vejo isso usado em alguns sistemas e programação incorporados, onde o tempo exato não é tão crítico. Em um loop de aplicativo principal, uma maneira de rastrear um 'tick' é resolvida. Isso pode ser um alarme dado pelo kernel, sleep ou select, que dá uma indicação da quantidade de tempo passada. Quando você sabe que horas são passadas, você sabe que pode adicionar ou subtrair esse tempo a um contador. Este contador é o que faz a sua aplicação de sincronismo acontecer. Por exemplo, se o contador for maior que 10 segundos, você pode descartar algo ou precisa 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 o tempo de duração de um processo de execução demorada é mais fácil com um contador do que com uma lista de timestamps de início / parada.

Pro:

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

Con:

• O tempo não é muito preciso
• A alteração na hora do sistema pode tornar ainda mais imprecisa
• O tempo é relativo à execução do aplicativo, não persiste

Comparando a hora do sistema

Esse é o sistema usado com mais frequência: armazene um registro de data e hora e compare-o com o registro de data e hora usando uma chamada de hora do sistema. Enormes distorções no tempo 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.

Pro:

• Comparação de tempo exata
• Persiste sobre reinicializações e longas indisponibilidades

Con:

• Faz uma chamada do sistema para obter um novo timestamp para comparar com outros timestamps
• O aplicativo precisa estar ciente de distorções ou pode quebrar

Sistemas afetados

A maioria dos aplicativos usará o registro de data e hora em comparação às tarefas de agendamento. 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 funcionar ou permitir períodos de login indefinidos, dependendo de sua finalidade.

Os sistemas de e-mail usarão registros de data e hora e / ou tempos limite para tratar de mensagens antigas ou não entregues. Uma distorção de relógio poderia afetar isso, mas com um impacto muito menor. Temporizadores de desligamento relacionados à reconexão a servidores podem ser perdidos, resultando em penalidades no servidor de conexão.

Eu não acho (não pesquisei) que os alarmes do kernel irão disparar ao mudar a hora do sistema. Sistemas que usam estes podem ser seguros.

Soluções

Gentilmente mova o tempo. Isso pode ser encontrado na documentação de sua solução de tempo favorita.