Ouvi rumores de coisas ruins acontecendo com servidores de banco de dados e 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 em execução em um host Debian Wheezy e o tempo está atrasado em 367 segundos. Posso simplesmente executar ntpdateou iniciar o openntp enquanto o Postgres está em execução ou isso provavelmente causará um problema? Em caso afirmativo, qual é o método mais seguro de corrigir a hora?
Existem outros serviços que são mais sensíveis a alterações na hora do sistema? Talvez servidores de correio (exim, sendmail, etc) ou filas de mensagens (activemq, RabbitMQ, zeromq, etc)?
Responder1
Os bancos de dados não gostam de retroceder no tempo, então você não quer começar com o comportamento padrão de pular o tempo. Adicionar a -xopção à linha de comando reduzirá o tempo se o deslocamento for inferior a 600 segundos (10 minutos). Na taxa de variação máxima, levará cerca de um dia e meio para ajustar o relógio em um minuto. Esta é uma maneira lenta, mas segura, de ajustar a hora.
Antes de executar ntppara ajustar o tempo, você pode começar ntpcom uma opção como -g 2verificar o tamanho do deslocamento que está detectando. Isso definirá a compensação de pânico para 2 segundos, o que deve ser relativamente seguro.
Uma opção alternativa que usei antes que essa opção estivesse disponível era escrever um loop que reiniciasse o relógio parte de segundo a cada minuto ou mais. Se você verificar para garantir que a redefinição não mudará no segundo, isso provavelmente será seguro. Se você usar muito carimbos de data e hora, poderá ter registros fora de sequência.
Uma opção comum é desligar o servidor por tempo suficiente para que não haja retrocesso do relógio. ntpou ntpdatepode ser configurado para avançar o relógio para a hora correta na inicialização. Isso deve ser feito antes do banco de dados ser iniciado.
Responder2
Os bancos de dados podem ser especialmente vulneráveis a alterações de horário do sistema se estiverem muito ativos e tiverem carimbos de data e hora em registros internos. Em geral, se o tempo estiver atrasado, você terá muito menos problemas se pular de repente para frente do que se estiver à frente e pular para trás de repente.
Como aponta Joffrey - é muito mais comum que o aplicativo tenha problemas com saltos repentinos no tempo do que o próprio banco de dados. A maneira mais segura de corrigir a hora é desligar o aplicativo por N+1 minutos (onde N é o número de minutos que o relógio do sistema está adiantado) e, em seguida, sincronizar a hora, 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 do tempo de sincronização, depois ofereça um esquilo morto ao goda do computador e apenas aperte o gatilho. Ok, estou sendo um pouco jocoso, mas não consigo pensar em nenhuma outra maneira "segura" do que interromper a interrupção do aplicativo.
Responder3
Geralmente não é o servidor de banco de dados que fica vulnerável a erros quando ocorre um salto de tempo instantâneo: são os aplicativos que usam o tempo.
Geralmente, há duas maneiras de monitorar o tempo: monitorar o próprio tempo ou comparar o tempo do sistema. Ambos têm algumas compensações positivas e negativas.
Controle de tempo próprio
Vejo isso sendo usado em algumas programações e sistemas embarcados onde o tempo exato não é tão crítico. Em um loop principal do aplicativo, uma forma de rastrear um 'tick' é cuidada. Este pode ser um alarme dado pelo kernel, sleep ou select que dá uma indicação da quantidade de tempo passado. Quando você sabe quanto tempo passou, você sabe que pode adicionar ou subtrair esse tempo a um contador. Esse contador é o que faz sua aplicação de tempo acontecer. Por exemplo, se o contador for superior a 10 segundos você pode descartar algo, ou precisa fazer alguma coisa.
Se o aplicativo não acompanhar o tempo, o contador não será alterado. Isto pode ser desejado dependendo do design da sua aplicação. Por exemplo, acompanhar quanto tempo um processo de longa execução está demorando para que algo seja tratado é mais fácil com um contador do que com 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 uma grande distorção
- Nenhuma chamada de sistema dispendiosa
- Contadores pequenos custarão menos memória do que um carimbo de data/hora completo
Vigarista:
- O tempo não é muito preciso
- A mudança na hora do sistema pode torná-la ainda mais imprecisa
- 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/hora e compare-o com o carimbo de data/hora usando uma chamada de horário do sistema. Grandes distorções na hora 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 de tempo precisa
- Persiste durante reinicializações e interrupções longas
Vigarista:
- Faz uma chamada de sistema para obter um novo carimbo de data/hora para comparar com outros carimbos de data/hora
- O aplicativo precisa estar ciente de distorções ou pode quebrar
Sistemas afetados
A maioria dos aplicativos usará carimbo de data/hora em comparação com tarefas agendadas. 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 na linguagem de consulta serão afetados por distorções se o aplicativo não detectar e tratar adequadamente. Os aplicativos nunca poderiam parar de funcionar ou permitir períodos de login indefinidos, dependendo de sua finalidade.
Os sistemas de correio usarão carimbos de data/hora e/ou tempos limite para lidar com e-mails obsoletos ou não entregues. Uma distorção do relógio pode afetar isso, mas com um impacto muito menor. Os temporizadores de espera relativos à reconexão aos servidores podem ser perdidos, resultando em penalidades no servidor conectado.
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.