कैसे एक डेटाबेस कनेक्शन लिमिट ने लगभग मेरे ग्राहकों के Mac रीबूट कर दिए

हम ग्राहकों के लिए Mac mini का एक छोटा फ़्लीट चलाते हैं। एक हब पर एक डेमन हर मशीन को SSH पर पोल करता है और कंट्रोल प्लेन को टेलीमेट्री भेजता है। मशीन चुप हो जाए, तो वह आगे कदम उठाता है। पहले वह इंतज़ार करता है। फिर स्मार्ट प्लग से मशीन का पावर साइकिल करता है। फिर किसी इंसान को बुलाता है।

पिछले हफ़्ते कंट्रोल प्लेन 500 लौटाने लगा। तेरह मिनट बाद डेमन ने तय कर लिया कि चारों Mac बंद हैं, और हर एक के लिए पावर साइकिल दर्ज कर दिया। दो पैसे देने वाले ग्राहकों के थे। तीसरा उसी सुबह बिका था।

असल में क्या फ़ेल हुआ

एक डेटाबेस कनेक्शन पूल। कंट्रोल प्लेन सर्वरलेस फ़ंक्शन पर चलता है, जो एक Postgres पूलर से जुड़ते हैं। पूरे प्रोजेक्ट के लिए उसकी सीमा पंद्रह कनेक्शन है। कुछ गर्म फ़ंक्शन ने सारे कनेक्शन ले लिए, और डेटाबेस वाला हर API रूट फ़ेल होने लगा। पूरी जानकारी एक अलग पोस्ट में है।

Mac ठीक थे। SSH चल रहा था। हर GUI सेशन चालू था। उनमें से एक पर बिल्ड कर रहे ग्राहक को कुछ पता नहीं चला। ख़राब सिर्फ़ वह सिस्टम था, जिसका काम यह जानना था कि Mac ख़राब हैं या नहीं।

ठीक फ़्लीट बंद कैसे दिखा

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

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

ladder: Unit 02 unreachable 12m51s → power cycle
ladder: Unit 03 unreachable 12m51s → power cycle
ladder: Unit 04 unreachable 12m51s → power cycle
ladder: Unit 05 unreachable 12m43s → power cycle

कुछ रीबूट क्यों नहीं हुआ

कोई स्मार्ट प्लग कॉन्फ़िगर नहीं था। पावर साइकिल वाले स्टेप ने प्लग ढूँढा, कोई नहीं मिला, और आगे बढ़ गया। बाद में चारों मशीनों का अपटाइम छह दिन, छह दिन, एक दिन और लगभग एक घंटा था। किसी को छुआ नहीं गया था।

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

फ़िक्स

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

ladder: skipped, no successful unit poll in 14m02s (control plane, not the units)

यह लाइन ठीक-ठीक बताती है कि वह क्या करने से मना कर रही है और क्यों। पुराने लॉजिक को पहली बार में यही कहना चाहिए था।

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

अपने ऑटोमेशन में क्या टेस्ट करें

हमने टेस्ट किया था कि Mac बंद होने पर क्या होता है। हमने कभी टेस्ट नहीं किया था कि Mac पर नज़र रखने वाली चीज़ बंद हो, तो क्या होता है। ये एक टेस्ट नहीं हैं। और दूसरा वाला ही बिजली के स्विच तक हाथ बढ़ाता है।