He escuchado rumores de que suceden cosas malas en las bases de datos y en los servidores de correo si se cambia la hora del sistema mientras se están ejecutando. Sin embargo, me cuesta encontrar información concreta sobre los riesgos reales.
Tengo un servidor de producción Postgres 9.3 ejecutándose en un host Debian Wheezy y el tiempo tiene un retraso de 367 segundos. ¿Puedo simplemente ejecutar ntpdateo iniciar openntp mientras se ejecuta Postgres, o es probable que eso cause un problema? Si es así, ¿cuál es un método más seguro para corregir la hora?
¿Existen otros servicios que sean más sensibles a un cambio en la hora del sistema? ¿Quizás servidores de correo (exim, sendmail, etc.) o colas de mensajes (activemq, Rabbitmq, zeromq, etc.)?
Respuesta1
A las bases de datos no les gustan los pasos hacia atrás en el tiempo, por lo que no querrás comenzar con el comportamiento predeterminado de saltar el tiempo. Agregar la -xopción a la línea de comando reducirá el tiempo si el desplazamiento es inferior a 600 segundos (10 minutos). A la velocidad máxima de giro, tardará aproximadamente un día y medio en ajustar el reloj en un minuto. Esta es una forma lenta pero segura de ajustar la hora.
Antes de ejecutar ntppara ajustar el tiempo, es posible que desee comenzar ntpcon una opción como -g 2verificar qué tan grande es el desplazamiento que está detectando. Esto establecerá la compensación del pánico en 2 segundos, lo que debería ser relativamente seguro.
Una opción alternativa que he usado antes de que esta opción estuviera disponible era escribir un bucle que reinicia el reloj hacia atrás un segundo cada minuto aproximadamente. Si verifica que el reinicio no cambie en el segundo, probablemente sea seguro. Si utiliza mucho las marcas de tiempo, es posible que tenga registros fuera de secuencia.
Una opción común es apagar el servidor el tiempo suficiente para que no haya retroceso del reloj. ntpo ntpdatese puede configurar para saltar el reloj a la hora correcta al inicio. Esto debe hacerse antes de iniciar la base de datos.
Respuesta2
Las bases de datos pueden ser especialmente vulnerables a los cambios de hora del sistema si son muy activas y tienen marcas de tiempo en los registros internos. En general, si llevas tiempo atrasado, tendrás muchos menos problemas si de repente saltas hacia adelante que si vas adelante y de repente saltas hacia atrás.
Como señala Joffrey, es mucho más frecuente que la aplicación tenga problemas con saltos repentinos de tiempo que la propia base de datos. La forma más segura de corregir la hora es cerrar la aplicación durante N+1 minutos (donde N es la cantidad de minutos que se adelanta el reloj de su sistema) y luego sincronizar la hora, iniciar NTP y reiniciar la aplicación. Si no puede tomar tanto tiempo de inactividad en la aplicación, solo puedo sugerirle que haga una copia de seguridad de la base de datos antes de sincronizar el tiempo, luego ofrezca una ardilla muerta al dios de la informática y simplemente apriete el gatillo. Ok, estoy siendo un poco bromista, pero no se me ocurre ninguna otra forma "segura" que interrumpir la aplicación.
Respuesta3
Por lo general, no es el servidor de la base de datos el que es vulnerable a errores cuando ocurre un salto de tiempo instantáneo: son las aplicaciones que usan el tiempo.
Generalmente hay dos formas de realizar un seguimiento del tiempo: realizar un seguimiento del tiempo propio o comparar el tiempo del sistema. Ambos tienen algunas compensaciones positivas y negativas.
Seguimiento del tiempo propio
Veo que esto se usa en algunos sistemas y programación integrados donde el tiempo exacto no es tan crítico. En un bucle de aplicación principal se cuida una forma de rastrear un 'tic'. Esto podría ser una alarma dada por el kernel, sleep o select que da una indicación de la cantidad de tiempo transcurrido. Cuando sabes qué tiempo pasa, sabes que puedes sumar o restar este tiempo a un contador. Este contador es lo que hace que funcione su aplicación de cronometraje. Por ejemplo, si el contador es superior a 10 segundos, puedes descartar algo o necesitas hacer algo.
Si la aplicación no realiza un seguimiento del tiempo, el contador no cambiará. Esto podría ser deseable dependiendo del diseño de su aplicación. Por ejemplo, hacer un seguimiento de cuánto tiempo tarda un proceso de larga duración en procesarse algo es más fácil con un contador que con una lista de marcas de tiempo de inicio/detención.
Pro:
- No depende del reloj del sistema
- No se romperá en un gran sesgo
- Sin costosas llamadas al sistema
- Los contadores pequeños costarán menos memoria que una marca de tiempo completa
Estafa:
- El tiempo no es muy exacto.
- El cambio en la hora del sistema podría hacerlo aún más inexacto
- El tiempo es relativo a la ejecución de la aplicación, no persiste
Comparando el tiempo del sistema
Este es el sistema que se usa con más frecuencia: almacena una marca de tiempo y compárala con la marca de tiempo usando una llamada de tiempo del sistema. Grandes desviaciones en la hora del sistema podrían amenazar la integridad de su aplicación, una tarea de unos pocos segundos podría tardar horas o finalizar inmediatamente dependiendo de la dirección del reloj.
Pro:
- Comparación de tiempo precisa
- Persiste durante reinicios e interrupciones prolongadas.
Estafa:
- Toma una llamada al sistema para obtener una marca de tiempo nueva para compararla con otras marcas de tiempo.
- La aplicación debe tener en cuenta las distorsiones o posibles roturas.
Sistemas afectados
La mayoría de las aplicaciones utilizarán marcas de tiempo para comparar las tareas programadas. Para sistemas de bases de datos que podrían ser limpiezas de caché.
Todas las aplicaciones que utilizan una base de datos y llaman a funciones de tiempo en el lenguaje de consulta se verán afectadas por sesgos si la aplicación no las detecta ni las maneja en consecuencia. Las aplicaciones nunca podrían dejar de ejecutarse ni permitir períodos de inicio de sesión indefinidos según su propósito.
Los sistemas de correo utilizarán marcas de tiempo y/o tiempos de espera para manejar correos obsoletos o no entregados. Un desfase del reloj podría afectar eso, pero con un impacto mucho menor. Los temporizadores de retroceso relacionados con la reconexión a los servidores podrían omitirse, lo que provocaría sanciones en el servidor que se conecta.
No creo (no he investigado) que las alarmas del kernel se activen al cambiar la hora del sistema. Los sistemas que los utilizan podrían ser seguros.
Soluciones
Mueve suavemente el tiempo. Esto se puede encontrar en la documentación de su solución de tiempo favorita.