آموزش جامع و گام‌به‌گام رفع خطای Error Establishing a Database Connection در وردپرس

خطای Error Establishing a Database Connection یکی از حساس‌ترین مشکلاتی است که می‌تواند وب‌سایت وردپرسی را به طور کامل از دسترس خارج کند. این خطا نشان می‌دهد که کدهای سیستم مدیریت محتوا توانایی برقراری ارتباط با دیتابیس و خواندن اطلاعات برگه، پست‌ها یا تنظیمات را ندارند. در این مقاله جامع، کلیه دلایل ریشه‌ای این اختلال فنی را بررسی کرده و گام‌های عملی رفع آن را با کدهای نمونه و تجربیات واقعی سرور بررسی می‌کنیم.

خطای عدم ارتباط با دیتابیس چیست و چگونه رخ می‌دهد؟

پاسخ کوتاه: این خطا زمانی ایجاد می‌شود که مفسر PHP وردپرس هنگام اجرا، نتواند به مفسر MySQL/MariaDB متصل شود. علت این اتفاق یا نادرست بودن اطلاعات احراز هویت در فایل تنظیمات است، یا خرابی جداول دیتابیس، و یا متوقف شدن سرویس MySQL در سرور به دلیل کمبود منابع.

وردپرس یک سیستم پویاست؛ به این معنی که هیچ صفحه استاتیک HMTL روی سرور ذخیره نشده است. هر زمان که کاربری آدرس سایت شما را باز می‌کند، موتور PHP اجرا شده و اطلاعات پردازش‌شده را از دیتابیس فراخوانی می‌کند. اگر در این مسیر، اتصال در لایه شبکه، احراز هویت یا لایه ساختار داده دچار خرابی شود، پیام خطای اتصال نمایش داده خواهد شد. این موضوع می‌تواند فوراً افت ترافیک و صدمه به سئوی سایت را به همراه داشته باشد.

۴ علت اصلی قطع اتصال وردپرس با پایگاه داده

تجربه عیب‌یابی صدها سایت وردپرسی نشان می‌دهد که این خطا معمولاً خارج از چهار دسته زیر نیست:

• اشتباه در اعتبارنامه‌ها (Credentials): تغییری در نام دیتابیس، نام کاربری یا رمز عبور در هاست ایجاد شده ولی فایل wp-config.php به‌روزرسانی نشده است.
• خرابی جداول دیتابیس (Corrupted Tables): بسته شدن ناگهانی فرایند نوشتن (به دلیل پر شدن دیسک یا ریستارت سرور) باعث آسیب به جداول InnoDB یا MyISAM شده است.
• خاموش شدن سرویس MySQL (Service Down): مصرف بیش از حد منابع (RAM/CPU) باعث شده مدیریت منابع لینوکس (OOM Killer) سرویس دیتابیس را متوقف کند.
• ناهماهنگی پیشوند جداول (Table Prefix Mismatch): تغییر متغیر $table_prefix در فایل تنظیمات بدون تغییر نام واقعی جداول در دیتابیس.

گام اول: بررسی و ویرایش اطلاعات در wp-config.php

پاسخ کوتاه: فایل wp-config.php در مسیر اصلی هاست قرار دارد. باید مقادیر DB_NAME، DB_USER، DB_PASSWORD و DB_HOST را با اطلاعات موجود در بخش MySQL Databases هاست (cPanel یا DirectAdmin) تطبیق دهید.

برای بررسی این فایل، وارد File Manager هاست خود شوید و فایل wp-config.php را برای ویرایش باز کنید. ثوابت زیر را پیدا کنید:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'database_name_here' );

/** MySQL database username */
define( 'DB_USER', 'username_here' );

/** MySQL database password */
define( 'DB_PASSWORD', 'password_here' );

/** MySQL hostname */
define( 'DB_HOST', 'localhost' );

جهت اطمینان از صحت این اطلاعات، مراحل زیر را طی کنید:

1. وارد کنترل‌پنل هاست شده و به بخش MySQL Databases بروید.
2. اطمینان حاصل کنید که نام دیتابیس دقیقا با DB_NAME یکسان باشد.
3. بررسی کنید که کاربر (User) به آن دیتابیس منتسب شده باشد و دسترسی All Privileges داشته باشد.
4. اگر از رمز عبور اطمینان ندارید، رمز کاربر دیتابیس را در هاست تغییر داده و مقدار جدید را در DB_PASSWORD جای‌گذاری کنید.
5. اگر بررسی مقادیر تخصصی سایت مانند تکه‌کدهای مدیریت فایل را انجام می‌دهید، مطالعه بخش تکه‌کدهای وردپرس در درک بهتر متغیرهای کانفیگ به شما کمک می‌کند.

گام دوم: تعمیر دیتابیس آسیب‌دیده با ابزار داخلی وردپرس

پاسخ کوتاه: اگر در بخش مدیریت سایت خطایی متفاوت با بخش عمومی دریافت می‌کنید (مثلاً One or more database tables are unavailable)، جداول آسیب دیده‌اند. با افزودن ثابت define('WP_ALLOW_REPAIR', true); به فایل کانفیگ می‌توانید از ابزار تعمیر خودکار استفاده کنید.

برای فعال‌سازی تعمیرکار داخلی وردپرس، خط زیر را درست قبل از عبارت /* That's all, stop editing! Happy publishing. */ در فایل wp-config.php قرار دهید:

define( 'WP_ALLOW_REPAIR', true );

سپس در مرورگر خود به آدرس زیر بروید (نام دامنه خود را جایگزین کنید):

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

در این صفحه روی دکمه Repair Database (تعمیر دیتابیس) یا Repair and Optimize Database کلیک کنید.

گام سوم: عیب‌یابی سرور و سرویس دیتابیس (MySQL/MariaDB)

پاسخ کوتاه: اگر تمام اطلاعات وردپرس درست است اما همچنان خطا باقی است، احتمالاً سرویس MySQL در سرور متوقف شده است. در سرورهای اختصاصی/مجازی باید سرویس را با دستور systemctl restart mysql ریستارت کنید.

اگر از هاست اشتراکی استفاده می‌کنید، در این مرحله باید با پشتیبانی هاست تماس بگیرید زیرا سرویس دیتابیس سرور احتمالا به دلیل فشار بالای سایر کاربران crash کرده است. اما اگر دسترسی SSH به سرور مجازی (VPS) یا اختصاصی دارید، دستورات زیر را اجرا کنید:

# بررسی وضعیت سرویس در اوبونتو / دبیان
systemctl status mysql

# بررسی وضعیت سرویس در سنت او اس / آلمالیپوکس
systemctl status mariadb

# راه اندازی مجدد سرویس
systemctl restart mysql

اگر سرویس پس از استارت مجدد بلافاصله متوقف می‌شود، حافظه رم سرور پر شده است. می‌توانید لاگ‌های مربوط به قطع شدن سرویس را بررسی کنید. توسعه‌دهندگانی که با اتوماسیون سرور کار می‌کنند، معمولاً از اسکریپت‌های پایتون برای مانیتورینگ رم استفاده می‌کنند؛ برای مطالعه بیشتر در این زمینه می‌توانید به بخش تکه‌کدهای پایتون مراجعه کنید.

جدول تشخیص سریع علت خطا براساس علائم سیستم

جدول زیر به شما کمک می‌کند بر اساس نحوه بروز خطا، علت اصلی را سریع‌تر پیدا کنید:

نکات تخصصی و تجربیات عملی که کمتر جایی گفته می‌شود

در عیب‌یابی‌های پیشرفته، گاهی اوقات همه چیز ظاهراً درست است اما خطا برطرف نمی‌شود. در ادامه سه نکته فنی کلیدی را بررسی می‌کنیم:

۱. تفاوت مهم localhost و 127.0.0.1 (UNIX Socket vs TCP/IP)

هنگامی که در فایل کانفیگ عبارت localhost را قرار می‌دهید، PHP سعی می‌کند از طریق **UNIX Socket** به MySQL متصل شود. اما وقتی از 127.0.0.1 استفاده می‌کنید، اتصال از طریق **پروتکل شبکه‌ای TCP/IP** برقرار می‌شود. اگر سوکت مای‌اس‌کیوال در مسیر پیش‌فرض نباشد، قرار دادن localhost باعث خطا می‌شود در حالی که تغییر آن به 127.0.0.1 یا اضافه کردن پورت (مثل 127.0.0.1:3306) مشکل را فوراً حل می‌کند.

۲. کش شدن برگه خطا در شبکه توزیع محتوا (Cloudflare / CDN)

بسیاری از اوقات شما مشکل دیتابیس را برطرف کرده‌اید، اما کلودفلر برگه HTTP 500 یا خطای قدیمی را کش کرده و به کاربران نشان می‌دهد. حتما پس از اصلاح دیتابیس، یک‌بار **Purge Everything** را در CDN خود بزنید و کش مرورگر را پاک کنید. طراحی و استایل صفحات خطا معمولاً با ساختارهای مبنا در تکه‌کدهای CSS مشخص می‌شود که کش شدن آن‌ها ممکن است حالت صفحه را بدون تغییر نشان دهد.

۳. کشته شدن MySQL توسط Linux OOM Killer

اگر از سرور اختصاصی استفاده می‌کنید و خطا به صورت تصادفی ظاهر و غیب می‌شود، سیستم‌عامل لینوکس به دلیل کمبود حافظه RAM ناچار می‌شود سنگین‌ترین فرآیند که معمولاً mysqld است را متوقف کند (Kill). با اجرای دستور dmesg -T | grep -i oom در ترمینال سرور می‌توانید متوجه شوید که آیا سرویس دیتابیس توسط هسته لینوکس کشته شده است یا خیر. حل این مشکل با افزودن حافظه SWAP یا ارتقای RAM سرور انجام می‌شود.

راهنمای عیب‌یابی سریع (Troubleshooting Matrix)

اگر می‌خواهید در کوتاه‌ترین زمان ممکن مشکل را ریشه‌یابی کنید، چک‌لیست زیر را گام‌به‌گام دنبال کنید:

<?php
$link = mysqli_connect('localhost', 'db_user', 'db_password');
if (!$link) {
    die('خطا در اتصال: ' . mysqli_connect_error());
}
echo 'اتصال با موفقیت برقرار شد!';
mysqli_close($link);
?>

برای بررسی سایر ابزارها و اسکریپت‌های کاربردی توسعه وب، می‌توانید از بخش عمومی مجموعه تکه‌کدهای کاربردی استفاده کنید. همچنین ساختار صفحات HTML تست در بخش تکه‌کدهای HTML و کدهای تعاملی در تکه‌کدهای جاوااسکریپت در دسترس هستند.

پرسش‌های متداول