데이터베이스 서버에서 NTP를 시작할 위험이 있습니까?


27

데이터베이스 및 메일 서버가 실행되는 동안 시스템 시간을 변경하면 데이터베이스 및 메일 서버에 나쁜 일이 발생한다는 소문을 들었습니다. 그러나 실제 위험에 대한 구체적인 정보를 찾는 데 어려움을 겪고 있습니다.

Debian Wheezy 호스트에서 프로덕션 Postgres 9.3 서버를 실행 중이며 시간이 367 초 단축되었습니다. ntpdatePostgres가 실행되는 동안 openntp를 실행 하거나 시작할 수 있습니까 ? 아니면 문제가 발생할 수 있습니까? 그렇다면 시간을 수정하는 더 안전한 방법은 무엇입니까?

시스템 시간 변경에 더 민감한 다른 서비스가 있습니까? 메일 서버 (exim, sendmail 등) 또는 메시지 대기열 (activemq, rabbitmq, zeromq 등) 일 수 있습니까?

답변:


23

데이터베이스는 시간이 거슬러 올라가는 것을 좋아하지 않으므로 시간 이동의 기본 동작으로 시작하고 싶지 않습니다. -x오프셋이 600 초 (10 분) 미만인 경우 명령 줄에 옵션을 추가하면 시간이 줄어 듭니다. 최대 슬루 레이트에서는 시계를 1 분씩 조정하는 데 약 하루 반이 걸립니다. 이것은 시간을 조정하는 느리지 만 안전한 방법입니다.

ntp시간을 조정 하기 위해 실행하기 전에 감지하는 오프셋 크기를 확인하는 ntp것과 같은 옵션으로 시작할 수 있습니다 -g 2. 이렇게하면 패닉 오프셋이 2 초로 설정되어 비교적 안전합니다.

이 옵션을 사용하기 전에 사용한 대체 옵션은 1 분마다 초 단위로 시계를 재설정하는 루프를 작성하는 것이 었습니다. 재설정이 두 번째로 변경되지 않는지 확인하면 이것이 안전 할 것입니다. 타임 스탬프를 많이 사용하면 시퀀스 레코드가 부족할 수 있습니다.

일반적인 옵션은 시계가 뒤로 이동하지 않을 정도로 서버를 오래 종료하는 것입니다. ntp또는 ntpdate시작시 시계를 올바른 시간으로 이동하도록 구성 할 수 있습니다. 데이터베이스를 시작하기 전에 수행해야합니다.


8

데이터베이스는 매우 활동적이고 내부 레코드에 타임 스탬프가있는 경우 시스템 시간 변경에 특히 취약 할 수 있습니다. 일반적으로 시간이 뒤처진 경우, 갑자기 앞뒤로 점프하는 것보다 갑자기 앞으로 점프하면 문제가 훨씬 줄어 듭니다.

Joffrey가 지적한 것처럼, 데이터베이스 자체보다 갑자기 시간이 많이 걸리는 문제가있는 응용 프로그램이 훨씬 더 많습니다. 시간을 수정하는 가장 안전한 방법은 N + 1 분 동안 응용 프로그램을 종료 한 다음 (여기서 N은 시스템 시계가 분 단위 인 시간) 동기화 한 다음 NTP를 시작하고 응용 프로그램을 다시 시작하는 것입니다. 응용 프로그램에서 많은 다운 타임을 취할 수 없다면 시간 동기화 전에 데이터베이스 백업을 수행 한 다음 컴퓨터의 고다에 죽은 다람쥐를 제안하고 방아쇠를 당기십시오. 좋아, 나는 약간 애매하지만 응용 프로그램 중단을 취하는 것보다 다른 "안전한"방법을 생각할 수 없습니다.


나는 앞으로 약 6 분 뒤로 뒤로 이동해야합니다. 로 설정 한 많은 내부 레코드가 now()있습니다. 답변 시간을 변경하는 안전한 방법을 추가 할 수 있습니까?
hugelysuperiorman

6
ntpd가 올바르게 설치되고 구성된 경우 클럭 속도를 느리게하여 시스템 시간을 점차적으로 수정할 수 있어야합니다. 정확한 시간에 도달하면 시간을 유지하도록 드리프트가 조정됩니다. 오류를 초과하여 최대 수정을 지정해야 할 수도 있습니다. 적어도 그것이 내가 이해하는 방식이지만 NTP 전문가는 아닙니다.
Jonathan J

@JonathanJ-NTP는 5 분 이상의 시간 왜곡을 수정하는 데 어려움을 겪고 있으며 "표준"문서 (설정이 여러 세트가 있음)에 따라 설정하면 먼저 한 번의 점프로 시간을 동기화 한 다음 드리프트를 조정하여 동기화를 유지합니다.
John

@John 나는 몇 년 전에 다람쥐를 다
썼다

4

일반적으로 즉각적인 시간 도약이 발생할 때 오류에 취약한 데이터베이스 서버는 아닙니다. 해당 시간을 사용하는 응용 프로그램입니다.

시간 추적에는 일반적으로 두 가지 방법이 있습니다. 자체 시간 추적 또는 시스템 시간 비교. 둘 다 긍정적이고 부정적인 장단점이 있습니다.

자신의 시간 추적

정확한 타이밍이 그다지 중요하지 않은 일부 임베디드 프로그래밍 및 시스템에서 이것이 사용되는 것을 볼 수 있습니다. 기본 응용 프로그램 루프에서는 '틱'추적 방법이 처리됩니다. 이것은 커널에 의해 제공되는 알람, 수면 시간 또는 경과 시간을 나타내는 수면 또는 선택이 될 수 있습니다. 시간이 지났다는 것을 알면이 시간을 카운터에 더하거나 뺄 수 있습니다. 이 카운터는 타이밍 응용 프로그램을 발생시키는 원인입니다. 예를 들어, 카운터가 10 초보다 높으면 무언가를 버릴 수 있거나 무언가를해야합니다.

응용 프로그램이 시간을 추적하지 않으면 카운터가 변경되지 않습니다. 이것은 응용 프로그램의 디자인에 따라 필요할 수 있습니다. 예를 들어, 장기 실행 프로세스가 처리하는 데 걸리는 시간을 추적하면 시작 / 중지 타임 스탬프 목록보다 카운터를 사용하는 것이 더 쉽습니다.

찬성:

  • 시스템 시계에 의존하지 않음
  • 큰 시간 왜곡으로 깨지지 않습니다.
  • 비용이 많이 드는 시스템 호출 없음
  • 작은 카운터는 전체 타임 스탬프보다 적은 메모리 비용

범죄자:

  • 시간이 매우 정확하지 않습니다
  • 시스템 시간의 변화는 더욱 부정확해질 수 있습니다
  • 타이밍은 응용 프로그램 실행과 관련이 있으며 지속되지 않습니다.

시스템 시간 비교

이것은 더 자주 사용되는 시스템입니다. 타임 스탬프를 저장하고 시스템 타임 콜을 사용하여 타임 스탬프와 비교하십시오. 시스템 시간이 크게 왜곡되면 응용 프로그램의 무결성이 위협받을 수 있습니다. 시계 방향에 따라 몇 초 정도 걸리거나 몇 시간이 걸리거나 즉시 종료 될 수 있습니다.

찬성:

  • 정확한 시간 비교
  • 재시동 및 긴 정전 지속

범죄자:

  • 다른 타임 스탬프와 비교할 수있는 새로운 타임 스탬프를 얻기 위해 시스템 호출을받습니다.
  • 응용 프로그램이 기울어 짐을 알고 있거나 깨질 수 있음

영향을받는 시스템

대부분의 응용 프로그램은 일정 작업과 비교할 때 타임 스탬프를 사용합니다. 캐시 정리가 가능한 데이터베이스 시스템의 경우.

쿼리 언어에서 데이터베이스 및 호출 시간 함수를 사용하는 모든 응용 프로그램은 응용 프로그램이 그에 따라 감지 및 처리하지 않으면 기울어 짐의 영향을받습니다. 응용 프로그램은 목적에 따라 실행을 중지하거나 무한 로그인 기간을 허용 할 수 없습니다.

메일 시스템은 오래된 메일 또는 배달되지 않은 메일을 처리하기 위해 타임 스탬프 및 / 또는 타임 아웃을 사용합니다. 시계 왜곡이 영향을 줄 수 있지만 훨씬 적은 영향을 미칩니다. 서버에 다시 연결하는 것과 관련된 백 오프 타이머가 누락되어 연결 서버에 불이익을 줄 수 있습니다.

시스템 시간을 변경할 때 커널 알람이 사라질 것이라고 생각하지 않습니다 (연구하지 않았습니다). 이를 사용하는 시스템은 안전 할 수 있습니다.

솔루션

부드럽게 움직입니다. 이것은 선호하는 시간 솔루션의 문서에서 찾을 수 있습니다.


1
이것은 훌륭한 답변이며 시간을 유지하는 방법에 대해 더 많이 알게되어 감사합니다. 프로덕션 데이터베이스 서버에서 시간 조정에 대한 현재의 우려를 명확하게 해결하지 못했기 때문에 선택하지 않았습니다. 나에게 물건을 가르치는 +1
hugelysuperiorman
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.