MySQL जीवन समाप्ति (EOL): तिथियां, जोखिम, और अपग्रेड चेकलिस्ट

1. MySQL का एंड ऑफ लाइफ़ (EOL) क्या है? आपको इसे अभी क्यों जांचना चाहिए

MySQL EOL क्या है? एक बुनियादी व्याख्या

MySQL एक ओपन‑सोर्स रिलेशनल डेटाबेस मैनेजमेंट सिस्टम है जो दुनिया भर में व्यापक रूप से उपयोग किया जाता है। यह वेब एप्लिकेशन से लेकर व्यापार प्रणालियों तक सब कुछ चलाता है—लेकिन कोई भी संस्करण हमेशा के लिए नहीं चलाया जा सकता।

MySQL में एक “एंड ऑफ लाइफ़ (EOL)” बिंदु भी होता है। यह वह तिथि दर्शाता है जब Oracle, डेवलपर, उस संस्करण के लिए समर्थन समाप्त कर देता है—जैसे सुरक्षा अपडेट और बग फिक्स।

उदाहरण के लिए, MySQL 5.7 ने अक्टूबर 2023 में समर्थन समाप्त कर दिया। इस प्रकार की “EOL जानकारी” अत्यंत महत्वपूर्ण है क्योंकि यह सीधे उत्पादन में चल रही प्रणालियों की सुरक्षा और भविष्य की रखरखाव क्षमता को प्रभावित करती है।

“हमने इसे नोटिस करने से पहले ही EOL हो गया” बहुत खतरनाक है

कई डेवलपर और ऑपरेटर MySQL को अपग्रेड करने में सतर्क रहते हैं। यह सोचना आसान है “यह स्थिर है, इसलिए हम इसे जैसा है वैसा ही छोड़ सकते हैं,” लेकिन EOL संस्करण को चलाते रहने से बड़े जोखिम उत्पन्न होते हैं।

विशेष रूप से, जोखिमों में शामिल हैं:

• सुरक्षा कमजोरियों का पैच नहीं किया जाता
• OS और अन्य सॉफ़्टवेयर के साथ संगतता खो जाती है
• आप विक्रेताओं से समर्थन नहीं ले सकते
• नए डेवलपर इसे बनाए रखने में कठिनाई महसूस करते हैं, जिससे रखरखाव लागत बढ़ती है

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

समर्थन स्थिति जानने से “घटनाओं” से बचाव होता है

व्यवसाय प्रणालियों में MySQL का उपयोग करने वाली कंपनियों के लिए, “हम अनजाने में EOL के बाद भी चलाते रहे” जैसी स्थिति बाद में बड़े आउटेज या सुरक्षा घटनाओं का कारण बन सकती है।

इसीलिए अपने MySQL संस्करण के समर्थन जीवनचक्र को समझना—और EOL से पहले नियोजित अपग्रेड या माइग्रेशन करना—स्थिर संचालन के लिए मुख्य कुंजी है।

अगले भाग में, हम यह स्पष्ट सूची तैयार करेंगे कि कौन से संस्करण कब EOL हुए, ताकि एक व्यावहारिक संदर्भ मिल सके।

2. MySQL End-of-Support Timeline by Version (EOL Summary)

प्रमुख MySQL संस्करणों और उनके EOL तिथियों को जानें

MySQL वर्षों के दौरान लगातार अपडेट किया गया है, और प्रत्येक प्रमुख संस्करण की एक स्पष्ट परिभाषित समर्थन अवधि होती है। नीचे प्रमुख संस्करणों के आधिकारिक रूप से प्रकाशित EOL (समर्थन समाप्ति तिथियों) का सारांश दिया गया है।

[EOL Table by Version]

*तिथियां Oracle और प्रमुख क्लाउड प्रदाताओं से सार्वजनिक रूप से उपलब्ध जानकारी पर आधारित हैं।

MySQL 5.5 (समर्थन 2018 में समाप्त हुआ)

MySQL 5.5 2010 में जारी किया गया था और कई वेब एप्लिकेशन द्वारा अपनाया गया था। हालांकि, समर्थन 3 दिसंबर, 2018 को समाप्त हो गया। चूंकि अब कोई सुरक्षा पैच या बग फिक्स नहीं दिया जाता, इसलिए अभी भी इसे चलाने वाली कोई भी प्रणाली जल्द से जल्द माइग्रेट करनी चाहिए।

MySQL 5.6 (समर्थन 2021 में समाप्त हुआ)

MySQL 5.6 प्रदर्शन सुधार और नई सुविधाओं के कारण लोकप्रिय हुआ, लेकिन यह 5 फरवरी, 2021 को EOL पर पहुंच गया। जो वातावरण अभी भी इसका उपयोग कर रहे हैं, वे पहले ही समर्थन से बाहर हैं और महत्वपूर्ण जोखिमों के प्रति उजागर हैं।

MySQL 5.7 (समर्थन अक्टूबर 2023 में समाप्त हुआ)

MySQL 5.7 कई वर्षों तक एंटरप्राइज़ सिस्टम में व्यापक रूप से उपयोग किया गया, लेकिन समर्थन 21 अक्टूबर, 2023 को समाप्त हो गया। कई सिस्टम अभी भी इस संस्करण को चला रहे हैं, और अधिक संगठन जल्द से जल्द माइग्रेट करने के लिए धक्का दे रहे हैं। अब संगतता जांच और डेटा माइग्रेशन कार्य प्रमुख फोकस बन गए हैं।

MySQL 8.0 (प्रिमियम समर्थन अप्रैल 2025 में समाप्त होने की योजना)

MySQL 8.0 वर्तमान मुख्यधारा का स्थिर संस्करण है, लेकिन प्रिमियम समर्थन अप्रैल 2025 में समाप्त होने की योजना है। उसके बाद विस्तारित समर्थन या LTS (लॉन्ग टर्म सपोर्ट) रिलीज़ पर स्विच करने की सलाह दी जाती है। 2024 में पेश किया गया MySQL 8.4 LTS के आसपास ध्यान बढ़ रहा है, और यदि आप स्थिर दीर्घकालिक संचालन चाहते हैं तो इसे विचार करना उचित है।

भविष्य की योजना के लिए EOL जानकारी आवश्यक है

जैसा कि ऊपर दिखाया गया है, प्रत्येक MySQL संस्करण की एक नियोजित EOL होती है, और आपको उसके अनुसार माइग्रेशन की तैयारी करनी चाहिए। संस्करण को दोबारा जाँचें और यह न सोचें “हम अभी ठीक हैं,” बल्कि “हम कब माइग्रेट करेंगे?” पर विचार करें।

3. समर्थन समाप्त होने के बाद क्या होता है? EOL जोखिमों की व्याख्या

समर्थन समाप्त होने के बाद जारी रखने के जोखिम बहुत बड़े हैं

जब MySQL का संस्करण EOL (End of Life) तक पहुँच जाता है, आधिकारिक सुरक्षा अपडेट, बग फिक्स और सुधार पूरी तरह से बंद हो जाते हैं। दूसरे शब्दों में, आप Oracle से अब कोई समर्थन नहीं पा सकते।

भले ही सब कुछ सामान्य दिखे, गंभीर जोखिम सतह के नीचे छिपे हो सकते हैं। यह विशेष रूप से इंटरनेट‑फेसिंग वेब सर्वर या कोर बिज़नेस सिस्टम के लिए महत्वपूर्ण है।

अनपैच्ड सुरक्षा कमजोरियाँ

सबसे गंभीर समस्या यह है कि नए खोजे गए कमजोरियों को अब पैच नहीं किया जाएगा। हमलावर ज्ञात कमजोरियों की जानकारी का उपयोग करके EOL संस्करणों को लक्षित करते हैं।

और क्योंकि MySQL व्यापक रूप से उपयोग किया जाता है, यह एक आकर्षक लक्ष्य बन जाता है। यदि कमजोरियों का खुलासा EOL के बाद भी होता है, तो आपका रक्षा विकल्प अत्यंत सीमित हो जाता है क्योंकि कोई फिक्स कभी जारी नहीं होगा।

🔒 कोई पैच उपलब्ध नहीं = आप हमेशा एक लक्ष्य बने रहेंगे।

कानूनों और सुरक्षा मानकों का उल्लंघन करने का जोखिम

अधिक कंपनियों और सार्वजनिक संस्थानों को ISMS या PCI DSS जैसे मानकों का पालन करना आवश्यक है। ये मानक अक्सर स्पष्ट रूप से असमर्थित सॉफ़्टवेयर के उपयोग को प्रतिबंधित करते हैं।

इसका मतलब है कि EOL MySQL संस्करण चलाते रहना ऑडिट निष्कर्षों या व्यापारिक साझेदारों के साथ विश्वास को नुकसान पहुंचा सकता है।

OS या अन्य सॉफ़्टवेयर के साथ असंगतता के कारण संचालन संबंधी समस्याएँ

क्योंकि EOL संस्करण नए OS रिलीज़ या अन्य सॉफ़्टवेयर के साथ संगतता के लिए अब परीक्षण नहीं किए जाते, वे अप्रत्याशित विफलताएँ या प्रदर्शन समस्याएँ पैदा कर सकते हैं। वास्तविक उदाहरणों में OS अपडेट के बाद MySQL का शुरू न होना या प्रदर्शन का काफी गिरना शामिल है।

यह आपातकालीन फायरफ़ाइटिंग—या सबसे बुरे मामले में, सेवा डाउनटाइम की ओर ले जा सकता है।

यह तकनीकी ऋण के रूप में बढ़ता है

EOL संस्करण को जीवित रखना तकनीकी ऋण जमा करता है। जब अंततः आपको अपग्रेड करना पड़ेगा, तो माइग्रेशन लागतें तेज़ी से बढ़ सकती हैं, और आप पुराने व्यवहार पर निर्भर बड़े कोड बेस का सामना कर सकते हैं।

संक्षेप में, जितना देर आप इसे टालते हैं, लागत और जोखिम समय के साथ बढ़ते जाते हैं।

संचालन को सुरक्षित रखने के उपाय

EOL जोखिमों से बचने के लिए, आपको तुरंत अपग्रेड करने की ज़रूरत नहीं है—परंतु आपको एक माइग्रेशन योजना बनानी चाहिए। अपने वर्तमान संस्करण, EOL तक शेष समय, और गंतव्य चुनकर, आप आत्मविश्वास के साथ एक स्थिर वातावरण बनाए रख सकते हैं।

अगले भाग में, हम मुख्य माइग्रेशन विकल्पों और कौन‑से केस में वे सबसे उपयुक्त हैं, इसका परिचय देंगे।

4. Migration Options: Choose the Best Strategy for Your Goals

आपका EOL प्रतिक्रिया आपके “माइग्रेशन स्ट्रैटेजी” पर निर्भर करती है।

जब MySQL EOL के करीब आता है, सबसे महत्वपूर्ण निर्णय है “कहाँ माइग्रेट करें”। केवल अपग्रेड करना पर्याप्त नहीं है—ऐसा विकल्प चुनना जो आपकी आवश्यकताओं और संचालन संरचना से मेल खाता हो, भविष्य की स्थिरता निर्धारित करता है।

यहाँ तीन सामान्य माइग्रेशन पैटर्न और वे किस प्रकार के उपयोगकर्ताओं के लिए सबसे उपयुक्त हैं, प्रस्तुत हैं।

Upgrade to MySQL 8.0 or 8.4 LTS (conservative, stability‑focused)

सबसे सरल विकल्प है नए MySQL संस्करण में अपग्रेड करना। वर्तमान में, MySQL 8.0 मानक है, लेकिन 2024 से, MySQL 8.4 LTS (Long Term Support) ने ध्यान आकर्षित किया है।

• Pros:
• मौजूदा MySQL वातावरण के साथ उच्च संगतता
• ओपन सोर्स का उपयोग जारी रख सकते हैं
• MySQL Workbench जैसे मौजूदा टूल्स का उपयोग जारी रख सकते हैं
• Cons:
• सिंटैक्स/स्पेसिफिकेशन परिवर्तन के कारण संगतता त्रुटियाँ हो सकती हैं
• स्टोरेज सेटिंग्स और कैरेक्टर सेट्स पर ध्यान देना आवश्यक है
• Best for:
• छोटे से मध्यम आकार की कंपनियों और उन डेवलपर्स के लिए जो बड़े सिस्टम परिवर्तन के बिना स्थिर संचालन चाहते हैं

Migrate to alternative RDBMS like MariaDB or TiDB (flexibility and future‑proofing)

MySQL के साथ संगत किसी अन्य RDBMS में स्विच करना भी एक मजबूत विकल्प है। दो लोकप्रिय विकल्प हैं MariaDB और TiDB।

• MariaDB:
• MySQL का एक फोर्क, समान सिंटैक्स और प्रशासन के साथ
• समुदाय द्वारा सक्रिय रूप से विकसित
• समृद्ध प्रदर्शन अनुकूलन सुविधाएँ
• TiDB:
• एक क्लाउड-नेटिव, वितरित SQL डेटाबेस
• मजबूत उच्च उपलब्धता और स्केलेबिलिटी
• OLAP और OLTP दोनों को अच्छी तरह संभालता है, विश्लेषण के लिए भी उपयुक्त
• Best for:
• भविष्य में क्लाउड माइग्रेशन या बड़े पैमाने पर डेटा प्रोसेसिंग पर विचार करने वाले संगठन
• उन्नत ओपन-सोर्स तकनीक अपनाना चाहने वाली टीमें

प्रबंधित क्लाउड डेटाबेस सेवाएँ (ऑप कार्यभार कम, स्केलेबल)

यदि आप ऑन-प्रेम ऑपरेशनल ओवरहेड को कम करना चाहते हैं, तो प्रबंधित क्लाउड RDB सेवाओं पर विचार करें। सामान्य उदाहरण शामिल हैं:

• Amazon RDS for MySQL
• AWS द्वारा प्रदान की गई प्रबंधित सेवा
• स्वचालित बैकअप और रेडंडेंसी मानक हैं
• समय के साथ संभावित स्वचालित अपग्रेड्स के बारे में जागरूक रहें
• Google Cloud SQL for MySQL
• Google Cloud द्वारा प्रदान की गई प्रबंधित सेवा
• स्केलेबल और अन्य GCP सेवाओं के साथ अच्छी तरह एकीकृत
• UI के माध्यम से आसान प्रबंधन, शुरुआती के लिए अनुकूल
• Pros:
• OS या हार्डवेयर रखरखाव नहीं
• कम इन्फ्रास्ट्रक्चर विशेषज्ञता की आवश्यकता
• Cons:
• चल रहे क्लाउड लागतें
• फाइन-ग्रेन ट्यूनिंग कठिन हो सकती है
• Best for:
• छोटे से मध्यम आकार के वेब एप्लिकेशन चलाना
• स्टार्टअप्स और वेब व्यवसाय जो dev/ops संसाधनों को सरल बनाना चाहते हैं

[Comparison Table] Options and characteristics

अगले भाग में, हम व्यावहारिक माइग्रेशन चरणों और प्रमुख सावधानियों को स्पष्ट, कार्यात्मक तरीके से विभाजित करेंगे। चलिए गलतियों से बचने के लिए चेकलिस्ट देखते हैं।

5. MySQL माइग्रेशन चरण और चेकलिस्ट (विफलता से कैसे बचें)

माइग्रेशन सफलता “80% तैयारी” है

MySQL के EOL के कारण माइग्रेट करना साधारण संस्करण अपग्रेड से अलग है—यह सावधानीपूर्वक चरणों और पूरी तैयारी की मांग करता है। विशेष रूप से प्रोडक्शन सिस्टम के लिए, डेटा की अखंडता और सेवा निरंतरता सुनिश्चित करना शीर्ष प्राथमिकता है।

यहाँ हम पाँच चरणों में मुख्य कदम समझाते हैं।

STEP1: वर्तमान पर्यावरण का आकलन और सूची बनाना

पहले, अपने वर्तमान MySQL संस्करण, कॉन्फ़िगरेशन, और निर्भरताओं की पहचान करें।
निम्नलिखित आइटम जांचें:

• MySQL संस्करण और बिल्ड नंबर
• उपयोग में मौजूद कैरेक्टर सेट (जैसे, utf8mb4)
• स्टोरेज इंजन (InnoDB, MyISAM)
• उपयोग में SQL सिंटैक्स और फ़ंक्शन (संस्करण निर्भरताएँ हो सकती हैं)
• जुड़े हुए एप्लिकेशन और बाहरी सेवाएँ

✅ लक्ष्य: सभी निर्भरताओं को समझना ताकि माइग्रेशन के बाद की विफलताओं से बचा जा सके

STEP2: संगतता सत्यापित करें

जाँचें कि आपका वर्तमान पर्यावरण लक्षित संस्करण के साथ संगत है या नहीं। बड़े अपग्रेड में, विशेष ध्यान दें:

• हटाए गए सिंटैक्स / आरक्षित शब्द जो आप उपयोग कर रहे हो सकते हैं
• डिफ़ॉल्ट सेटिंग में परिवर्तन (जैसे, SQL मोड)
• सिस्टम वेरिएबल्स और पैरामीटर्स में अंतर

🔎 आप mysql_upgrade कमांड या MySQL Shell Upgrade Checker Utility का उपयोग करके संगतता का निदान कर सकते हैं।

STEP3: बैकअप लें और परीक्षण पर्यावरण बनाएं

प्रोडक्शन को सीधे अपग्रेड करना बहुत जोखिमपूर्ण है।
पहले, पूर्ण बैकअप लें और उसे स्टेजिंग (टेस्ट) पर्यावरण बनाने के लिए उपयोग करें।

• mysqldump या mysqlpump का उपयोग करके बैकअप डंप करें
• फ़ाइल-आधारित बैकअप (जैसे, XtraBackup)
• स्टेजिंग में पुनर्स्थापित करें और एप्लिकेशन व्यवहार का परीक्षण करें

माइग्रेशन के बाद की समस्याओं और SQL त्रुटियों को पहले से खोजकर, आप प्रोडक्शन कटओवर के दौरान समस्याओं को न्यूनतम कर सकते हैं।

STEP4: डेटा को प्रोडक्शन में माइग्रेट करें

सत्यापन के बाद, प्रोडक्शन में माइग्रेट करें। यदि संभव हो, इसे रात में या कम ट्रैफ़िक के समय करें।

• माइग्रेशन से ठीक पहले अंतिम बैकअप
• अस्थायी रूप से सेवा को रोकें (यदि संभव हो तो मेंटेनेंस पेज उपयोग करें)
• नए डेटाबेस संस्करण में डेटा इम्पोर्ट करें
• कॉन्फ़िग फ़ाइलों और पर्यावरण वेरिएबल्स को समायोजित करें

यदि आपको एप्लिकेशन पक्ष में भी परिवर्तन करने की आवश्यकता है (जैसे MySQL एंडपॉइंट बदलना), तो समय के बारे में विशेष सावधानी बरतें।

STEP5: सत्यापित करें और अनुकूलित करें

माइग्रेशन कटओवर पर समाप्त नहीं होता।
नए पर्यावरण की स्थिरता की पुष्टि करने के लिए निम्नलिखित जांचें:

• एप्लिकेशन से कनेक्टिविटी
• क्वेरी निष्पादन गति और कोई भी त्रुटियाँ
• लॉग मॉनिटरिंग (एरर लॉग, स्लो क्वेरी लॉग)
• कैश सेटिंग्स और इंडेक्स रीबिल्ड्स का अनुकूलन

जैसे आवश्यक हो, ANALYZE TABLE या OPTIMIZE TABLE चलाएँ ताकि माइग्रेशन द्वारा उत्पन्न प्रदर्शन गिरावट को पुनः प्राप्त किया जा सके।

Checklist (final review)

✅ वर्तमान संस्करण और कॉन्फ़िगरेशन की पुष्टि करें
✅ अग्रिम रूप से संगतता जांच चलाएँ
✅ पूर्ण बैकअप लें
✅ स्टेजिंग वातावरण में परीक्षण करें
✅ नियोजित प्रोडक्शन कटओवर निष्पादित करें
✅ माइग्रेशन के बाद त्रुटियों और प्रदर्शन की निगरानी करें

सफलता की कुंजी निष्पादन योजना है। EOL-चालित माइग्रेशन के लिए, स्थिर तैयारी, परीक्षण, और सावधान कटओवर सबसे अच्छा जोखिम-निवारण रणनीति है।

6. Handling EOL on Cloud Services (For AWS and GCP Users)

Even on the cloud, you can’t be complacent

भले ही आप Amazon RDS या Google Cloud SQL जैसे क्लाउड प्लेटफ़ॉर्म पर MySQL का उपयोग करें, EOL (समर्थन समाप्ति) अभी भी आपका मुद्दा है। क्लाउड प्रदाता स्वचालित अपग्रेड या यहाँ तक कि सेवा सेवानिवृत्ति लागू कर सकते हैं असमर्थित संस्करणों के लिए, इसलिए सक्रिय योजना महत्वपूर्ण है।

नीचे प्रमुख क्लाउड सेवाओं द्वारा EOL संभालने का एक अवलोकन है।

Amazon RDS for MySQL: watch out for automatic upgrades

Amazon RDS for MySQL के साथ, AWS ने कई बार समर्थन समाप्ति के कारण संस्करण सेवानिवृत्ति और बाध्यकारी अपग्रेड किए हैं।

• MySQL 5.5: 2018 में समाप्त → स्वचालित रूप से 5.6 में माइग्रेट किया गया
• MySQL 5.6: 2021 में समाप्त → 2022 के बाद 5.7 में स्वचालित अपग्रेड लागू किया गया

परिणामस्वरूप, आपका MySQL संस्करण आपके न चाहने वाले समय पर बदल सकता है, जिससे एप्लिकेशन समस्याएँ या प्रदर्शन गिरावट हो सकती है।

✅ निवारण: अपने स्वयं के शेड्यूल पर अपग्रेड की योजना बनाएँ और निष्पादित करें

AWS ईमेल और कंसोल नोटिफिकेशन के माध्यम से अग्रिम सूचना प्रदान करता है, लेकिन यदि आप इसे अनदेखा करते हैं, तो यह स्वचालित रूप से लागू हो सकता है—इसलिए सावधान रहें।

Google Cloud SQL for MySQL: first-gen retirement and migration push

Cloud SQL for MySQL भी पुराने संस्करणों और आर्किटेक्चर की सेवानिवृत्ति की दिशा में आगे बढ़ रहा है।

• पहली पीढ़ी के इंस्टेंस अब नए नहीं बनाए जा सकते
• उन संस्करणों के लिए अपग्रेड को प्रोत्साहित करने वाली नीतियाँ हैं जो समर्थन समाप्ति के करीब हैं

Google उपयोगकर्ता की लचीलापन का सम्मान करता है, लेकिन दीर्घकालिक “जीवन समर्थन” की सीमाएँ हैं, इसलिए आपको बाद में नहीं बल्कि पहले अपग्रेड या पुनः निर्माण करना चाहिए।

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

✅ क्लाउड-विशिष्ट सेटिंग्स और संगतता का अग्रिम परीक्षण करें

Cloud benefits—and EOL pitfalls

क्लाउड सेवाओं के पास लाभ हैं, लेकिन कमजोर EOL तैयारी समस्याएँ पैदा कर सकती है।

क्लाउड में भी, वास्तविकता वही है: आप अभी भी EOL से निपटने के लिए जिम्मेदार हैं।

EOL checklist for cloud environments

✅ अपने वर्तमान MySQL संस्करण और EOL टाइमलाइन की जाँच करें
✅ विक्रेता नोटिफिकेशन (ईमेल या अन्य चैनल) सक्षम करें
✅ पुष्टि करें कि क्या आप स्वचालित अपग्रेड के अधीन हैं
✅ स्टेजिंग में नए संस्करण का परीक्षण करें
✅ आवश्यकतानुसार एप्लिकेशन-साइड परिवर्तन की योजना बनाएँ

क्लाउड सुविधा का अधिकतम लाभ उठाने के लिए, “सेट और भूलें” नहीं। अपने पक्ष में सक्रिय प्रबंधन और मॉनिटरिंग बनाए रखें। विशेष रूप से MySQL EOL के लिए, क्लाउड वातावरण को अभी भी ठोस तैयारी की आवश्यकता होती है।

7. Frequently Asked Questions (FAQ)

Q1: Can I keep using MySQL after support ends?

उ: तकनीकी रूप से हाँ, लेकिन यह अनुशंसित नहीं है।
EOL MySQL को कोई सुरक्षा पैच या बग फिक्स नहीं मिलते। इससे कमजोरियों का शोषण करने वाले हमलों का जोखिम तेज़ी से बढ़ता है और यह कानूनों या सुरक्षा नीतियों का उल्लंघन कर सकता है।

भले ही सिस्टम ठीक दिखे, आप अभी भी गंभीर छिपे जोखिम के साथ काम कर रहे हैं, इसलिए जल्दी अपग्रेड या माइग्रेशन की योजना बनाएँ।

Q2: What’s the difference between MySQL 8.0 and 8.4 LTS?

A: MySQL 8.4 LTS एक स्थिर रिलीज़ है जो लंबी अवधि के लिए समर्थित है।
MySQL 8.0 नियमित रिलीज़ चक्र का पालन करता है, और प्रीमियम सपोर्ट अप्रैल 2025 में समाप्त होने की योजना है। इसके विपरीत, MySQL 8.4 LTS (Long Term Support) को लगभग पाँच वर्षों की दीर्घकालिक समर्थन के साथ एक स्थिर रिलीज़ के रूप में पेश किया गया था।

यदि आप व्यावसायिक सिस्टम के लिए दीर्घकालिक स्थिरता को प्राथमिकता देते हैं, तो MySQL 8.4 LTS में माइग्रेट करना अनुशंसित है।

Q3: माइग्रेशन की लागत कितनी है?

A: यह स्केल और माइग्रेशन पाथ पर बहुत निर्भर करता है।
उदाहरण के लिए, उसी सर्वर पर संस्करण अपग्रेड कोई सीधा खर्च नहीं के साथ संभव हो सकता है। लेकिन क्लाउड सेवाओं में माइग्रेट करना या उत्पाद (MariaDB/TiDB) बदलना डिज़ाइन, निर्माण, परीक्षण और तकनीकी समर्थन के लिए प्रयास और खर्च की आवश्यकता कर सकता है।

आपको डाउनटाइम कम करने और एक स्टेजिंग वातावरण तैयार करने की लागत भी विचार करनी चाहिए।

Q4: प्रोडक्शन सिस्टम को माइग्रेट करते समय किन बातों का ध्यान रखें?

A: प्री‑टेस्टिंग और चरणबद्ध माइग्रेशन मुख्य हैं।
प्रोडक्शन में, आपको संगतता जांच, बैकअप और स्टेजिंग टेस्ट करने चाहिए। रीड रेप्लिका या ब्लू‑ग्रीन डिप्लॉयमेंट (पुराने और नए वातावरण को साथ‑साथ चलाना और धीरे‑धीरे स्विच करना) का उपयोग करने से डाउनटाइम कम हो सकता है।

यह सबसे सुरक्षित है कि काम रात में या सप्ताहांत में किया जाए जब ट्रैफ़िक कम हो।

Q5: क्या मैं क्लाउड में ऑटोमैटिक अपग्रेड को रोक सकता हूँ?

A: आप कुछ हिस्सों को नियंत्रित कर सकते हैं, लेकिन अंततः आपको विक्रेता की नीति का पालन करना होगा।
RDS और Cloud SQL कुछ नियंत्रण जैसे ऑटोमैटिक अपग्रेड शेड्यूल को देर से शुरू करना या समायोजित करना की अनुमति देते हैं, लेकिन EOL के बाद भी जबरन अपग्रेड हो सकते हैं।

क्योंकि दीर्घकालिक बचाव कठिन है, सबसे भरोसेमंद तरीका आपके द्वारा नियोजित अपग्रेड है।

Q6: मुझे वैकल्पिक डेटाबेस कैसे चुनना चाहिए?

A: इन तीन मानदंडों का उपयोग करें।

1. संगतता : आपका मौजूदा एप्लिकेशन और SQL कितना बिना बदलाव के काम करेगा
2. स्केलेबिलिटी / भविष्य‑सुरक्षा : क्या यह डेटा और ट्रैफ़िक में वृद्धि को संभाल सकता है
3. ऑपरेशनल क्षमता : क्या आप इसे इन‑हाउस रख सकते हैं या विक्रेता समर्थन की आवश्यकता है

व्यावसायिक सिस्टम के लिए, चयन आपके वास्तविक ऑपरेशनल क्षमता पर आधारित होना चाहिए, न कि ट्रेंड्स पर।

8. सारांश: सपोर्ट समाप्त होने से पहले आप जो सबसे अच्छा कदम उठा सकते हैं

EOL “दूर नहीं” है—यह बिलकुल पास है

MySQL EOL (समर्थन समाप्ति) केवल आईटी स्टाफ के लिए ही नहीं है। यह पूरे संगठन को सुरक्षा, प्रदर्शन, उपलब्धता और लागत प्रबंधन के पहलुओं में प्रभावित करता है।

MySQL 5.7 ने अक्टूबर 2023 में समर्थन समाप्त कर दिया है, और MySQL 8.0 का प्रीमियम सपोर्ट अप्रैल 2025 में समाप्त होने की योजना है। यदि आप सोचते हैं “यह अभी भी चल रहा है, इसलिए ठीक है,” तो आप महत्वपूर्ण जोखिम के साथ काम कर रहे होंगे इससे पहले कि आप इसे समझें।

नियोजित माइग्रेशन सबसे अच्छा जोखिम‑परिहार रणनीति है

जैसा कि इस लेख में दिखाया गया है, माइग्रेशन कठिन नहीं है जब इसे चरण‑दर‑चरण किया जाए:

• वर्तमान संस्करण की पहचान करें
• संगतता जांचें और माइग्रेशन गंतव्य चुनें
• स्टेजिंग वातावरण में परीक्षण करें
• चरणबद्ध माइग्रेशन और अंतिम कटओवर करें

इन चरणों का पालन करके आप सुरक्षित रूप से माइग्रेशन पूरा कर सकते हैं और डाउनटाइम तथा डेटा हानि से बच सकते हैं।

भले ही आप क्लाउड सेवाओं का उपयोग कर रहे हों, सब कुछ विक्रेता पर न छोड़ें—अपनी स्थिति को समझें और सक्रिय रूप से एक अपग्रेड योजना बनाएं।

“मुझे नहीं पता था” अब कोई बहाना नहीं है

आधुनिक सिस्टम ऑपरेशन्स में, केवल तकनीकी ज्ञान ही नहीं, बल्कि निरंतर रखरखाव जागरूकता भी आवश्यक है। समर्थन समाप्ति समयसीमा को जानना, जोखिम का मूल्यांकन करना, और सबसे अच्छा माइग्रेशन विकल्प चुनना सभी ऑपरेटर और डेवलपर के लिए आवश्यक कौशल हैं।

अंत में: अभी करने के लिए तीन कार्य

1. अपने सिस्टम में उपयोग किए जा रहे MySQL संस्करण की जाँच करें
2. EOL तिथि की पुष्टि करें और उसे अपने कैलेंडर में जोड़ें
3. अपनी टीम के साथ माइग्रेशन दृष्टिकोण (अपग्रेड बनाम डेटाबेस बदलना) पर चर्चा करें

इनमें से केवल इन कार्यों को करने से आपका अगला कदम स्पष्ट हो जाएगा।

MySQL EOL को संभालना भविष्य की घटनाओं के खिलाफ एक “बीमा नीति” है।
इस लेख का उपयोग अपने संचालन की समीक्षा करने और एक सुरक्षित, सतत पर्यावरण बनाने के लिए ट्रिगर के रूप में करें।