WordPress में "Error Establishing a Database Connection": इसे कैसे ठीक करें

आप अपनी साइट खोलते हैं और हर पेज — फ्रंट एंड और wp-admin, दोनों — की जगह बस एक धूसर वाक्य आ जाता है: Error establishing a database connection. कुछ भी नहीं दिखता, क्योंकि कुछ दिख ही नहीं सकता। WordPress पेज बनाने तक पहुँचा ही नहीं।

इसे जल्दी ठीक करने के लिए यह मॉडल दिमाग में रखें। WordPress आपकी सारी सामग्री — posts, pages, settings, users — किसी फाइल में नहीं, बल्कि एक MySQL डेटाबेस में रखता है। हर request पर वह wp-config.php से चार login जानकारियाँ पढ़ता है, उस डेटाबेस से जुड़ता है, और जो चाहिए वह खींच लाता है। इस error का मतलब है कि वह कनेक्शन आजमाया गया और ठुकरा दिया गया। हल यह पता लगाने में है कि उसे क्यों ठुकराया गया, और इसकी सिर्फ तीन ही संभावनाएँ हैं।

तीन वजहें, संभावना के क्रम में

1. wp-config.php में कोई गलत credential — आमतौर पर होस्ट बदलने का नतीजा।
2. डेटाबेस सर्वर बंद है या ओवरलोड है — आमतौर पर आपकी तरफ से कुछ न बदलने का नतीजा।
3. डेटाबेस खराब हो गया है — कम आम, और यह खुद को अलग तरीके से जाहिर करता है।

इन्हें इसी क्रम में जाँचें।

चरण 1: चारों credentials जाँचें

SFTP या अपने होस्ट के फाइल मैनेजर से अपनी साइट के root में मौजूद wp-config.php खोलें। चार लाइनें इस कनेक्शन को परिभाषित करती हैं:

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

इनमें से हर एक आपके होस्ट द्वारा दिए गए मान से हूबहू मेल खाना चाहिए। अपने hosting कंट्रोल पैनल का डेटाबेस सेक्शन खोलें (cPanel में यह “MySQL Databases” है) और एक-एक अक्षर मिलाएँ:

• DB_NAME — होस्ट अक्सर नाम के आगे आपके account का prefix लगा देते हैं, जैसे cpaneluser_wpdb। वह prefix नाम का हिस्सा है।
• DB_USER — वही prefix यहाँ भी लगता है, और user का उस डेटाबेस से जुड़ा होना जरूरी है, सिर्फ मौजूद होना काफी नहीं।
• DB_PASSWORD — सबसे आम गुनहगार। अगर पक्का न हो, तो कंट्रोल पैनल में इसे reset करें और नया मान पेस्ट कर दें। आखिर में कोई खाली जगह या smart quote न रह जाए, इसका ध्यान रखें।
• DB_HOST — localhost मान बैठने की गलती न करें। कई होस्ट एक अलग डेटाबेस सर्वर इस्तेमाल करते हैं, जिसका पता mysql.yourhost.com जैसा होता है, कभी-कभी :port के साथ। सही मान कंट्रोल पैनल में दिखता है।

चूँकि ये चारों मान इसी फाइल में रहते हैं, एक साफ-सुथरी और सही तरह quote की गई wp-config.php दोबारा बनाने का सबसे सुरक्षित तरीका है wp-config.php generator — चारों डेटाबेस फ़ील्ड भरें और नतीजे को पुराने ब्लॉक के ऊपर पेस्ट कर दें।

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

चरण 2: पुष्टि करें कि डेटाबेस सर्वर सचमुच चालू है

अगर credentials सही हैं और error फिर भी बनी हुई है — खासकर तब जब वह अपने आप आई हो, आपकी तरफ से बिना किसी बदलाव के — तो शक डेटाबेस सर्वर पर ही जाता है।

shared hosting पर यह आम है और आमतौर पर अस्थायी: ट्रैफिक बढ़ने पर MySQL सेवा दब जाती है या अपनी per-account कनेक्शन सीमा पर पहुँचकर नए कनेक्शन ठुकराने लगती है। यह आमतौर पर कुछ ही मिनटों में सँभल जाती है। कोई बड़ा कदम उठाने से पहले थोड़ा रुककर पेज दोबारा लोड करें।

यह जाँचने के लिए कि credentials WordPress से अलग भी सही हैं या नहीं, wp-config.php के बगल में एक छोटा-सा script रख दें:

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

अपने असली DB_HOST, DB_USER और DB_PASSWORD इस्तेमाल करें। अगर यह Connected छापे, तो आपकी login जानकारी काम कर रही है और समस्या कहीं और है (खराब डेटाबेस, चरण 3)। अगर यह कोई connection error छापे, तो मैसेज बता देता है कि कौन-सी: “Access denied” का मतलब गलत user या password; “Can’t connect to MySQL server” का मतलब गलत host या सचमुच बंद सेवा — अब होस्ट से संपर्क करने का समय है। काम पूरा होते ही script हटा दें।

चरण 3: खराब डेटाबेस की मरम्मत करें

एक निशानी corruption को कनेक्शन समस्या से अलग करती है: फ्रंट एंड लोड होता है पर wp-admin error दिखाता है, या इसका उल्टा। अगर कनेक्शन सचमुच ठुकराया गया होता, तो दोनों ठप होते। ऐसा बँटा हुआ बर्ताव खराब tables की तरफ इशारा करता है।

WordPress में एक built-in repair टूल होता है। wp-config.php में, “stop editing” वाली टिप्पणी के ऊपर, एक लाइन जोड़ें:

define( 'WP_ALLOW_REPAIR', true );

फिर सीधे अपने ब्राउज़र में यह URL खोलें:

https://yoursite.com/wp-admin/maint/repair.php

यह बिना login के लोड होता है — यही तो बात है, क्योंकि हो सकता है आप बाहर बंद हों — और “Repair Database” तथा “Repair and Optimize Database” के विकल्प देता है। इसे चलाएँ।

फिर तुरंत वह लाइन wp-config.php से हटा दें। जब तक वह मौजूद है, इंटरनेट पर कोई भी उस URL पर पहुँचकर आपके डेटाबेस पर repair चला सकता है। यह कोई मर्जी की सफाई नहीं है; यह उस छेद को बंद करना है जो आपने अभी-अभी खोला था।

चरण 4: जब repair जुड़ ही न पाए

अगर repair पेज खुद ही connection error दिखाए, तो मरम्मत करने को कुछ है ही नहीं — डेटाबेस तक पहुँचा ही नहीं जा सकता, यानी आप वापस चरण 1 या चरण 2 पर आ गए। ऐसे में भरोसेमंद कदम है डेटाबेस को अपने होस्ट के सबसे ताजा बैकअप से restore करना। ज्यादातर कंट्रोल पैनल रोजाना अपने आप डेटाबेस के snapshots रखते हैं; कल रात के बैकअप से restore करना लगभग हमेशा उस corruption के पीछे भागने से तेज और सुरक्षित है जिससे आप जुड़ ही नहीं सकते।

वह सलाह जिसे आराम से नजरअंदाज किया जा सकता है

“बस WordPress दोबारा इंस्टॉल कर दो।” यह error डेटाबेस कनेक्शन की है, core फाइलों की नहीं। दोबारा इंस्टॉल करने से वही फाइलें बदलती हैं जो ठीक-ठाक चल रही हैं, और जो टूटा है उसे यह छूता तक नहीं।

“अपनी PHP memory limit बढ़ा दो।” मेमोरी खत्म होना एक अलग error है, जिसका मैसेज भी अलग होता है। लिमिट बढ़ाने से ठुकराए गए डेटाबेस कनेक्शन पर कोई असर नहीं पड़ता, और यह बस इतना छिपा देती है कि आपने credentials जाँचे ही नहीं।

“अपना cache क्लियर कर दो।” यह नाकामी PHP में तब होती है जब कोई cache किसी पेज को परोस भी नहीं पाता। जब तक कनेक्शन ठुकराया जा रहा है, cache क्लियर करने से कुछ नहीं बदलता; यह सिर्फ साइट वापस आने के बाद करने लायक है।

“डेटाबेस को सीधे एडिट करके ठीक कर दो।” कनेक्शन काम कर भी रहा है या नहीं, यह पक्का किए बिना phpMyAdmin खोलकर tables को हाथ से एडिट करना ही वह तरीका है जिससे एक अस्थायी outage स्थायी data loss बन जाता है। पहले कनेक्शन पक्का करें; data को सबसे आखिर में छुएँ, और वह भी सिर्फ किसी बैकअप से।

फिर भी अटके हुए हैं?

अगर test script से credentials सही निकलें, सर्वर चालू हो, और repair जुड़कर कोई error न बताए, फिर भी साइट वही मैसेज दिखाए, तो बचा हुआ शक एक ऐसे plugin पर है जो अपने अलग कनेक्शन से डेटाबेस से बात करता है — कोई caching या डेटाबेस plugin जिसने कोई पुराना host सहेज रखा हो। इसे रद्द करने के लिए SFTP से wp-content/plugins का नाम बदलकर plugins-off कर दें। अगर error हट जाए, तो plugins को एक-एक करके वापस लाएँ, जब तक वह दोबारा न लौटे।