데이터베이스와 메일 서버가 실행되는 동안 시스템 시간을 변경하면 문제가 발생한다는 소문을 들었습니다. 그러나 실제 위험에 대한 구체적인 정보를 찾는 데 어려움을 겪고 있습니다.
Debian Wheezy 호스트에서 실행되는 프로덕션 Postgres 9.3 서버가 있고 시간이 367초 차이납니다. Postgres가 실행되는 동안 openntp를 실행하거나 시작할 수 있습니까 ntpdate? 아니면 문제가 발생할 가능성이 있습니까? 그렇다면 시간을 수정하는 더 안전한 방법은 무엇입니까?
시스템 시간 변경에 더 민감한 다른 서비스가 있습니까? 메일 서버(exim, sendmail 등)나 메시지 대기열(activemq, Rabbitmq, zeromq 등)일까요?
답변1
데이터베이스는 시간의 역방향 단계를 좋아하지 않으므로 시간을 건너뛰는 기본 동작으로 시작하고 싶지 않습니다. -x오프셋이 600초(10분) 미만인 경우 명령줄에 옵션을 추가하면 시간이 느려집니다. 최대 슬루율에서는 시계를 1분 단위로 조정하는 데 약 하루 반이 걸립니다. 이것은 시간을 조정하는 느리지만 안전한 방법입니다.
시간을 조정하기 위해 실행하기 전에 감지되는 오프셋의 크기를 확인하는 것과 같은 옵션부터 ntp시작하는 것이 좋습니다 . 이렇게 하면 패닉 오프셋이 상대적으로 안전한 2초로 설정됩니다.ntp-g 2
이 옵션을 사용할 수 있기 전에 내가 사용한 대체 옵션은 매분마다 초의 시계 뒤로 부분을 재설정하는 루프를 작성하는 것이었습니다. 재설정이 두 번째를 변경하지 않는지 확인하면 안전할 수 있습니다. 타임스탬프를 많이 사용하면 순서가 맞지 않는 레코드가 생길 수 있습니다.
일반적인 옵션은 시계가 뒤로 이동하지 않을 때까지 서버를 종료하는 것입니다. ntp또는 ntpdate시작 시 시계를 정확한 시간으로 점프하도록 구성할 수 있습니다. 이는 데이터베이스가 시작되기 전에 수행되어야 합니다.
답변2
데이터베이스는 매우 활동적이며 내부 기록에 타임스탬프가 있는 경우 시스템 시간 변경에 특히 취약할 수 있습니다. 일반적으로 시간이 뒤처져 있다면 앞서 있다가 갑자기 뒤로 뛰어오르는 것보다 갑자기 앞으로 뛰어오르는 것이 문제가 훨씬 적습니다.
Joffrey가 지적했듯이, 데이터베이스 자체보다 갑작스러운 시간 점프 문제가 있는 애플리케이션이 훨씬 더 자주 발생합니다. 시간을 수정하는 가장 안전한 방법은 N+1분(여기서 N은 시스템 시계보다 빠른 분 수) 동안 애플리케이션을 종료한 다음 시간을 동기화하고 NTP를 시작한 다음 애플리케이션을 다시 시작하는 것입니다. 응용 프로그램에서 그렇게 많은 가동 중지 시간을 감당할 수 없다면 시간을 동기화하기 전에 데이터베이스를 백업한 다음 컴퓨터 세계에 죽은 다람쥐를 바치고 방아쇠를 당기는 것이 좋습니다. 좋아, 조금 우스꽝스럽게 말하고 있지만 애플리케이션 중단을 해결하는 것 외에 다른 "안전한" 방법은 생각할 수 없습니다.
답변3
즉각적인 시간 도약이 발생할 때 오류에 취약한 것은 일반적으로 데이터베이스 서버가 아니라 해당 시간을 사용하는 애플리케이션입니다.
일반적으로 시간을 추적하는 방법에는 자체 시간 추적 또는 시스템 시간 비교라는 두 가지 방법이 있습니다. 두 가지 모두 긍정적이고 부정적인 장단점이 있습니다.
자신의 시간 추적
정확한 타이밍이 그다지 중요하지 않은 일부 임베디드 프로그래밍 및 시스템에서 이것이 사용되는 것을 봅니다. 기본 애플리케이션 루프에서는 '틱'을 추적하는 방법이 처리됩니다. 이는 경과된 시간을 표시하는 커널, 절전 또는 선택에 의해 제공되는 경보일 수 있습니다. 몇 시간이 지났는지 알면 이 시간을 카운터에 더하거나 뺄 수 있다는 것을 알게 됩니다. 이 카운터는 타이밍 애플리케이션이 발생하도록 하는 것입니다. 예를 들어, 카운터가 10초보다 높으면 무언가를 버리거나 뭔가를 해야 합니다.
응용 프로그램이 시간을 추적하지 않으면 카운터가 변경되지 않습니다. 이는 애플리케이션 디자인에 따라 필요할 수 있습니다. 예를 들어, 장기 실행 프로세스가 처리되는 데 걸리는 시간을 추적하는 것은 시작/중지 타임스탬프 목록보다 카운터를 사용하는 것이 더 쉽습니다.
찬성:
- 시스템 시계에 의존하지 않음
- 큰 시간 왜곡으로 인해 파손되지 않음
- 비용이 많이 드는 시스템 호출 없음
- 작은 카운터는 전체 타임스탬프보다 메모리 비용이 적게 듭니다.
범죄자:
- 시간이 별로 정확하지 않네요
- 시스템 시간을 변경하면 더욱 부정확해질 수 있습니다.
- 타이밍은 애플리케이션 실행에 상대적이며 지속되지 않습니다.
시스템 시간 비교
이것은 더 자주 사용되는 시스템입니다. 타임스탬프를 저장하고 시스템 시간 호출을 사용하여 타임스탬프와 비교합니다. 시스템 시간의 큰 왜곡은 애플리케이션의 무결성을 위협할 수 있으며, 몇 초의 작업은 시계 방향에 따라 몇 시간이 걸리거나 즉시 끝날 수 있습니다.
찬성:
- 정확한 시간 비교
- 재시작 및 장기간의 중단에도 지속됨
범죄자:
- 다른 타임스탬프와 비교할 새로운 타임스탬프를 얻기 위해 시스템 호출을 받습니다.
- 애플리케이션은 왜곡을 인식해야 하며 그렇지 않으면 중단될 수 있습니다.
영향을 받는 시스템
대부분의 응용 프로그램은 작업 일정을 비교하기 위해 타임스탬프를 사용합니다. 캐시 정리가 가능한 데이터베이스 시스템의 경우.
쿼리 언어의 데이터베이스 및 호출 시간 기능을 사용하는 모든 애플리케이션은 애플리케이션이 그에 따라 감지하고 처리하지 않으면 왜곡의 영향을 받습니다. 애플리케이션은 목적에 따라 실행을 중지하거나 무기한 로그인 기간을 허용할 수 없습니다.
메일 시스템은 오래되었거나 배달되지 않은 메일을 처리하기 위해 타임스탬프 및/또는 시간 초과를 사용합니다. 클럭 왜곡은 이에 영향을 미칠 수 있지만 영향은 훨씬 적습니다. 서버 재연결과 관련된 백오프 타이머가 누락되어 연결 서버에 페널티가 발생할 수 있습니다.
나는 시스템 시간을 변경할 때 커널 알람이 울릴 것이라고 생각하지 않습니다(연구하지 않았습니다). 이를 사용하는 시스템은 안전할 수 있습니다.
솔루션
부드럽게 시간을 이동합니다. 이는 선호하는 시간 솔루션 문서에서 찾을 수 있습니다.