Veritabanı sunucusunda NTP başlatılma riski var mı?

Çalışırken sistem zamanını değiştirirseniz, veritabanı ve posta sunucularına olan kötü şeyler söylentileri duydum. Ancak, gerçek riskler hakkında somut bilgiler bulmakta zorlanıyorum.

Bir Debian Wheezy sunucusunda çalışan bir Postgres 9.3 sunucusuna sahibim ve süresi 367 saniyedir. ntpdatePostgres çalışırken sadece openntp çalıştırabilir ya da başlatabilir miyim , yoksa bir soruna neden olabilir mi? Eğer öyleyse, zamanı düzeltmenin daha güvenli bir yöntemi nedir?

Sistem zamanındaki değişime daha duyarlı başka hizmetler var mı? Belki posta sunucuları (exim, sendmail, vb.) Veya mesaj kuyrukları (activemq, rabbitmq, zeromq, etc)?

Veritabanları zaman içinde geriye doğru adımlardan hoşlanmaz, bu nedenle zaman atlamak için varsayılan davranışla başlamak istemezsiniz. -xSeçeneğin komut satırına eklenmesi, ofset 600 saniyeden (10 dakika) azsa süreyi kısaltır. Maksimum dönüş hızında, saati bir dakikaya ayarlamak yaklaşık bir buçuk gün sürer. Bu, zamanı ayarlamak için yavaş ama güvenli bir yoldur.

ntpSüreyi ayarlamak için çalıştırmadan önce , ne kadar büyük bir sapma tespit ettiğini doğrulamak ntpgibi bir seçenekle başlamak isteyebilirsiniz -g 2. Bu panik ofsetini 2 saniyeye ayarlayacaktır, ki bu nispeten güvenli olmalıdır.

Bu seçenek mevcut olmadan önce kullandığım alternatif bir seçenek, saatin saniyenin bir kısmını geri çeken bir döngüyü yazmaktı. Sıfırlama işleminin saniye değişmeyeceğinden emin olursanız, bu büyük olasılıkla güvenlidir. Zaman damgalarını çok kullanırsanız, sıra kayıtlarınız olmayabilir.

Yaygın bir seçenek, sunucunun saatin geriye doğru bir hareketi olmayacak kadar uzun süre kapatılmasıdır. ntpveya ntpdatebaşlangıçta saati doğru saate atlayacak şekilde yapılandırılabilir. Bu, veritabanı başlatılmadan önce yapılmalıdır.

Veritabanları, eğer çok aktiflerse ve dahili kayıtlarda zaman damgalarına sahiplerse, sistem zaman değişikliklerine karşı özellikle savunmasız olabilirler. Genel olarak, eğer zamanınız geride kaldıysa, aniden öne doğru atlarsanız ve aniden geriye atlarsanız, çok daha az sorun yaşarsınız.

Joffrey'in işaret ettiği gibi - aniden zıplayan sorunları veritabanının kendisinden daha sık karşılaşılan bir uygulamadır. Zamanı düzeltmenin en güvenli yolu, N + 1 dakika boyunca uygulamayı kapatmak (burada N, sistem saatinizin önde olduğu dakika sayısıdır) ve ardından zamanı senkronize edin, NTP'yi başlatın ve uygulamayı yeniden başlatın. Uygulamada çok fazla zaman harcayamazsanız, zaman eşitlemeden önce veritabanını yedeklemenizi önerebilirim, daha sonra bilgisayarlılığın godası için ölü bir sincap önerin ve tetiği çekin. Tamam, biraz çekingen davranıyorum, ancak uygulama kesintisi almaktan başka "güvenli" bir yol düşünemiyorum.

Genellikle bir anlık zaman sıçraması meydana geldiğinde hataya açık olan veritabanı sunucusu değildir: bu süreyi kullanan uygulamaları.

Genellikle izlemenin iki yolu vardır: kendi zamanının izlenmesi veya sistem zamanının karşılaştırılması. İkisinin de bazı olumlu ve olumsuz değişimleri var.

Kendi zaman takibi

Kesin zamanlamanın bu kadar kritik olmadığı bazı gömülü programlama ve sistemlerde kullanıldığını görüyorum. Bir ana uygulama döngüsünde, bir 'kene' izlemenin bir yolu halledilir. Bu, çekirdek tarafından verilen bir alarm, uyku veya geçen sürenin bir göstergesini veren bir seçim olabilir. Hangi zamanın geçtiğini bildiğiniz zaman, bu saati bir sayaca ekleyebileceğinizi veya çıkarabileceğinizi biliyorsunuz. Bu sayaç, zamanlama uygulamanızı gerçekleştiren şeydir. Örneğin, sayaç 10 saniyeden yüksekse bir şeyi atabilirsiniz veya bir şey yapmanız gerekir.

Uygulama zamanı takip etmezse, sayaç değişmez. Bu, uygulamanızın tasarımına bağlı olarak istenebilir. Örneğin, uzun süren bir işlemin bir şeyi ne kadar süreyle gerçekleştirdiğini takip etmek, bir sayaçla bir başlama / durma zaman damgaları listesinden daha kolaydır.

Pro:

• Sistem saatine bağlı değil
• Büyük bir çarpıklık kırmak olmayacak
• Pahalı sistem çağrısı yok
• Küçük sayaçlar tam bir zaman damgasından daha az hafızaya mal olur

con:

• Zaman çok doğru değil
• Sistem zamanındaki değişiklik onu daha da yanlış yapabilir
• Zamanlama, uygulamayı çalıştırmaya göre görmez, sürmez

Sistem saatini karşılaştırma

Bu daha sık kullanılan sistemdir: bir zaman damgası saklayın ve bir sistem zaman çağrısı kullanarak zaman damgasıyla karşılaştırın. Sistem zamanındaki büyük sapmalar uygulamanızın bütünlüğünü tehdit edebilir, birkaç saniyelik bir görev saatin yönüne bağlı olarak birkaç saat sürebilir veya sona erebilir.

Pro:

• Doğru zaman karşılaştırma
• Yeniden başlatmalar ve uzun süreli kesintiler üzerinde ısrar ediyor

con:

• Diğer zaman damgaları ile karşılaştırmak üzere yeni bir zaman damgası almak için sistem çağrısı alır
• Uygulama çarpıklıkların farkında olmalı veya kırılabilir

Etkilenen sistemler

Uygulamaların çoğu, görevleri zamanlamak için karşılaştırma yaparken zaman damgasını kullanır. Önbellek temizlemeli olabilecek veritabanı sistemleri için.

Sorgu dilinde bir veritabanı ve çağrı süresi işlevleri kullanan tüm uygulamalar, uygulama uygun bir şekilde algılamaz ve işlemezse, çarpıklıklardan etkilenir. Uygulamalar çalışmayı asla durduramaz veya amacına bağlı olarak belirsiz oturum açma sürelerine izin veremez.

Posta sistemleri, eski veya teslim edilmeyen postaları işlemek için zaman damgaları ve / veya zaman aşımlarını kullanır. Bir saat kayması bunu etkileyebilir, ancak çok daha az bir etkiye sahip. Sunuculara yeniden bağlanmaya ilişkin zaman aşımına uğrayan zamanlayıcılar, bağlantı sunucusunda cezalarla sonuçlanabilecek şekilde kaçırılabilir.

Sistem zamanını değiştirirken çekirdek alarmlarının çalışacağını sanmıyorum (araştırmamıştım). Bunları kullanan sistemler güvenli olabilir.

Çözümler

Yavaşça hareket zamanı. Bu, favori zaman çözümünüzün belgelerinde bulunabilir.