برای رفع خطای اتصال به پایگاه داده وردپرس، ابتدا مشخص کنید اتصال رد میشود، مقصد دیتابیس در دسترس نیست، یا اتصال برقرار است اما جدولهای لازم پیدا نمی‌شوند. اطلاعات اتصال را با پنل میزبان تطبیق دهید و پیش از تعمیر یا بازیابی، از داده‌های فعلی نسخهٔ قابل بازیابی تهیه کنید؛ نصب دوباره معمولاً پاسخ این خطا نیست.
راهحل سریع و ایمن
- زمان شروع خطا، آخرین تغییر و دامنهٔ درگیری را ثبت کنید؛ صفحهٔ عمومی، ورود و یک صفحهٔ پویا را جدا ببینید. نمایش سالم صفحهٔ کش‌شده را نشانهٔ سلامت دیتابیس ندانید.
- در پنل ارائه‌دهندهٔ میزبانی، وضعیت سرویس پایگاه داده و محدودیت مصرف حساب را بررسی کنید. اگر چند برنامه هم‌زمان قطع شده‌اند، پیش از تغییر رمز یا فایل‌ها موضوع را به همان ارائهدهنده گزارش دهید.
- از فایل فعال wp-config.php یک نسخهٔ خصوصی خارج از پوشهٔ عمومی نگه دارید و مقادیر DB_NAME، DB_USER و DB_HOST را با مشخصات همان محیط مقایسه کنید؛ رمز را در تصویر یا تیکت قرار ندهید.
- بررسی کنید کاربر دیتابیس به همان پایگاه داده متصل و دارای مجوز لازم است. ورود به ابزار مدیریت دیتابیس با حساب پنل، اتصال موفق کاربر برنامه را ثابت نمی‌کند.
- اگر خطا پس از انتقال رخ داده، میزبان، پورت، سوکت و پیشوند جدول‌ها را جدا بررسی کنید. دیدن صفحهٔ نصب را با قطع ارتباط یکی نگیرید و نصب جدید را ادامه ندهید.
- برای خطای متناوب، زمان دقیق درخواست ناموفق را با گزارش محدودیت اتصال یا توقف سرویس تطبیق دهید. افزونه‌ها، صف‌ها و کارهای زمان‌بندی‌شده را فقط با شواهد و ترجیحاً در محیط آزمایشی بررسی کنید.
- پس از اصلاح یک علت، ورود، خواندن نوشته، ذخیرهٔ پیشنویس و مسیر فروشگاه را کنترل کنید. اگر خطا باقی است، تغییر را برگردانید و گزارش پالایش‌شده را به مسئول دیتابیس بدهید؛ ابزار تعمیر عمومی را باز رها نکنید.
پیش از تغییر، دسترسی و نقطهٔ بازگشت را مشخص کنید
حداقل دسترسی مفید شامل مدیریت فایل امن، پنل دیتابیس و امکان مشاهدهٔ گزارش خصوصی خطا است. لازم نیست همهٔ اعضای تیم رمز پایگاه داده داشته باشند. یک نفر مسئول تغییر تنظیمات و یک نفر مسئول بررسی نتیجه باشد تا تغییر هم‌زمان رمز، میزبان و افزونه‌ها زنجیرهٔ تشخیص را از بین نبرد. اگر فقط به پیشخوان دسترسی دارید و آن هم باز نمیشود، از مسیر بازیابی دسترسی پنل یا مسئول فنی اقدام کنید؛ ساختن فایل آزمایشی عمومی برای دورزدن این محدودیت راه مناسبی نیست.
نسخهٔ پشتیبان مناسب این رخداد صرفاً یک پوشهٔ فایل نیست. باید بدانید آخرین خروجی دیتابیس چه زمانی گرفته شده، کجا نگه‌داری میشود و آیا بازیابی آن در یک محیط جدا ممکن است. اگر سرویس پایگاه داده قطع است، گرفتن خروجی تازه شاید ممکن نباشد؛ این وضعیت را صریح ثبت کنید و از ارائهدهنده دربارهٔ آخرین نسخهٔ سالم بپرسید. کپی‌کردن تصادفی فایل‌های داخلی دیتابیس در حال اجرا را جایگزین پشتیبان سازگار با موتور آن نکنید.
در فروشگاه فعال، بازگرداندن دیتابیس دیروز میتواند سفارشها، تغییر موجودی و وضعیت پرداخت امروز را حذف کند. پیش از هر بازیابی، بازهٔ تراکنشهای جدید را تعیین و مسئول تطبیق پرداخت‌ها را مشخص کنید. محیط آزمایشی باید ایمیل واقعی، درگاه فعال و وب‌هوک خروجی را مهار کند تا بررسی باعث سفارش یا اعلان ناخواسته نشود. برای اصلاح یک نام میزبان نیازی به بازیابی همهٔ اطلاعات نیست؛ حجم اقدام باید با علت اثبات‌شده متناسب بماند.
پیام خطا دقیقاً چه چیزی را ثابت میکند؟
پیام «خطا در برقراری ارتباط با پایگاه داده» نشان میدهد وردپرس نتوانسته مرحلهٔ لازم برای دسترسی به دیتابیس را با موفقیت طی کند، اما از روی همین جمله نمی‌توان میان رمز اشتباه، سرویس متوقف یا مسیر اتصال نامعتبر انتخاب کرد. صفحهٔ سفارشی خطا نیز ممکن است جزئیات اصلی را پنهان کند. نخست متن قابل مشاهده را ثبت کنید و سپس از گزارش خصوصی همان درخواست، نوع شکست را بخواهید؛ به دنبال یک برچسب قطعی از روی ظاهر صفحه نباشید.
پیام Access denied جهت بررسی حساب و مجوز را تقویت میکند، در حالی که Connection refused بیشتر به مقصد و سرویس شنونده مربوط است. خطای سوکت یا نبود فایل سوکت مسیر محلی را مطرح میکند و timeout میتواند ناشی از مسیر شبکه، محدودیت یا پاسخ‌ندادن سرویس باشد. این‌ها جهت تشخیص‌اند، نه مجوز تغییر فوری. ممکن است چند مشکل پشت سر هم وجود داشته باشد: پس از تصحیح میزبان، خطای اعتبارنامه تازه آشکار شود؛ این لزوماً بدترشدن وضعیت نیست.
در راهنمای خطاهای رایج وردپرس اطلاعات اتصال و مشکلات میزبان از مسیرهای بررسی این پیام معرفی شده‌اند. کاربرد این اشاره محدود است: به ما می‌گوید بررسی را در چند لایه انجام دهیم، نه اینکه هر پیام اتصال با ویرایش یک خط حل میشود. اگر به‌جای این پیام، گزارش توقف اجرای PHP دارید، مسیر خطای بحرانی وردپرس مناسب‌تر است؛ اگر پاسخ کلی سرور بدون نشانهٔ مشخص دیتابیس دیده میشود، ابتدا خطای داخلی ۵۰۰ را تفکیک کنید.
دامنهٔ خرابی را بدون ایجاد بار اضافی پیدا کنید
سه مشاهدهٔ کنترل‌شده معمولاً از ده‌ها بار تازه‌سازی مفیدتر است: یک صفحهٔ عمومی شناخته‌شده، صفحهٔ ورود، و یک عملیات خواندنی که به دادهٔ تازه نیاز دارد. وضعیت ورود کاربر، ساعت و شبکهٔ مورد استفاده را ثبت کنید. اگر صفحهٔ اصلی باز میشود ولی جست‌وجو شکست می‌خورد، احتمال دارد صفحهٔ اصلی از کش آمده باشد. برای بررسی، همهٔ کش‌ها را یک‌باره پاک نکنید؛ این کار میتواند درخواست‌های بیشتری را روی دیتابیس ناپایدار بریزد.
در صورت وجود چند دامنه یا زیردامنه، مشخص کنید کدام نصب وردپرس و کدام دیتابیس درگیر است. دو سایت ممکن است روی یک حساب میزبانی باشند ولی کاربران دیتابیس جدا داشته باشند. از طرف دیگر چند نصب ممکن است یک سرویس مشترک داشته باشند و هم‌زمان آسیب ببینند. نتیجهٔ این تفکیک باید یک جملهٔ روشن باشد: «فقط نصب فروشگاه پس از انتقال قطع است» یا «چند نصب مستقل در یک بازه خطا دارند». جملهٔ دوم بررسی سرویس مشترک را جلو می‌اندازد.
آزمون روی موبایل برای این مرحله باید با همان نشانی دقیق انجام شود. صفحهٔ ذخیره‌شدهٔ مرورگر، نسخهٔ آفلاین یا شبکهای که پاسخ دیگری از CDN می‌گیرد، میتواند تصویر متفاوتی بدهد. بازکردن چند پنجرهٔ ناشناس هم‌زمان یا اجرای ابزار فشار ضرورتی ندارد. هدف، تعیین مرز خرابی با کمترین درخواست است. اگر سرویس زیر فشار است، هر مشاهده را با فاصله و هماهنگ با مسئول زیرساخت انجام دهید و زمان آن را برای تطبیق گزارش‌ها نگه دارید.
درخت تصمیم اتصال را مرحله به مرحله دنبال کنید
ابتدا بپرسید آیا سرویس از محیط اجرای PHP قابل دسترسی است. اگر پاسخ منفی است، بررسی رمز را موقتاً کنار بگذارید و مقصد، پورت، سوکت یا محدودیت مسیر را بررسی کنید. دسترسی لپ‌تاپ مدیر یا ابزار پنل به معنی دسترسی پردازش وب نیست. از ارائهدهنده بخواهید مشخص کند آزمون از کدام ماشین، کانتینر یا حساب انجام شده است. این پرسش جلوی نتیجه‌گیری اشتباه از یک تست موفق نامرتبط را می‌گیرد.
اگر مقصد در دسترس است اما ورود کاربر رد میشود، نام کاربر، رمز و مجوز اتصال از میزبان برنامه را بررسی کنید. اگر ورود موفق است ولی پایگاه داده انتخاب نمیشود، نام پایگاه و تخصیص کاربر به آن را تطبیق دهید. اگر پایگاه انتخاب میشود ولی جدولهای وردپرس پیدا نمی‌شوند، نوبت پیشوند و کاملبودن انتقال است. اگر جدولهای مورد انتظار وجود دارند اما گزارش مشخص آسیب یا خطای خواندن دریافت میشود، بررسی سلامت داده را به متخصص بسپارید.
برای خطای متناوب، این درخت را در لحظهٔ شکست اجرا کنید، نه تنها زمانی که سایت دوباره سالم شده است. بازشدن اتصال در ساعت خلوت، سقف اتصال در زمان اجرای کارهای گروهی را رد نمی‌کند. هر شاخه یک خروجی قابل قبول دارد: تأیید مقصد، تأیید هویت، تأیید پایگاه و تأیید جدول. اگر یکی نامعلوم است، همان را نامعلوم بنویسید. عوض‌کردن چند متغیر برای رسیدن تصادفی به صفحهٔ سالم، علت را روشن و تکرار رخداد را قابل پیشگیری نمی‌کند.
فایل فعال تنظیمات را از نسخه‌های مشابه جدا کنید
در انتقال یا استقرار، ممکن است چند فایل با نام مشابه، یک پوشهٔ قدیمی یا نسخهٔ آزمایشی کنار نصب اصلی باقی مانده باشد. قبل از ویرایش، ریشهٔ واقعی دامنه را در پنل تطبیق دهید و مطمئن شوید فایل مورد نظر مربوط به همان نصب است. تغییر نسخهٔ آرشیوی هیچ اثری ندارد و ممکن است شما را به تغییرهای پرخطرتر سوق دهد. فایل پشتیبان را با پسوند قابل دانلود در پوشهٔ عمومی نگه ندارید؛ محتویات آن میتواند دسترسی دیتابیس را افشا کند.
DB_NAME نام پایگاه، DB_USER حساب اتصال، DB_PASSWORD رمز همان حساب و DB_HOST مقصد اتصال است. پیشوندی که پنل به نام‌ها اضافه کرده میتواند بخشی از نام واقعی باشد. حروف، فاصلهٔ اضافی و تفاوت محیط آزمایشی با عملیاتی را بررسی کنید. برای رمز، بازنویسی از روی تصویر یا فرستادن در پیام گروهی مناسب نیست. اگر رمز نامعلوم است، بازنشانی باید برنامه‌ریزی شود، چون برنامهٔ دیگری نیز ممکن است همان حساب را مصرف کند.
برای جزئیات جایگاه تنظیمات می‌توان به مستند رسمی ویرایش wp-config.php مراجعه کرد. اینجا پیشنهاد عملی این است که یک مقدار را با مرجع معتبر همان محیط تطبیق دهید، نسخهٔ قبلی را خصوصی نگه دارید و اثر همان تغییر را بسنجید. فایل تنظیمات محل نمایش تشخیصی نیست؛ افزودن چاپ ثابت‌ها یا خروجی کامل پیکربندی حتی برای چند دقیقه میتواند رمز، کلیدها و مسیرهای داخلی را در اختیار بازدیدکننده قرار دهد.
نام کاربر درست، بدون تخصیص درست کافی نیست
وجود یک حساب دیتابیس در فهرست پنل نشان نمی‌دهد آن حساب به پایگاه مورد نظر دسترسی دارد. در برخی پنل‌ها ساخت پایگاه، ساخت کاربر و اتصال آن دو عملیات جدا هستند. پس از انتقال حساب میزبانی نیز ممکن است نام‌ها عوض شده باشند. از صفحهٔ تخصیص کاربر، ارتباط دقیق را بررسی کنید. اگر سطح مجوز مشخص نیست، مسئول میزبان باید مجوزهای لازم برنامه را روی همان پایگاه تأیید کند؛ دادن دسترسی سراسری به همهٔ پایگاه‌ها راه تشخیص نیست.
اگر ابزار مدیریت دیتابیس با ورود یکپارچهٔ پنل باز میشود، آن ابزار ممکن است از هویتی متفاوت با وردپرس استفاده کند. بنابراین دیدن جدول‌ها در آن فقط وجود داده را نشان میدهد. برای تأیید حساب برنامه، آزمون باید با همان هویت و از مسیر مجاز انجام شود، بدون نوشتن رمز در تاریخچهٔ فرمان یا فایل عمومی. از پشتیبانی بخواهید نتیجه را به صورت «احراز هویت موفق یا ناموفق» و «انتخاب پایگاه موفق یا ناموفق» گزارش کند، نه با ارسال رمز و متن کامل اتصال.
بازنشانی رمز را زمانی انجام دهید که شواهد به همان شاخه اشاره میکند. ابتدا مصرف‌کنندگان حساب را فهرست کنید، زمان تغییر را هماهنگ کنید و راه به‌روزرسانی امن تنظیمات را داشته باشید. در صورت استفادهٔ مشترک چند برنامه، تغییر ناگهانی میتواند دامنهٔ خرابی را بزرگ کند. پس از اصلاح، ذخیرهٔ یک پیشنویس کنترل‌شده را هم بررسی کنید؛ موفقیت خواندن یک صفحه لزوماً توانایی نوشتن مجاز برنامه را ثابت نمی‌کند. آزمایش نوشتن باید محدود و قابل حذف باشد، نه تغییر مستقیم جدول سفارشها.
DB_HOST، پورت و سوکت را حدس نزنید
در میزبانی‌های مختلف مقصد دیتابیس میتواند میزبان محلی، نام سرویس داخلی یا نشانی جداگانه باشد. مقدار متداول یک سرویس دیگر را روی سایت خود کپی نکنید. پس از جابه‌جایی، نام قدیمی ممکن است همچنان حل شود اما به سرویس نادرست برسد. از ارائهدهنده مقدار دقیق مورد نیاز وردپرس و شیوهٔ مشخص‌کردن پورت یا سوکت را بخواهید؛ پاسخ باید مربوط به همان حساب و همان محیط اجرای PHP باشد، نه یک نمونهٔ عمومی راهنما.
در برخی محیط‌ها localhost مسیر سوکت محلی را انتخاب میکند، در حالی که نشانی حلقهٔ محلی عددی اتصال TCP را مطرح میکند. این تفاوت میتواند توضیح دهد چرا یک آزمون کار میکند و دیگری نه، اما دلیل کافی برای جایگزینی کورکورانه نیست. مرجع اتصال MySQLi در PHP پارامترهای میزبان، پورت و سوکت را جدا تعریف میکند. برداشت محدود این است که این اجزا یکسان نیستند؛ تنظیم نهایی باید با پیکربندی واقعی سرویس سازگار باشد.
در محیط کانتینری، «محلی» معمولاً به همان محیط اجرای پردازش اشاره دارد، نه الزاماً ماشین دیتابیس. اگر پس از تغییر معماری مشکل ایجاد شده، نام سرویس و دسترسی شبکهٔ داخلی را مسئول زیرساخت بررسی کند. بازکردن پورت دیتابیس به اینترنت یا حذف محدودیت شبکه برای امتحان، اقدام پذیرفتنی نیست. نتیجهٔ مطلوب، اتصال از مبدأ مورد نیاز و با مسیر مورد تأیید است. اگر اتصال رمزگذاری‌شده الزامی است، اعتبار گواهی و تنظیمات مربوط نیز باید توسط متخصص همان محیط بررسی شود.
پیشوند جدول با اعتبارنامه تفاوت دارد
متغیر table_prefix به وردپرس می‌گوید مجموعهٔ جدولهای نصب را با چه پیشوندی پیدا کند. اشتباه در آن معمولاً مسئلهٔ پیدا نکردن دادهٔ مورد انتظار است، نه نرسیدن به سرویس دیتابیس. به همین دلیل اگر بعد از انتقال صفحهٔ نصب ظاهر شد، نباید فوراً ساخت نصب جدید را ادامه دهید. ابتدا وجود جدول‌ها، نام پایگاه انتخابشده و پیشوند پیکربندی را کنار هم ببینید. نصب مجدد ممکن است مجموعهٔ دیگری بسازد و ابهام را بیشتر کند.
در یک پایگاه ممکن است جدولهای نسخهٔ قدیمی، محیط آزمایشی یا نصب دیگری هم وجود داشته باشد. انتخاب مجموعه فقط بر اساس کوتاه‌ترین نام درست نیست. تاریخ محتوا، شناسهٔ سایت و نشانی‌های ذخیره‌شده را به شکل خواندنی و خصوصی تطبیق دهید. اگر شبکهٔ چندسایتی دارید، ارتباط جدولهای مشترک و جدولهای هر سایت نیاز به بررسی جدا دارد. تغییر پیشوند در فایل بدون درک این ارتباط‌ها میتواند ورود و مجوزهای کاربران را هم تحت تأثیر بگذارد.
روش کم‌خطر این است که ابتدا مشخص شود کدام مجموعه متعلق به نصب مورد نظر است و آیا انتقال همهٔ جدولهای لازم کامل شده است. از اجرای تغییر نام گروهی جدول‌ها یا جست‌وجو و جایگزینی گسترده در دیتابیس برای رفع یک پیام مبهم خودداری کنید. اگر مجموعهٔ درست پیدا شد، اصلاح باید در محیط آزمایشی با ورود و ذخیره‌سازی کنترل شود. اگر چند مجموعهٔ ناقص دارید، گزارش انتقال و خروجی اصلی را بررسی کنید؛ مخلوط‌کردن دستی آنها میتواند یک سایت ظاهراً سالم با دادهٔ ناسازگار بسازد.
سرویس متوقف را از سقف اتصال جدا کنید
قطع کامل سرویس، پاسخ‌ندادن موقت و پرشدن ظرفیت اتصال ظاهر مشابهی برای بازدیدکننده دارند ولی اقدام متفاوت می‌خواهند. از پنل یا مسئول میزبان وضعیت سرویس در بازهٔ خطا، رخداد راه‌اندازی مجدد و محدودیت حساب را بخواهید. پیام «اکنون سرویس فعال است» توضیحی برای رخداد گذشته نیست. زمان شروع و پایان مشاهده‌شده، منطقهٔ زمانی و یک شناسهٔ درخواست در صورت وجود کمک میکند گزارش‌ها روی یک بازه متمرکز شوند.
اگر خطا هم‌زمان با خروجی‌گیری، واردکردن محصول یا اجرای صف رخ میدهد، این هم‌زمانی یک فرضیه است. بررسی کنید آیا کار زمان‌بندی‌شده اتصال‌های زیادی نگه داشته، چند اجرای هم‌پوشان ایجاد شده یا یک درخواست کند ظرفیت را اشغال کرده است. حذف همهٔ صف‌ها یا سفارش‌های معلق برای سبک‌کردن دیتابیس راهحل تشخیصی نیست. روی نسخهٔ آزمایشی، حجم کار محدود و شرایط اجرای همان وظیفه را بازسازی کنید و نتیجه را با توقف یا اصلاح همان عامل مقایسه کنید.
افزایش ظرفیت بدون شناخت مصرف میتواند فقط زمان برگشت خطا را جابه‌جا کند. از متخصص بخواهید ارتباط محدودیت اتصال، درخواست‌های هم‌زمان PHP و کارهای پس‌زمینه را بررسی کند. اگر محدودیت از سیاست حساب ناشی میشود، تصمیم با ارائه‌دهندهٔ میزبانی است؛ وب‌ریزان در این راهنما سرویس زیرساخت نمی‌فروشد. خروجی مورد نیاز شما علت و اقدام مشخص است: مثلاً اصلاح اجرای هم‌پوشان یک کار، نه یک توصیهٔ کلی برای «قوی‌تر کردن» همهٔ اجزا بدون شواهد.
گزارش خصوصی را به شاهد قابل استفاده تبدیل کنید
گزارش مفید باید زمان، نوع خطا و لایهٔ تولیدکننده را حفظ کند و اطلاعات محرمانه را حذف کند. نام کاربر، نام پایگاه، مسیر داخلی و نشانی شبکه ممکن است برای پشتیبانی مجاز لازم باشند، اما نباید در انجمن عمومی یا تصویر منتشرشده دیده شوند. رمز، رشتهٔ کامل اتصال، کوکی و دادهٔ سفارش هیچ جایگاهی در گزارش عمومی ندارند. نسخهٔ کامل را تنها در کانال امن و با دسترسی محدود نگه دارید و نسخهٔ پالایش‌شده را برای هماهنگی تیم استفاده کنید.
اگر ثبت خطا فعال نیست، از میزبان مسیر امن گزارش را بخواهید. فعالکردن نمایش خطا روی صفحه یا ساختن debug.log قابل دانلود زیر ریشهٔ وب میتواند مشکل تازه‌ای بسازد. مدت جمع‌آوری و مسئول خاموش‌کردن تنظیم تشخیصی را پیش از اجرا تعیین کنید. برای خطای متناوب، یک بازهٔ کوتاه با ساعت دقیق بهتر از انباشتن چند روز دادهٔ حساس است. لاگ باید پاسخ یک پرسش مشخص را بدهد: احراز هویت رد شده یا مقصد پاسخ نداده است؟
در گزارش نهایی، واقعیت را از برداشت جدا بنویسید. «در دو درخواست مشخص پیام سقف اتصال ثبت شده» واقعیت است؛ «احتمالاً اجرای هم‌زمان واردکننده باعث آن شده» فرضیه است. برای اثبات فرضیه، زمان اجرای واردکننده و تغییر رفتار پس از اصلاح کنترل‌شده لازم است. این تفکیک باعث میشود مسئول بعدی مجبور نباشد همهٔ بررسی‌ها را از ابتدا تکرار کند و مانع تبدیل حدس یک نفر به دستور قطعی برای تغییر دیتابیس میشود.
خرابی جدول چه زمانی واقعاً مطرح میشود؟
وقتی اتصال و انتخاب پایگاه موفق است اما یک جدول مشخص خطای سلامت، خواندن یا ساختار میدهد، بررسی خرابی داده معنا پیدا میکند. پیام کلی اتصال به‌تنهایی چنین مدرکی نیست. ابتدا نام جدول درگیر، موتور ذخیره‌سازی و نوع گزارش را مسئول دیتابیس بررسی کند. برخی مشکلات از انتقال ناقص، فضای ذخیره‌سازی یا مجوز ناشی می‌شوند و تعمیر جدول پاسخ آنها نیست. تشخیص اشتباه در این مرحله میتواند عملیات سنگین و بی‌فایده روی دادهٔ زنده ایجاد کند.
قابلیت WP_ALLOW_REPAIR یک کلید بی‌خطر برای امتحان عمومی نیست. مسیر wp-admin/maint/repair.php در صورت فعال‌بودن این قابلیت میتواند بدون ورود در دسترس باشد. برای همین، استفاده از آن را به متخصص، پشتیبان قابل بازیابی و محدودیت دسترسی مناسب همان محیط بسپارید. این مقاله عمداً دستور آمادهٔ فعال‌سازی ارائه نمی‌کند. در صورت استفادهٔ ضروری، ثابت باید پس از پایان حذف شود و بستهشدن دسترسی بدون ورود نیز بررسی شود؛ فقط بستن برگهٔ مرورگر کافی نیست.
تعمیر، بهینه‌سازی و بازیابی سه کار متفاوت‌اند. هیچ‌کدام نباید برای پوشاندن خطای رمز یا شبکه اجرا شوند. پیش از مداخلهٔ داده‌ای، زمان توقف نوشتن، اثر احتمالی روی سفارش‌های جدید و معیار مقایسهٔ داده قبل و بعد را تعیین کنید. اگر موتور یا وضعیت جدول اجازهٔ مسیر امن مورد نظر را نمی‌دهد، مسئول دیتابیس باید برنامهٔ جایگزین ارائه کند. حذف جدول مشکل‌دار، نصب دوباره یا جایگزینی همهٔ داده‌ها با یک خروجی قدیمی را پاسخ پیش‌فرض ندانید.
Apache و nginx کجای این خطا قرار می‌گیرند؟
Apache و nginx درخواست وب را دریافت می‌کنند، اما خطای اتصال معمولاً در مسیر اجرای وردپرس و ارتباط PHP با پایگاه داده رخ میدهد. تغییر قواعد پیوند یکتا یا حذف فایل تنظیمات وب‌سرور، رمز دیتابیس را اصلاح نمی‌کند. ابتدا ثابت کنید درخواست به PHP و نصب درست رسیده است. اگر پاسخ از یک صفحهٔ خطای سفارشی یا پروکسی می‌آید، ممکن است متن اصلی و کد وضعیت عوض شده باشد؛ گزارش هر لایه باید با زمان یک درخواست واحد تطبیق داده شود.
در معماری nginx جلوی Apache یا PHP-FPM، مسئول هر گزارش متفاوت است. گزارش دسترسی nginx میتواند کد پاسخ را نشان دهد، در حالی که علت اتصال در گزارش PHP یا سرویس دیتابیس ثبت شده است. به‌جای فرستادن همهٔ فایل‌ها، از پشتیبانی بخواهید مسیر همان درخواست را دنبال کند. اگر بعد از تغییر pool اجرای PHP خطا آغاز شده، تفاوت دسترسی سوکت، متغیرهای محیطی یا پیکربندی آن pool فرضیهٔ مناسب‌تری از دست‌کاری قواعد بازنویسی است.
اگر سایت به‌جای پیام دیتابیس فقط ممنوعیت دسترسی یا پاسخ دروازه میدهد، ابتدا آن لایه را تعیین تکلیف کنید. پاسخ نرسیده به وردپرس، آزمون معتبری برای تنظیمات دیتابیس نیست. از سوی دیگر، نمایش صفحهٔ اتصال با وضعیت غیرمنتظره ممکن است نتیجهٔ مدیریت خطا در لایهٔ جلویی باشد. در پایان اصلاح، هم متن واقعی صفحه و هم کد HTTP را کنترل کنید تا پروکسی یا صفحهٔ نگه‌داری، خرابی باقی‌مانده را پشت یک پاسخ موفق ظاهری پنهان نکند.
سناریوی فرضی انتقال فروشگاه و نام میزبان قدیمی
فرض کنید فروشگاهی پس از انتقال فایل و دیتابیس، بلافاصله پیام اتصال میدهد؛ این یک مثال فرضی است و گزارشی از آزمون واقعی نیست. سه فرضیهٔ رقیب وجود دارد: رمز در انتقال اشتباه شده، مقصد اتصال هنوز متعلق به میزبان قبلی است، یا خروجی دیتابیس ناقص وارد شده است. مسئول بررسی ابتدا بدون ویرایش، ریشهٔ دامنه و فایل فعال تنظیمات را تأیید میکند. سپس مشخصات اتصال را با پنل مقصد تطبیق میدهد و متوجه تفاوت نام میزبان میشود.
این مشاهده هنوز کاملبودن انتقال را اثبات نمی‌کند. اصلاح فقط روی DB_HOST، با نسخهٔ خصوصی فایل قبلی و طبق مقدار تأییدشدهٔ ارائهدهنده انجام میشود. اگر خطا به Access denied تغییر کند، شاخهٔ اعتبارنامه اکنون قابل بررسی است؛ اگر اتصال برقرار و صفحهٔ نصب نمایان شود، باید پیشوند و پایگاه انتخابشده بررسی شود. معیار موفقیت صرفاً ناپدیدشدن پیام اول نیست. ورود مدیر، نمایش محصول شناخته‌شده و ذخیرهٔ پیشنویس باید روی دادهٔ درست موفق باشد.
برای فروشگاه این سناریو، پرداخت‌های رخ‌داده بین آخرین خروجی و تغییر دامنه جدا تطبیق داده می‌شوند. اگر سفارش جدیدی در مبدأ باقی مانده باشد، بازگرداندن کل مقصد به خروجی قدیمی تصمیم مناسبی نیست. نتیجهٔ قابل قبول، اتصال به مقصد صحیح همراه با برنامهٔ روشن برای همگام‌سازی دادهٔ جاافتاده است. اگر شواهد نشان دهد درخواست هنوز به نصب قدیمی می‌رسد، ادامهٔ تغییر دیتابیس متوقف میشود و مسیر دامنه بررسی می‌گردد. همین معیار توقف مانع تعمیر اشتباه یک مجموعهٔ سالم میشود.
سناریوی فرضی قطع متناوب هنگام پردازش سفارشها
در مثال فرضی دوم، صفحات محتوایی اغلب باز می‌شوند اما هنگام اجرای کار گروهی، پیشخوان و تسویه‌حساب گاهی پیام اتصال می‌دهند. فرضیه‌های رقیب عبارت‌اند از قطعی کوتاه سرویس، سقف اتصال و خطای یک جدول سفارش. ابتدا زمان چند شکست واقعی با برنامهٔ کارهای پس‌زمینه تطبیق داده میشود. اگر گزارش خصوصی در همان لحظه محدودیت اتصال را نشان دهد، فرضیهٔ خرابی جدول ضعیف‌تر میشود؛ نبود خطای جدول به‌تنهایی سلامت کامل داده را تضمین نمی‌کند.
بررسی بعدی روی نسخهٔ آزمایشی با صف محدود و ارتباطات خروجی مهارشده انجام میشود. مسئول فنی بررسی میکند آیا دو اجرای واردکننده روی هم افتاده‌اند و آیا کاهش همپوشانی، رفتار اتصال را تغییر میدهد. اینجا حذف صف یا افزایش نامحدود ظرفیت معیار نیست. باید همان نوع کار با پایان قابل مشاهده و بدون خطای اتصال انجام شود. اگر در زمان توقف کار گروهی نیز خطا ادامه یابد، فرضیهٔ مشترک سرویس یا مسیر شبکه دوباره در اولویت قرار می‌گیرد.
در محیط اصلی، اصلاح محدود با امکان برگشت اجرا میشود و سفارش‌های درگیر از نظر ثبت، پرداخت و موجودی تطبیق می‌یابند. کاربرانی که صفحهٔ خطا دیده‌اند نباید بدون بررسی به پرداخت دوباره تشویق شوند؛ وضعیت تراکنش ممکن است بیرون از وردپرس تغییر کرده باشد. نتیجهٔ این مثال زمانی پذیرفتنی است که هم صف به روال عادی برگردد و هم سفارش ناقص باقی نماند. اگر فقط صفحهٔ اصلی سریع‌تر شده باشد، مسئلهٔ اصلی هنوز حل‌شده محسوب نمیشود.
موبایل، سبد خرید و دادهٔ تازه را جدا کنترل کنید
کاربر موبایل ممکن است صفحهٔ محصول کش‌شده را ببیند اما افزودن به سبد یا تغییر نشانی نیازمند ارتباط تازه باشد. بنابراین گزارش «روی گوشی باز میشود» برای بستن رخداد کافی نیست. روی یک گوشی و یک مرورگر دسکتاپ، مسیر کوتاه و مشخصی را با دادهٔ آزمایشی دنبال کنید: بازکردن محصول، افزودن کنترل‌شده به سبد و رسیدن به مرحلهٔ قبل از پرداخت. اطلاعات شخصی واقعی را وارد سناریوی آزمایش نکنید و وضعیت کش هر مشاهده را ثبت کنید.
در ووکامرس، ثبت سفارش، کاهش موجودی، یادداشت پرداخت و پردازش پس‌زمینه ممکن است در زمان‌های متفاوت انجام شوند. اگر ارتباط در میانهٔ مسیر قطع شده، از روی یک صفحهٔ موفق یا ناموفق دربارهٔ وضعیت مالی تصمیم نگیرید. شناسهٔ سفارش و تراکنش را در کانال امن تطبیق دهید و مسئول رسیدگی به سفارش‌های مبهم را تعیین کنید. اجرای مجدد گروهی همهٔ کارهای ناموفق بدون شناخت اثر تکرار میتواند اعلان، پردازش یا تغییر وضعیت تکراری بسازد.
اگر اصلاح اتصال نیاز به پنجرهٔ کوتاه توقف دارد، پیام مناسب و روش جلوگیری از نوشتن تازه را با مسئول فروشگاه هماهنگ کنید. کش‌کردن صفحات حساب و سبد برای پوشاندن خطا راه بازیابی نیست. بعد از رفع علت، یک تغییر کنترل‌شدهٔ داده و مشاهدهٔ آن در درخواست بعدی کمک میکند مطمئن شوید سایت از پایگاه درست می‌خواند و به همان پایگاه می‌نویسد. برای تحلیل بار پس از تثبیت دسترسی، مسیر بررسی سرعت سایت میتواند مرحلهٔ بعد باشد، نه جایگزین رفع قطعی اتصال.
کد HTTP و canonical را پس از بازیابی بررسی کنید
نام خطای دیتابیس کد HTTP را به‌تنهایی تعیین نمی‌کند. پاسخ واقعی صفحهٔ عمومی را در ابزار شبکهٔ مرورگر ببینید و بررسی کنید صفحهٔ خطا با وضعیت موفق ارائه نشده باشد. برای توقف موقت برنامه‌ریزی‌شده، مسئول فنی باید پاسخ مناسب و رفتار کش را تعیین کند. هدایت همهٔ نشانی‌ها به خانه یا تغییر canonical به یک صفحهٔ سالم، مشکل اتصال را حل نمی‌کند و میتواند تشخیص وضعیت هر نشانی را دشوارتر کند.
طبق توضیح رسمی گوگل دربارهٔ وضعیت‌های HTTP، خطاهای پایدار سرور میتوانند بر خزش و نگه‌داری نشانی‌ها در نمایه اثر بگذارند؛ پاسخ موفق نیز تضمین نمایه‌شدن نیست. نتیجهٔ عملی این است که بعد از رفع اتصال، چند نشانی مهم را با محتوای واقعی و وضعیت پاسخ صحیح بررسی کنید. این راهنما وعدهٔ بازگشت رتبه یا زمان مشخص برای بازیابی دیده‌شدن نمی‌دهد؛ رفتار موتور جست‌وجو را باید از گزارش‌های خود سایت پیگیری کرد.
اگر انتقال هم‌زمان با رخداد بوده، canonical، دامنهٔ اصلی و نشانی‌های داخلی را پس از تثبیت داده کنترل کنید. وجود دامنهٔ محیط آزمایشی در خروجی میتواند نشانهٔ انتخاب مجموعهٔ اشتباه باشد، اما قبل از هر جایگزینی گسترده باید منشأ آن روشن شود. ابتدا یک صفحهٔ شناخته‌شده و تنظیمات مربوط را به صورت خواندنی بررسی کنید. اصلاح سراسری نشانی‌ها حین قطعی، دو مسئلهٔ مستقل را مخلوط میکند و برگشت امن به وضعیت قبل را دشوارتر می‌سازد.
معیار پذیرش، برگشت و تحویل فنی
فهرست پذیرش باید خواندن محتوای تازه، ورود کاربر مجاز، ذخیرهٔ پیشنویس، اجرای محدود کار پس‌زمینه و مسیر اصلی فروشگاه را پوشش دهد. هر مورد را با زمان و نتیجه ثبت کنید. اگر خطا دوره‌ای بوده، یک مشاهدهٔ موفق کافی نیست؛ باید در بازه یا شرایطی که قبلاً شکست رخ می‌داد نیز بررسی انجام شود. برای این کار فشار مصنوعی روی سایت زنده ایجاد نکنید. همان وظیفهٔ واقعی را در پنجرهٔ هماهنگ و با مشاهدهٔ گزارش خصوصی پیگیری کنید.
برگشت تنظیمات با برگشت داده تفاوت دارد. اگر اصلاح میزبان نتیجه نداده، بازگرداندن نسخهٔ قبلی فایل ممکن است کافی باشد؛ اگر در فاصلهٔ تغییر، دادهٔ تازه نوشته شده، بازگرداندن کل پایگاه تصمیم دیگری است و نیاز به تطبیق دارد. پیش از هر اقدام، شرط توقف را بنویسید: افزایش خطا، مشاهدهٔ دادهٔ اشتباه یا اختلال تازه در سفارش. با رسیدن به آن شرط، آزمایش را ادامه ندهید و علت را دوباره از شاخهٔ اثبات‌شده بررسی کنید.
برای تحویل، یک گزارش کوتاه شامل زمان رخداد، محیط درگیر، آخرین تغییر، نوع خطای پالایش‌شده، نتیجهٔ هر شاخه و تغییر اعمال‌شده تهیه کنید. فایل تنظیمات کامل یا خروجی دیتابیس را ضمیمهٔ عمومی نکنید. اگر به همراهی برای تفکیک مشکل برنامه نیاز دارید، پشتیبانی وردپرس مسیر مرتبط است؛ مسائل وضعیت سرویس و محدودیت حساب باید با ارائه‌دهندهٔ میزبانی شما نیز هماهنگ شود. گزارش خوب مشخص میکند چه چیزی هنوز اثبات نشده و مسئول قدم بعدی کیست.
استقرار چند نسخه‌ای و اتصال به دادهٔ اشتباه
گاهی خطا پس از استقرار فقط در بخشی از درخواست‌ها دیده میشود، چون همهٔ نمونه‌های برنامه از یک تنظیم استفاده نمی‌کنند. یک پردازش ممکن است تنظیم قدیمی یا متغیر محیطی متفاوت داشته باشد و نمونهٔ دیگر سالم باشد. در این وضعیت، تغییر دوبارهٔ رمز روی تنها نسخه‌ای که در دسترس شماست تشخیص را سخت‌تر میکند. از مسئول استقرار بخواهید نمونه‌های فعال، محل دریافت تنظیم و زمان اعمال آن را مشخص کند. اطلاعات محرمانه نباید برای مقایسه در خروجی عمومی چاپ شوند؛ تأیید تطابق میتواند در محیط خصوصی انجام شود.
اگر وردپرس به پایگاه دیگری وصل شده باشد، ممکن است خطا اصلاً دیده نشود اما نوشته‌ها یا سفارشها قدیمی باشند. این حالت خطرناک‌تر از یک پیام واضح است، چون بازدیدکننده میتواند روی مجموعهٔ اشتباه دادهٔ تازه بسازد. معیار تشخیص را از قبل تعیین کنید: وجود یک نوشتهٔ شناخته‌شده، تاریخ آخرین تغییر و تطبیق شناسهٔ یک سفارش مجاز. برای این کار از اطلاعات شخصی مشتری در تصویر استفاده نکنید. اگر اختلاف دیده شد، نوشتن تازه را با هماهنگی متوقف و مسیر اتصال را پیش از هر ادغام بررسی کنید.
در سامانه‌ای که لایهٔ اختصاصی اتصال یا فایل جایگزین مدیریت دیتابیس دارد، فرض اتصال سادهٔ یک نصب عادی ممکن است کافی نباشد. مسئول فنی باید بداند آیا تنظیمات اضافی از فایل دیگر، متغیر محیطی یا ابزار استقرار وارد میشود. پاک‌کردن اجزای ناشناخته برای برگشت به حالت «پیش‌فرض» میتواند ارتباط برنامه را بیشتر مختل کند. ابتدا معماری موجود را ثبت کنید و اصلاح را در همان چارچوب انجام دهید؛ اگر مستندات داخلی وجود ندارد، این کمبود باید به عنوان یک کار پیشگیری مستقل ثبت شود.
پیام پشتیبانی را حول یک پرسش مشخص بنویسید
در درخواست پشتیبانی ننویسید فقط «دیتابیس خراب است». توضیح دهید از چه زمانی، روی کدام نصب و در کدام عملیات خطا رخ داده و آیا تغییری قبل از آن انجام شده است. سپس یک پرسش قابل پاسخ مطرح کنید: آیا اتصال از محیط اجرای وب در آن بازه رد شده، یا سرویس در دسترس نبوده است؟ این شکل گزارش به ارائهدهنده اجازه میدهد شواهد مناسب را پیدا کند و مانع پیشنهاد تعمیر داده پیش از اثبات مشکل جدول میشود. شناسهٔ حساب را فقط در کانال رسمی ارائه کنید.
پاسخ پشتیبانی را نیز به معیار بعدی تبدیل کنید. اگر سرویس سالم اعلام شد، بپرسید سلامت مربوط به زمان اکنون است یا بازهٔ رخداد و آیا آزمون با هویت برنامه انجام شده است. اگر محدودیت حساب مطرح شد، نوع محدودیت و زمان ثبت آن را بخواهید؛ نیازی به دریافت اطلاعات سایر مشتریان یا تنظیمات محرمانهٔ زیرساخت نیست. اگر احراز هویت رد شده، نام حساب و تخصیص پایگاه را از پنل خود بررسی کنید. با این روش، مکاتبه به جمع‌کردن حدس‌ها تبدیل نمیشود و هر پاسخ، شاخهٔ بعدی را روشن میکند.
پایان‌دادن به تنظیمات موقت تشخیص
پس از تأیید بازیابی، فهرست تغییرهای موقت را جدا از اصلاح اصلی مرور کنید. حساب موقت بررسی، ثبت جزئیات اضافه، دسترسی متخصص و هر نسخهٔ خصوصی انتقال‌یافته باید سرنوشت مشخص داشته باشند. حذف شواهد لازم برای تحلیل آینده درست نیست، اما نگه‌داری نامحدود خروجی کامل داده نیز ضرورتی ندارد. گزارش پالایش‌شده را نگه دارید و فایل‌های حاوی اطلاعات حساس را طبق روش نگه‌داری سایت محدود یا حذف کنید. مسئول هر مورد و زمان پایان آن باید معلوم باشد تا جمع‌کردن ابزارها از قلم نیفتد.
اگر در جریان بررسی رمز عوض شده، تأیید کنید همهٔ مصرف‌کنندگان مجاز با مقدار جدید کار می‌کنند و نسخهٔ قدیمی در فایل عمومی یا کانال مکاتبه باقی نمانده است. اگر به دلیل توقف سرویس کارهای زمان‌بندی‌شده عقب افتاده‌اند، برگشت آنها را کنترل‌شده انجام دهید؛ شروع هم‌زمان همهٔ کارهای عقب‌مانده ممکن است همان فشار قبلی را بازسازی کند. نتیجهٔ این مرحله باید یک وضعیت عملیاتی روشن باشد: اتصال پایدار است، کارهای ضروری ادامه یافته‌اند و هیچ ابزار موقتی بدون مسئول باقی نمانده است. این بررسی با تعمیر تازه یا تغییر ساختار داده تفاوت دارد و نباید بهانهٔ مداخلهٔ بیشتر شود.
پیشگیری را به علت اثبات‌شده وصل کنید
برای خطای ناشی از انتقال، چک‌لیست استقرار باید مقصد دیتابیس، نام کاربر، تخصیص مجوز و پیشوند را به طور مستقل کنترل کند. برای خطای ناشی از چرخش رمز، فهرست مصرف‌کنندگان حساب و روش به‌روزرسانی امن لازم است. برای سقف اتصال، برنامهٔ اجرای کارها و جلوگیری از همپوشانی اهمیت دارد. یک توصیهٔ عمومی برای نصب افزونهٔ بیشتر، جای این اقدامات متناسب با علت را نمی‌گیرد و ممکن است خود بار تازه‌ای به برنامه اضافه کند.
پشتیبان‌ها باید به صورت دوره‌ای در محیط جدا بازیابی و از نظر محتوای مورد انتظار بررسی شوند. دسترسی به فایل تنظیمات، خروجی‌ها و گزارش‌ها محدود بماند و نسخه‌های موقت پس از پایان بررسی جمع شوند. اگر رخداد از جابه‌جایی یا راه‌اندازی عجولانه آمده، مرور اشتباهات راه‌اندازی سایت کمک میکند کنترل‌های قبل از انتشار را منظم کنید. معیار پایان کار، یک صفحهٔ سبز نیست؛ ارتباط پایدار، دادهٔ درست و امکان برگشت قابل توضیح است.