डेटाबेस सर्वर पर NTP शुरू करने का जोखिम?

Question

मैंने डेटाबेस और मेल सर्वरों के खराब होने की अफवाहें सुनी हैं यदि आप सिस्टम टाइम बदल रहे हैं तो वे चल रहे हैं। हालाँकि, मुझे वास्तविक जोखिमों पर कोई ठोस जानकारी प्राप्त करने में मुश्किल समय आ रहा है।

मेरे पास एक प्रोडक्शन पोस्टग्रेज 9.3 सर्वर है जो डेबियन व्हीज़ी होस्ट पर चल रहा है और समय 367 सेकंड है। ntpdateजब मैं पोस्टग्रेज चल रहा है, तो क्या मैं सिर्फ रन कर सकता हूं या ओपनपेंट शुरू कर सकता हूं , या क्या इससे समस्या होने की संभावना है? यदि हां, तो समय को सही करने का एक सुरक्षित तरीका क्या है?

क्या अन्य सेवाएं हैं जो सिस्टम समय में बदलाव के लिए अधिक संवेदनशील हैं? हो सकता है कि मेल सर्वर (एक्जिम, सेंडमेल, आदि) या संदेश की कतारें (एक्टिवमैक, खरगोशबिट, ज़ीरोमक, आदि)?

Answer 1

डेटाबेस समय में पिछड़े चरणों को पसंद नहीं करते हैं, इसलिए आप समय कूदने के डिफ़ॉल्ट व्यवहार के साथ शुरू नहीं करना चाहते हैं। -xकमांड लाइन में विकल्प जोड़ने से उस समय की नींद खराब हो जाएगी जब ऑफसेट 600 सेकंड (10 मिनट) से कम हो। अधिकतम स्लीव रेट पर घड़ी को एक मिनट में समायोजित करने में एक दिन और आधा समय लगेगा। यह समय को समायोजित करने का एक धीमा लेकिन सुरक्षित तरीका है।

ntpसमय को समायोजित करने के लिए दौड़ने से पहले , आप यह सत्यापित करने के लिए ntpएक विकल्प के साथ शुरू कर सकते हैं कि -g 2यह कितनी बड़ी ऑफसेट का पता लगा रहा है। यह 2 सेकंड के लिए आतंक ऑफसेट सेट करेगा जो अपेक्षाकृत सुरक्षित होना चाहिए।

इस विकल्प के उपलब्ध होने से पहले मैंने जो वैकल्पिक विकल्प का उपयोग किया था, वह एक लूप लिखना था, जो हर मिनट या उसके बाद घड़ी के दूसरे हिस्से को रीसेट करता है। यदि आप यह सुनिश्चित करने के लिए जांच करते हैं कि रीसेट दूसरा नहीं बदलेगा तो यह सुरक्षित है। यदि आप टाइमस्टैम्प का भारी उपयोग करते हैं, तो आप अनुक्रम रिकॉर्ड से बाहर हो सकते हैं।

एक सामान्य विकल्प यह है कि सर्वर को लंबे समय तक बंद कर दिया जाए ताकि घड़ी का कोई बैकवर्ड मूवमेंट न हो। ntpया ntpdateस्टार्ट-अप में सही समय पर घड़ी कूदने के लिए कॉन्फ़िगर किया जा सकता है। डेटाबेस शुरू होने से पहले यह किया जाना चाहिए।

Answer 2

डेटाबेस विशेष रूप से सिस्टम समय परिवर्तनों के लिए कमजोर हो सकते हैं यदि वे बहुत सक्रिय हैं और आंतरिक रिकॉर्ड पर टाइमस्टैम्प हैं। सामान्य तौर पर, यदि आप समय से पीछे हैं, तो आपको बहुत कम समस्याएँ होंगी यदि आप अचानक आगे कूदते हैं यदि आप आगे हैं और अचानक पीछे की ओर कूदते हैं।

जैसा कि जोफ्रे बताते हैं - यह बहुत अधिक बार अनुप्रयोग है जो डेटाबेस से अचानक समय कूदता है के साथ समस्या है। समय को सही करने का सबसे सुरक्षित तरीका है एन + 1 मिनट के लिए आवेदन को बंद करना (जहां एन मिनट आपके सिस्टम की घड़ी आगे है) और फिर सिंक समय, एनटीपी शुरू करें और एप्लिकेशन को पुनरारंभ करें। यदि आप आवेदन में इतना डाउनटाइम नहीं ले सकते हैं, तो मैं केवल सुझाव दे सकता हूं कि आप समय को सिंक करने से पहले डेटाबेस का बैकअप ले लें, फिर कंप्यूटरडोम के गोडा को एक मृत गिलहरी की पेशकश करें और बस ट्रिगर खींचें। ठीक है, मैं थोड़ा मुखर हो रहा हूं, लेकिन मैं एक आवेदन आउटेज लेने की तुलना में किसी अन्य "सुरक्षित" तरीके के बारे में नहीं सोच सकता।

Comments

मैं आगे हूं और लगभग 6 मिनट तक पीछे की ओर कूदने की जरूरत है। मेरे पास कई, कई आंतरिक रिकॉर्ड हैं, जिनके साथ सेट किया गया था now()। क्या आप अपने उत्तर में समय बदलने की कोई सुरक्षित विधि जोड़ सकते हैं?

— विल्लिसेल्प्रोएरमैन

अगर ntpd को सही तरीके से स्थापित और कॉन्फ़िगर किया गया है, तो घड़ी को धीमा करके सिस्टम समय को धीरे-धीरे सही करने में सक्षम होना चाहिए। एक बार सही समय प्राप्त करने के बाद, बहाव को समय बनाए रखने के लिए समायोजित किया जाता है। आपको अपनी त्रुटि के अतिरिक्त एक अधिकतम सुधार निर्दिष्ट करने की आवश्यकता हो सकती है। कम से कम मैं इसे समझता हूं, लेकिन मैं एनटीपी विशेषज्ञ नहीं हूं।

— जोनाथन जे

@JonathanJ - NTP में 5 मिनट से अधिक समय स्कीज़ को सही करने में कठिनाई होती है, और जब "मानक" डॉक्यूमेंटेशन (जिसमें कई सेट होते हैं, प्रति सेकंड) सेट किया जाता है, तो पहले समय को एक छलांग में सिंक करता है, फिर बहाव को समायोजित करके सिंक बनाए रखता है।

— जॉन

@ जॉन मैं सालों पहले गिलहरी से बाहर भाग गया;)

— जोफ्री

Answer 3

यह आमतौर पर डेटाबेस सर्वर नहीं होता है जो तत्काल समय छलांग होने पर त्रुटि के लिए कमजोर होता है: इसके अनुप्रयोग जो उस समय का उपयोग करते हैं जो हैं।

आमतौर पर ट्रैकिंग समय के दो तरीके हैं: खुद का समय ट्रैकिंग या सिस्टम का समय की तुलना करना। दोनों में कुछ सकारात्मक और नकारात्मक ट्रेडऑफ हैं।

खुद का समय ट्रैकिंग

मैं कुछ एम्बेडेड प्रोग्रामिंग और सिस्टम में इसका उपयोग करता हूं, जहां सटीक समय महत्वपूर्ण नहीं है। मुख्य एप्लिकेशन लूप में 'टिक' को ट्रैक करने का एक तरीका ध्यान रखा जाता है। यह कर्नेल, नींद या चयन द्वारा दिया गया अलार्म हो सकता है जो गुजरे समय की मात्रा का संकेत देता है। जब आप जानते हैं कि क्या समय बीत चुका है, तो आप जानते हैं कि आप इस समय को एक काउंटर में जोड़ या घटा सकते हैं। यह काउंटर वह है जो आपके समय के अनुप्रयोग को बनाता है। उदाहरण के लिए, यदि काउंटर 10 सेकंड से अधिक है तो आप कुछ त्याग सकते हैं, या आपको कुछ करने की आवश्यकता है।

यदि एप्लिकेशन समय का ट्रैक नहीं रखता है, तो काउंटर नहीं बदलेगा। यह आपके एप्लिकेशन के डिज़ाइन के आधार पर वांछित हो सकता है। उदाहरण के लिए, एक लंबे समय से चल रही प्रक्रिया को कुछ समय के लिए ट्रैक रखने पर एक टाइमस्टैम्प शुरू / रोक की सूची की तुलना में काउंटर के साथ आसान है।

समर्थक:

• सिस्टम क्लॉक पर निर्भर नहीं
• एक बड़े समय तिरछा पर नहीं टूटेगा
• कोई महंगा सिस्टम कॉल नहीं
• छोटे काउंटरों को एक पूर्ण टाइमस्टैम्प की तुलना में कम स्मृति खर्च होगी

कोन:

• समय बहुत सटीक नहीं है
• सिस्टम समय में बदलाव इसे और भी गलत बना सकता है
• समय अनुप्रयोग चलाने के सापेक्ष है, निरंतर नहीं रहता है

तुलना प्रणाली समय

यह अधिक बार उपयोग की जाने वाली प्रणाली है: टाइमस्टैम्प को स्टोर करें और सिस्टम टाइम कॉल का उपयोग करके टाइमस्टैम्प के साथ तुलना करें। सिस्टम के समय में भारी वृद्धि से आपके एप्लिकेशन की अखंडता को खतरा हो सकता है, कुछ सेकंड का एक कार्य घड़ी की दिशा के आधार पर तुरंत या अंत में ले सकता है।

समर्थक:

• सटीक समय की तुलना
• पुनरारंभ और लंबे आउटेज पर बनी रहती है

कोन:

• अन्य टाइमस्टैम्प के साथ तुलना करने के लिए एक ताजा टाइमस्टैम्प प्राप्त करने के लिए एक सिस्टम कॉल लेता है
• एप्लिकेशन को स्काइज़ के बारे में पता होना चाहिए या टूट सकता है

प्रभावित सिस्टम

अधिकांश एप्लिकेशन शेड्यूल कार्यों की तुलना में टाइमस्टैम्प का उपयोग करेंगे। डेटाबेस सिस्टम के लिए जो कैश क्लीनअप हो सकते हैं।

सभी अनुप्रयोग जो डेटाबेस का उपयोग करते हैं और क्वेरी भाषा में कॉल फ़ंक्शंस का उपयोग करते हैं, यदि एप्लिकेशन पता नहीं लगाता है और तदनुसार हैंडल करता है, तो स्कीज़ से प्रभावित होगा। एप्लिकेशन कभी भी चलना बंद नहीं कर सकते हैं या अपने उद्देश्य के आधार पर अनिश्चित लॉगिन अवधि की अनुमति नहीं दे सकते हैं।

मेल सिस्टम बासी या बिना मेल वाले मेल को संभालने के लिए टाइमस्टैम्प और / या टाइमआउट का उपयोग करेगा। एक घड़ी तिरछा प्रभावित कर सकता है लेकिन बहुत कम प्रभाव के साथ। सर्वर से फिर से कनेक्ट करने के संबंध में बैक-ऑफ टाइमर कनेक्ट करने में चूक हो सकती है, जिससे कनेक्टिंग सर्वर पर पेनल्टी लग सकती है।

मुझे नहीं लगता (शोध नहीं किया गया है) कि सिस्टम समय बदलते समय कर्नेल अलार्म बंद हो जाएगा। इनका उपयोग करने वाले सिस्टम सुरक्षित हो सकते हैं।

समाधान की

धीरे से समय बढ़ाएं। यह आपके पसंदीदा समय समाधान के प्रलेखन में पाया जा सकता है।

Comments

यह एक शानदार प्रतिक्रिया है, और मैं समय रहते हुए अधिक सीखने की सराहना करता हूं। मैंने इसका चयन नहीं किया क्योंकि यह मेरे उत्पादन डेटाबेस सर्वर पर समय को समायोजित करने की मेरी वर्तमान चिंता का एक स्पष्ट समाधान प्रदान नहीं करता था। मुझे चीजें सिखाने के लिए +1।

— विजीलसिफ़ेरोफॉर्मन