データベースやメールサーバの稼働中にシステム時刻を変更すると、悪影響が出るという噂を聞きましたが、実際のリスクに関する具体的な情報を見つけるのは困難です。
Debian Wheezy ホストで稼働している本番環境の Postgres 9.3 サーバーがあり、時間が 367 秒ずれています。Postgresntpdateの実行中に openntp を実行または起動するだけでよいのでしょうか、それとも問題が発生する可能性はありますか? もしそうなら、時間を修正するより安全な方法は何ですか?
システム時間の変更にもっと敏感な他のサービスはありますか? メール サーバー (exim、sendmail など) やメッセージ キュー (activemq、rabbitmq、zeromq など) でしょうか?
答え1
データベースは時間を遡ることを好まないので、時間をジャンプするデフォルトの動作から始めるのは望ましくありません。-xコマンドラインにオプションを追加すると、オフセットが 600 秒 (10 分) 未満の場合に時間が調整されます。最大スルー レートでは、時計を 1 分調整するのに約 1 日半かかります。これは、時間を調整するのに時間がかかりますが安全な方法です。
時間を調整するために実行する前に、検出されるオフセットの大きさを確認するなどのオプションからntp始めることをお勧めします。これにより、パニック オフセットが 2 秒に設定され、比較的安全になります。ntp-g 2
このオプションが利用可能になる前に私が使用していた代替オプションは、1 分ごとに時計を秒単位の単位でリセットするループを記述することでした。リセットによって秒が変更されないことを確認すれば、これはおそらく安全です。タイムスタンプを頻繁に使用すると、レコードの順序が乱れる可能性があります。
一般的なオプションは、時計が逆戻りしないようにサーバーを長時間シャットダウンすることです。 ntpまたは、ntpdate起動時に時計を正しい時刻にジャンプするように構成することもできます。これは、データベースを起動する前に行う必要があります。
答え2
データベースが非常にアクティブで、内部レコードにタイムスタンプがある場合、システム時間の変更に対して特に脆弱になる可能性があります。一般的に、時間が遅れている場合、時間が進んでいるときに突然遅れるよりも、突然進む方が問題が少なくなります。
Joffrey が指摘しているように、突然の時刻のずれの問題は、データベース自体よりもアプリケーションで発生する場合の方がはるかに多いです。時刻を修正する最も安全な方法は、アプリケーションを N+1 分間シャットダウンし (N はシステム クロックが進んでいる分数)、時刻を同期して NTP を開始し、アプリケーションを再起動することです。アプリケーションでそれほどのダウンタイムを許容できない場合は、時刻を同期する前にデータベースのバックアップを取り、コンピュータ界のゴダに死んだリスを差し出して引き金を引くことをお勧めします。冗談はさておき、アプリケーションを停止する以外に「安全な」方法は思いつきません。
答え3
通常、瞬間的な時間の飛び越しが発生した場合にエラーの影響を受けやすいのはデータベース サーバーではなく、時間を使用するアプリケーションです。
通常、時間を追跡する方法は 2 つあります。自分の時間を追跡する方法と、システム時間を比較する方法です。どちらにも、プラス面とマイナス面のトレードオフがあります。
自分の時間を追跡する
これは、正確なタイミングがそれほど重要ではない組み込みプログラミングやシステムで使用されています。メイン アプリケーション ループでは、「ティック」を追跡する方法が考慮されています。これは、経過した時間を示すカーネル、スリープ、または選択によって発行されるアラームです。経過した時間がわかれば、その時間をカウンターに追加または減算できます。このカウンターによって、タイミング アプリケーションが実行されます。たとえば、カウンターが 10 秒を超えた場合は、何かを破棄するか、何かを行う必要があります。
アプリケーションが時間を追跡しない場合、カウンターは変更されません。アプリケーションの設計によっては、これが望ましい場合があります。たとえば、長時間実行されるプロセスが何かを処理するのにどのくらいの時間がかかっているかを追跡するのは、開始/停止タイムスタンプのリストよりもカウンターを使用する方が簡単です。
プロ：
- システムクロックに依存しない
- 大きな時間のずれは発生しない
- コストのかかるシステムコールなし
- 小さなカウンターは完全なタイムスタンプよりもメモリを消費しません
欠点:
- 時間はあまり正確ではない
- システム時間の変更により、さらに不正確になる可能性がある
- タイミングはアプリケーションの実行に相対的であり、持続しない
システム時間の比較
これは、より頻繁に使用されるシステムです。タイムスタンプを保存し、システム時間呼び出しを使用してタイムスタンプと比較します。システム時間に大きなずれがあると、アプリケーションの整合性が脅かされる可能性があります。数秒のタスクが、時計の方向によっては数時間かかるか、すぐに終了する可能性があります。
プロ：
- 正確な時間比較
- 再起動や長時間の停止でも持続する
欠点:
- 他のタイムスタンプと比較するために新しいタイムスタンプを取得するためにシステムコールを実行します
- アプリケーションはスキューに注意する必要があり、そうしないと壊れる可能性がある
影響を受けるシステム
ほとんどのアプリケーションは、タスクをスケジュールするためにタイムスタンプの比較を使用します。データベース システムの場合は、キャッシュのクリーンアップが考えられます。
データベースを使用し、クエリ言語で時間関数を呼び出すすべてのアプリケーションは、アプリケーションが適切に検出して処理しない場合、スキューの影響を受けます。アプリケーションは、その目的に応じて実行を停止したり、無期限のログイン期間を許可したりすることはできません。
メール システムでは、古くなったメールや未配信のメールを処理するために、タイムスタンプやタイムアウトが使用されます。クロックのずれがこれに影響を及ぼす可能性がありますが、影響ははるかに小さくなります。サーバーへの再接続に関するバックオフ タイマーが失われ、接続サーバーにペナルティが発生する可能性があります。
システム時間を変更してもカーネルアラームが鳴るとは思いません (調査していません)。これらを使用するシステムは安全である可能性があります。
ソリューション
時間をゆっくり動かします。これは、お気に入りの時間ソリューションのドキュメントに記載されています。