मुझे दस्तावेज़ीकरण में एक उद्धरण नहीं मिल रहा है, लेकिन मेरा अनुभव बताता है कि सामान्य रूप से ईसी 2 की नेटवर्किंग आधारभूत संरचना (जिसमें आरडीएस और संभावित रूप से कोई अन्य एडब्ल्यूएस सेवा शामिल होगी जो प्रति ग्राहक प्रावधानित वर्चुअल मशीनों पर चलती है, यदि सभी नहीं एडब्ल्यूएस, और निश्चित रूप से "ईसी 2 इंस्टेंस" तक सख्ती से सीमित नहीं दिखता है) स्टेटफुल पैकेट निरीक्षण लागू करता है, और "भूल जाएगा" कि एक टीसीपी कनेक्शन पूर्ण आलस्य के कुछ मिनटों के बाद मान्य है ... आपके द्वारा वर्णित व्यवहार का कारण बनता है।
कनेक्शन के दोनों सिरों पर मशीनों को आश्वस्त किया जा सकता है कि कनेक्शन अभी भी है, लेकिन नेटवर्क यातायात को उनके बीच से गुजरने की अनुमति नहीं देगा, क्योंकि एसपीआई वातावरण में टीसीपी सत्र की खोज नहीं की जाती है, वे बनाए जाते हैं, और केवल कर सकते हैं जब नेटवर्क कनेक्शन को शुरुआत में देखता है (SYN, SYN/ACK, ACK ) मुझे मूल रूप से ईसी 2 (आरडीएस नहीं) में MySQL सर्वर के साथ इस समस्या का सामना करना पड़ा, लेकिन अगर अंतर्निहित कारण समान नहीं है तो मुझे आश्चर्य होगा।
इसके समाधान के लिए दो संभावित दृष्टिकोण हैं।
यदि आपकी PHP मशीन Linux है, तो लेयर 4 पर कनेक्शन को जीवित रखने के लिए कर्नेल को कॉन्फ़िगर करें। यह परिवर्तन आपके लिए इस अर्थ में अदृश्य होगा कि ये रखवाले Time में मान नहीं बदलेंगे। SHOW PROCESSLIST में कॉलम Sleep . में कनेक्शन के लिए क्योंकि यह परत 7 पर कनेक्शन के निष्क्रिय रहने के समय को रीसेट नहीं करेगा ... लेकिन इसे AWS अवसंरचना से समयबाह्य से बचना चाहिए यदि MySQL कनेक्शन का प्रबंधन करने वाले पुस्तकालय इसका लाभ उठाने के लिए सॉकेट विकल्पों को सही ढंग से सेट कर रहे हैं।
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive .html यह बताता है कि इसे लाइव कैसे सेट अप किया जाए, और इसे रीबूट के दौरान लगातार कैसे बनाया जाए।
ऐसा न होने पर, दूसरा विकल्प यह है कि MySQL को नेटवर्क टाइमआउट की तुलना में जल्दी कनेक्शन बंद करने के लिए बाध्य किया जाए। ताकि PHP मशीन तुरंत पहचान ले कि वह बंद सॉकेट पर बात करने की कोशिश कर रही है। यह एक टाइमआउट को लंबा करने के बजाय छोटा करने के लिए काउंटर-सहज ज्ञान युक्त लग सकता है, लेकिन टाइमआउट को छोटा करने से आपका पिंग परीक्षण बहुत जल्दी विफल हो जाना चाहिए यदि कोई सत्र बहुत लंबा निष्क्रिय हो गया है, जो (अनिवार्य रूप से) समस्या को हल करता है, विवेक मानते हुए PHP क्लाइंट लाइब्रेरी में। एक बार जब आपका आवेदन व्यस्त हो जाता है, तो कनेक्शन शायद ही कभी समयबाह्य तक पहुंचने के लिए पर्याप्त समय तक निष्क्रिय रहेंगे।
MySQL सर्वर में दो अलग-अलग निष्क्रिय टाइमआउट सेटिंग्स हैं: wait_timeout
(गैर-संवादात्मक सत्रों के लिए, यानी कोड से कनेक्शन, जैसे PHP) और interactive_timeout
(क्वेरी ब्राउज़र और कमांड लाइन क्लाइंट से) लेकिन सर्वर केवल अंतर जानता है क्योंकि क्लाइंट लाइब्रेरी को सर्वर को सूचित करना होता है कि वह किस प्रकार का कनेक्शन स्थापित कर रहा है। मान लें कि आपकी क्लाइंट लाइब्रेरी सही सेटअप का उपयोग करती है, तो wait_timeout वह है जिसे आप ढूंढ रहे हैं। इसे 900 से नीचे के मान पर सेट करने से समस्या का समाधान होना चाहिए यदि लिनक्स कर्नेल में टीसीपी कीपलाइव सेटिंग्स को बदलना नहीं है। ध्यान दें, हालांकि, परिवर्तन करने के बाद, केवल भविष्य के कनेक्शन प्रभावित होंगे - परिवर्तन किए जाने पर पहले से स्थापित कनेक्शन अभी भी वर्तमान मान के साथ चल रहे होंगे, जो कि डिफ़ॉल्ट रूप से 8 घंटे (28800 सेकंड) है। ये आपके उदाहरण के लिए RDS पैरामीटर समूह में कॉन्फ़िगर करने योग्य हैं।
यहां एडब्ल्यूएस डॉक्स में समान व्यवहार के संकेत दिए गए हैं। , विंडोज रजिस्ट्री सेटिंग्स के साथ, जिन्हें टीसीपी रखवाले को बदलने के लिए समायोजित करने की आवश्यकता है यदि आप लिनक्स के बजाय विंडोज़ पर PHP सर्वर चला रहे हैं, जैसा कि मैंने ऊपर माना है ... भले ही लेख विशेष रूप से रेडशिफ्ट और बाहरी कनेक्शन के बारे में है जैसा कि ऊपर चर्चा की गई है, EC2 यह अभी भी अंतर्निहित मुद्दे को मान्य करता प्रतीत होता है।
