27 votos

¿Riesgo de arrancar NTP en servidor de base de datos?

He oído rumores de que las cosas malas que suceden a la base de datos y servidores de correo, si cambia la hora del sistema mientras se están ejecutando. Sin embargo, estoy teniendo un tiempo difícil encontrar ninguna información concreta sobre los riesgos reales.

Tengo una producción de Postgres 9.3 server que se ejecuta en un Debian Wheezy de host y el tiempo está apagado por 367 segundos. ¿Sólo se puede ejecutar ntpdate o iniciar openntp mientras que Postgres se está ejecutando, o que es probable que cause un problema? Si es así, ¿cuál es el método más seguro de la corrección de tiempo?

Hay otros servicios que son más sensibles a un cambio en el sistema de tiempo? Tal vez los servidores de correo (exim, sendmail, etc) o de las colas de mensajes (activemq, rabbitmq, zeromq, etc)?

24voto

BillThor Puntos 15761

Las bases de datos no como pasos hacia atrás en el tiempo, así que usted no desea que se inicie con el comportamiento predeterminado de saltar en el tiempo. La adición de la -x opción para la línea de comandos se mató el tiempo si el desplazamiento es de menos de 600 segundos (10 minutos). A la máxima velocidad de respuesta tomará alrededor de un día y la mitad para ajustar el reloj por un minuto. Este es un lento pero seguro camino para ajustar el tiempo.

Antes de ejecutar ntp para ajustar el tiempo, puede que desee empezar a ntp con una opción, como por ejemplo -g 2 a comprobar cómo es de grande un desplazamiento de fase de detección. Esto establecerá el pánico offset a 2 segundos, que debería ser relativamente seguro.

Una opción alternativa que he utilizado antes de que esta opción estaba disponible era escribir un bucle que restablecer el reloj de la parte posterior de segundo cada minuto o así. Si usted llega a asegurar el restablecimiento de no cambiar el segundo este es probablemente seguro. Si el uso de las marcas de tiempo fuertemente, usted puede tener fuera de la secuencia de registros.

Una opción común es para apagar el servidor el tiempo suficiente de que no hay ningún movimiento hacia atrás del reloj. ntp o ntpdate se puede configurar para saltar el reloj a la hora correcta en el arranque. Esto debe hacerse antes de la base de datos se inicia.

9voto

KOTJMF Puntos 623

Las bases de datos pueden ser especialmente vulnerables a los cambios de hora del sistema si son muy activos y tienen marcas de tiempo en los registros internos. En general, si tienes tiempo está detrás, tendrás muchos menos problemas si de repente salto hacia adelante que si vas delante y de repente salto hacia atrás.

Como Joffrey señala - es mucho más a menudo la aplicación que tiene problemas con la súbita tiempo salta de la base de datos. La manera más segura para corregir el tiempo es cerrar la aplicación para N+1 minutos (donde N es el número de minutos en el reloj del sistema está por delante) y, a continuación, sincronizar la hora, comenzar NTP, y reiniciar la aplicación. Si usted no puede tomar mucho tiempo de inactividad en la aplicación, sólo puedo sugerir que usted tome una copia de seguridad de la base de datos antes de la sincronización de tiempo, a continuación, ofrecer una ardilla muerta a la goda de computerdom y tire del gatillo. Ok, me estoy poniendo un poco burlón, pero no puedo pensar en ningún otro lugar "seguro" de manera que tomando una solicitud de interrupción.

5voto

Joffrey Puntos 515

Generalmente no es el servidor de base de datos que es vulnerable a error cuando un instante de tiempo salto se produce: su de las aplicaciones que utilizan el tiempo que están.

Generalmente hay dos formas de seguimiento de tiempo: tiempo de seguimiento o la comparación de sistema de tiempo. Ambos tienen algo de positivo y negativo de los equilibrios.

Tiempo de seguimiento de

Puedo ver esto en algunos incrustado de programación y sistemas donde el tiempo exacto no es crítica. En un bucle principal de la aplicación de un camino de seguimiento de una 'marca' es tomado cuidado de. Esto podría ser una alarma dada por el kernel, el sueño o seleccionar que da una indicación de la cantidad de tiempo que ha pasado. Cuando usted sabe lo que el tiempo se pasa usted sabe que usted puede agregar o restar esta vez a un contador. Este contador es lo que hace que su tiempo de aplicación de suceder. Por ejemplo, si el contador es mayor de 10 segundos puede descartar algo, o tienes que hacer algo.

Si la aplicación no mantiene un registro de tiempo, el contador no va a cambiar. Esto podría ser deseada dependiendo del diseño de la aplicación. Por ejemplo, mantener en el tiempo que un proceso de larga duración es tomar algo que se maneja es más fácil con un contador que muestra una lista de inicio/parada de marcas de tiempo.

Pro:

  • No depende de reloj del sistema
  • No se rompe en un gran tiempo de inclinación
  • No costoso sistema de llamada
  • Pequeños contadores va a costar menos memoria que una marca de tiempo completo

Con:

  • El tiempo no es muy precisa
  • Cambio en el sistema de tiempo podría hacer aún más imprecisa
  • Tiempo es relativo a la ejecución de la aplicación, no se conserva

La comparación de sistema de tiempo

Este es el sistema que se utiliza con más frecuencia: la tienda de una marca de tiempo y compararla con la fecha y hora mediante un sistema de tiempo de llamada. Enormes sesgos en el sistema de tiempo podría amenazar la integridad de su solicitud, una tarea de un par de segundos podría tomar horas o fin de inmediato dependiendo de la dirección del reloj.

Pro:

  • La hora exacta de comparación
  • Persiste por más de reinicios y cortes largos

Con:

  • Toma una llamada al sistema para obtener una nueva marca de tiempo para comparar con otras marcas de tiempo
  • La aplicación debe ser consciente de tergiversa o se puede romper

Los sistemas afectados

La mayoría de las aplicaciones de uso de la marca de tiempo en comparación a la programación de tareas. Para los sistemas de base de datos que podría ser la caché de limpieza.

Todas las aplicaciones que utilizan una base de datos y el tiempo de llamada funciones en el lenguaje de consulta que serán afectados por sesgos si la aplicación no detectar y tratar en consecuencia. Aplicaciones nunca podría dejar de ejecutar o permitir indefinido de inicio de sesión de períodos dependiendo de su propósito.

Los sistemas de correo va a utilizar las marcas de tiempo y/o los tiempos de espera para el manejo de rancio o correos no entregados. Un desfase de reloj podría afectar eso, pero con un mucho menor impacto. Back-off temporizadores con respecto a volver a conectar con los servidores podrían perderse resultando en penalidades en el servidor de conexión.

No creo (no he investigado) que el kernel de alarmas se apagará cuando se cambia la hora del sistema. Los sistemas que utilizan estas podrían ser seguros.

Soluciones

Mueva suavemente el tiempo. Esto se puede encontrar en la documentación de su momento favorito de la solución.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: