Rischio di avviare NTP sul server database?

Ho sentito voci di cose brutte che accadono al database e ai server di posta se si modifica l'ora di sistema mentre sono in esecuzione. Tuttavia, faccio fatica a trovare informazioni concrete sui rischi reali.

Ho un server Postgres 9.3 di produzione in esecuzione su un host Debian Wheezy e il tempo è scaduto di 367 secondi. Posso semplicemente eseguire ntpdateo avviare openntp mentre Postgres è in esecuzione o è probabile che causi un problema? In tal caso, qual è un metodo più sicuro per correggere l'ora?

Ci sono altri servizi che sono più sensibili a un cambiamento nell'ora del sistema? Forse server di posta (exim, sendmail, ecc.) O code di messaggi (activemq, rabbitmq, zeromq, ecc.)?

Ai database non piacciono i passi indietro nel tempo, quindi non si desidera iniziare con il comportamento predefinito di saltare il tempo. Aggiungendo l' -xopzione alla riga di comando, il tempo si sposterà se l'offset è inferiore a 600 secondi (10 minuti). Alla velocità di risposta massima ci vorranno circa un giorno e mezzo per regolare l'orologio di un minuto. Questo è un modo lento ma sicuro per regolare l'ora.

Prima di correre ntpper regolare il tempo, potresti voler iniziare ntpcon un'opzione come -g 2verificare quanto è grande un offset che sta rilevando. Questo imposterà l'offset di panico su 2 secondi, che dovrebbe essere relativamente sicuro.

Un'opzione alternativa che ho usato prima che questa opzione fosse disponibile era quella di scrivere un ciclo che ripristinasse la parte posteriore del secondo ogni minuto circa. Se controlli per assicurarti che il ripristino non cambi il secondo, questo è probabilmente sicuro. Se si utilizzano pesantemente i timestamp, è possibile che siano presenti record fuori sequenza.

Un'opzione comune è quella di arrestare il server abbastanza a lungo da evitare movimenti all'indietro dell'orologio. ntpo ntpdatepuò essere configurato per saltare l'orologio all'ora corretta all'avvio. Questo dovrebbe essere fatto prima dell'avvio del database.

I database possono essere particolarmente vulnerabili alle modifiche dell'ora del sistema se sono molto attivi e hanno timestamp su record interni. In generale, se il tempo è alle spalle, avrai molti meno problemi se salti improvvisamente in avanti rispetto a se sei avanti e salti improvvisamente all'indietro.

Come sottolinea Joffrey, è molto più spesso l'applicazione che presenta problemi con improvvisi salti di tempo rispetto al database stesso. Il modo più sicuro per correggere l'ora è chiudere l'applicazione per N + 1 minuti (dove N è il numero di minuti che il tuo orologio di sistema è in anticipo) e quindi sincronizzare l'ora, avviare NTP e riavviare l'applicazione. Se non riesci a sopportare così tanti tempi di inattività nell'applicazione, posso solo suggerirti di eseguire un backup del database prima di sincronizzare il tempo, quindi offrire uno scoiattolo morto al goda del computerdom e premere semplicemente il grilletto. Ok, sto diventando un po 'faceto, ma non riesco a pensare a nessun altro modo "sicuro" che prendere un'interruzione dell'applicazione.

Di solito non è il server di database che è vulnerabile all'errore quando si verifica un salto temporale istantaneo: sono le applicazioni che usano il tempo che lo sono.

Esistono in genere due modi per tenere traccia del tempo: il monitoraggio del proprio tempo o il confronto del tempo di sistema. Entrambi hanno alcuni compromessi positivi e negativi.

Proprio monitoraggio del tempo

Lo vedo usato in alcuni sistemi e programmazioni integrate in cui il tempismo esatto non è così critico. In un ciclo applicativo principale viene preso in considerazione un modo per tracciare un 'tick'. Potrebbe trattarsi di un allarme dato dal kernel, sleep o select che fornisce un'indicazione del tempo trascorso. Quando sai a che ora passa, sai che puoi aggiungere o sottrarre questa volta a un contatore. Questo contatore è ciò che rende possibile l'applicazione di temporizzazione. Ad esempio, se il contatore è superiore a 10 secondi, puoi scartare qualcosa o devi fare qualcosa.

Se l'applicazione non tiene traccia del tempo, il contatore non cambierà. Questo potrebbe essere desiderato a seconda del design dell'applicazione. Ad esempio, tenere traccia di quanto tempo viene gestito un processo di lunga durata è più semplice con un contatore rispetto a un elenco di timestamp di avvio / arresto.

Pro:

• Non dipende dall'orologio di sistema
• Non si romperà su un grande disallineamento
• Nessuna costosa chiamata di sistema
• I contatori di piccole dimensioni costeranno meno memoria rispetto a un timestamp completo

con:

• Il tempo non è molto preciso
• La modifica dell'ora di sistema potrebbe renderla ancora più imprecisa
• Il tempismo è relativo all'esecuzione dell'applicazione, non persiste

Confronto del tempo di sistema

Questo è il sistema usato più spesso: memorizza un timestamp e confrontalo con il timestamp usando una chiamata di orario del sistema. Enormi disallineamenti nell'ora del sistema potrebbero minacciare l'integrità dell'applicazione, un'attività di alcuni secondi potrebbe richiedere ore o terminare immediatamente a seconda della direzione dell'orologio.

Pro:

• Confronto preciso dei tempi
• Persiste per riavvii e lunghe interruzioni

con:

• Riceve una chiamata di sistema per ottenere un nuovo timestamp da confrontare con altri timestamp
• L'applicazione deve essere consapevole delle inclinazioni o può rompersi

Sistemi interessati

La maggior parte delle applicazioni utilizzerà il timestamp rispetto alle attività di pianificazione. Per i sistemi di database che potrebbero essere operazioni di pulizia della cache.

Se l'applicazione non rileva e gestisce di conseguenza, tutte le applicazioni che utilizzano un database e le funzioni del tempo di chiamata nella lingua della query saranno interessate da errori. Le applicazioni non potrebbero mai smettere di funzionare o consentire periodi di accesso indefiniti a seconda del suo scopo.

I sistemi di posta utilizzeranno timestamp e / o timeout per la gestione di messaggi non aggiornati o non consegnati. Una inclinazione dell'orologio potrebbe influire su questo, ma con un impatto molto minore. I timer di back-off relativi alla riconnessione ai server potrebbero non essere rispettati, con conseguenti sanzioni per il server di connessione.

Non penso (non ho fatto ricerche) che gli allarmi del kernel si spegneranno quando si cambia l'ora di sistema. I sistemi che usano questi potrebbero essere sicuri.

soluzioni

Sposta delicatamente il tempo. Questo può essere trovato nella documentazione della tua soluzione temporale preferita.