¿Riesgo de iniciar NTP en el servidor de bases de datos?

27

He escuchado rumores de que suceden cosas malas a la base de datos y los servidores de correo si 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 Postgres 9.3 de producción que se ejecuta en un host Debian Wheezy y el tiempo de espera es de 367 segundos. ¿Puedo 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 el tiempo?

¿Hay 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.)?

— vastlysuperiorman
fuente

23

A las bases de datos no les gustan los pasos hacia atrás en el tiempo, por lo que no desea 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 de rotación máxima, llevará aproximadamente un día y medio ajustar el reloj por un minuto. Esta es una forma lenta pero segura de ajustar el tiempo.

Antes de ejecutar ntppara ajustar el tiempo, es posible que desee comenzar ntpcon una opción como -g 2verificar qué tan grande está detectando un desplazamiento. Esto establecerá la compensación de 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 restableciera la parte posterior del reloj cada segundo más o menos cada minuto. Si verifica que el reinicio no cambie en el segundo, es probable que sea seguro. Si usa muchas 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 el reloj no retroceda. ntpo ntpdatepuede configurarse para saltar el reloj a la hora correcta al inicio. Esto debe hacerse antes de que se inicie la base de datos.

— BillThor
fuente

8

Las bases de datos pueden ser especialmente vulnerables a los cambios de hora del sistema si están muy activas y tienen marcas de tiempo en los registros internos. En general, si su tiempo está atrasado, tendrá muchos menos problemas si salta repentinamente hacia adelante que si está adelante y salta repentinamente 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 adelanta el reloj del 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 goda de computerdom y simplemente apriete el gatillo. Ok, estoy siendo un poco gracioso, pero no puedo pensar en ninguna otra forma "segura" que tomar el corte de una aplicación.

— John
fuente

Estoy adelante y necesito saltar hacia atrás unos 6 minutos. Tengo muchos, muchos registros internos que se establecieron con now(). ¿Puedes agregar algún método seguro para cambiar el tiempo de tu respuesta?

— vastlysuperiorman

66

Si ntpd está instalado y configurado correctamente, debería poder corregir gradualmente la hora del sistema disminuyendo la velocidad del reloj. Una vez que se alcanza el tiempo correcto, la deriva se ajusta para mantener el tiempo. Es posible que deba especificar una corrección máxima que exceda su error. Al menos así lo entiendo, pero no soy un experto en NTP.

— Jonathan J

@JonathanJ: NTP tiene dificultades para corregir sesgos de tiempo superiores a 5 minutos, y cuando se configura por documentación "estándar" (de la cual hay varios conjuntos, es cierto) primero sincroniza el tiempo en un salto y luego mantiene la sincronización ajustando la deriva.

— John

@John Me quedé sin ardillas hace años;)

— Joffrey

4

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 las que usan el tiempo.

En general, hay dos formas de realizar un seguimiento del tiempo: seguimiento del tiempo propio o comparación del tiempo del sistema. Ambos tienen algunas compensaciones positivas y negativas.

Seguimiento del tiempo propio

Veo esto usado en algunos programas y sistemas embebidos donde el tiempo exacto no es tan crítico. En un bucle de aplicación principal, se soluciona una forma de rastrear un 'tic'. Esto podría ser una alarma dada por el núcleo, suspensión o selección 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 su aplicación de temporización suceda. Por ejemplo, si el contador es superior a 10 segundos, puede descartar algo o debe hacer algo.

Si la aplicación no registra el tiempo, el contador no cambiará. Esto puede desearse dependiendo del diseño de su aplicación. Por ejemplo, realizar un seguimiento de cuánto tiempo se está manejando un proceso de larga duración es más fácil con un contador que con una lista de marcas de tiempo de inicio / parada.

Pro:

No depende del reloj del sistema
No se romperá en un gran sesgo
No hay llamadas al sistema costosas
Los contadores pequeños costarán menos memoria que una marca de tiempo completa

Estafa:

El tiempo no es muy preciso.
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

Comparación del tiempo del sistema

Este es el sistema que se usa con más frecuencia: almacene una marca de tiempo y compárela con la marca de tiempo utilizando una llamada de tiempo del sistema. Grandes sesgos en el tiempo del sistema podrían amenazar la integridad de su aplicación, una tarea de unos pocos segundos podría llevar horas o terminar de inmediato dependiendo de la dirección del reloj.

Pro:

Comparación precisa de tiempo
Persiste sobre reinicios y largas interrupciones

Estafa:

Toma una llamada del sistema para obtener una nueva marca de tiempo para comparar con otras marcas de tiempo
La aplicación debe ser consciente de los sesgos o puede romperse

Sistemas afectados

La mayoría de las aplicaciones usarán marcas de tiempo en comparación con las tareas programadas. Para sistemas de bases de datos que podrían ser limpiezas de caché.

Todas las aplicaciones que usan una base de datos y funciones de tiempo de llamada en el lenguaje de consulta se verán afectadas por sesgos si la aplicación no detecta y maneja en consecuencia. Las aplicaciones nunca podrían dejar de ejecutarse o 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 sesgo 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 perderse, lo que generaría penalizaciones en el servidor de conexión.

No creo (no he investigado) que las alarmas del kernel se activen al cambiar la hora del sistema. Los sistemas que usan estos podrían ser seguros.

Soluciones

Mueve el tiempo suavemente. Esto se puede encontrar en la documentación de su solución de tiempo favorita.

— Joffrey
fuente

1

Esta es una gran respuesta, y agradezco aprender más sobre el mantenimiento del tiempo. No lo seleccioné porque no proporcionó una solución clara a mi preocupación actual de ajustar el tiempo en mi servidor de base de datos de producción. +1 por enseñarme cosas.

— vastlysuperiorman