وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

خطای اتصال Redis در وردپرس؛ چطور سایت را برگردانیم و علت را پیدا کنیم؟

روش بازگرداندن موقت وردپرس و تشخیص Redis خاموش، آدرس یا رمز اشتباه، خطای دیسک و فعال‌سازی دوباره کش را بخوانید.

انتشار:
توسط تیم فنی نت‌آرام
۷ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله خطای اتصال Redis در وردپرس؛ چطور سایت را برگردانیم و علت را پیدا کنیم؟ در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
به‌جای سایت یا پیشخوان وردپرس پیام Error establishing a Redis connection می‌بینید. Redis در بعضی سایت‌ها برای نگه‌داشتن داده‌های موقتِ کش استفاده می‌شود. این خطا یعنی بخش اتصال سایت نتوانسته ارتباط مورد انتظار را برقرار کند یا Redis برای عملیات درخواست‌شده خطایی برگردانده است. ممکن است سرویس خاموش باشد، آدرس یا دسترسی تغییر کرده باشد یا خود Redis به دلیل مشکل دیگری پاسخ مناسب ندهد.
پیش از شروع، بدانید Redis همیشه فقط یک کش ساده نیست؛ ممکن است برنامه‌های دیگر از همان سرویس برای نشست، صف یا داده‌های مهم استفاده کنند. بنابراین پاک‌کردن همه داده‌های Redis، حذف پوشه‌ها یا خاموش‌کردن بررسی‌های امنیتی راه تشخیص امن نیست. ابتدا متن کامل خطا و کاربرد واقعی Redis را مشخص کنید.

قدم اول: متن خطا و زمان آن را ثبت کنید

زمان و نشانی صفحه‌ای را که خطا داده یادداشت کنید. اگر بعد از انتقال سایت، تغییر رمز، راه‌اندازی مجدد سرور یا نصب افزونه اتفاق افتاده، آن تغییر را نیز ثبت کنید. بخش جزئی‌تر پیام ممکن است یکی از این نشانه‌ها را داشته باشد:
  • Connection refused: در آدرس یا پورت انتخاب‌شده، اتصال رد شده است؛ سرویس، مسیر و محل اجرای سایت را بررسی کنید.
  • NOAUTH یا خطای احراز هویت: ارتباطی به سرویس رسیده، اما دسترسی موردنیاز داده نشده است؛ نام کاربر یا رمز را با تنظیمات معتبر مقایسه کنید.
  • MISCONF: ممکن است Redis برای نوشتن نسخه پایدار روی دیسک مشکل داشته باشد؛ متن کامل و گزارش سرویس تعیین می‌کند علت چیست.
  • خطای مربوط به socket: مسیر فایل سوکت یا دسترسی کاربر برنامه به آن می‌تواند مسئله باشد.
این‌ها سرنخ‌اند، نه تشخیص قطعی. از نمایش یا ارسال رمز Redis، اطلاعات wp-config.php و متن کامل گزارش دارای مشخصات خصوصی خودداری کنید.

اگر پیشخوان بالا نمی‌آید، راه بازگشت موقت چیست؟

ابتدا از فایل‌های سایت و تنظیمات مهم نسخه پشتیبان بگیرید. از پنل هاست، File Manager را باز کنید و به پوشه نصب وردپرس، سپس wp-content بروید. وردپرس برای کش شیء سفارشی می‌تواند از فایل ویژه‌ای به نام object-cache.php در همین پوشه استفاده کند. توضیح فنی وردپرس وجود این فایل را بخشی از سازوکار drop-in می‌داند.
اگر مطمئن هستید این فایل متعلق به اتصال Redis سایت شماست و مدیر سایت استفاده از آن را تأیید کرده، یک کپی امن بگیرید و برای آزمون موقت نام فایل را مثلاً به object-cache.php.disabled تغییر دهید. آن را حذف نکنید. سپس سایت و پیشخوان را دوباره باز کنید. در بسیاری از پیکربندی‌ها با بارگذاری‌نشدن drop-in، وردپرس از کش داخلی غیرپایدار خودش استفاده می‌کند و صفحه خطای Redis کنار می‌رود.
اگر سایت پس از تغییر نام بالا آمد، این نتیجه نشان می‌دهد مشکل احتمالاً به همان مسیر کش مرتبط است؛ هنوز علت خرابی Redis را ثابت نمی‌کند. سرعت سایت یا رفتار افزونه‌های وابسته ممکن است تغییر کند، پس این وضعیت را راه‌حل نهایی ندانید. اگر فایل متعلق به سامانه دیگری است، سایت چندبخشی یا پیکربندی خاص دارید، یا از تأثیر آن مطمئن نیستید، بدون هماهنگی آن را تغییر ندهید. اگر بعد از آزمون مشکلی تازه ایجاد شد، با هماهنگی مدیر سایت نام قبلی را برگردانید.

قدم دوم: محل واقعی Redis را پیدا کنید

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

قدم سوم: وضعیت سرویس و اتصال را آزمایش کنید

اگر مدیر سرور لینوکسی هستید و Redis روی همان سرور با systemd اجرا می‌شود، نام واحد واقعی را از تنظیمات سیستم پیدا کنید. در بسیاری از نصب‌های اوبونتو ممکن است نام آن redis-server باشد، ولی در سیستم‌های دیگر متفاوت است. برای نمونه:
کد / دستورsudo systemctl status redis-server --no-pager -l
اگر واحد پیدا نشد، اول نام سرویس واقعی را مشخص کنید؛ نتیجه به معنی نبود Redis در همه معماری‌ها نیست. اگر سرویس failed است، گزارش همان واحد و زمان خطا را ببینید:
کد / دستورsudo journalctl -u redis-server -n 100 --no-pager
اگر redis-cli در دسترس است و اتصال واقعاً به Redis محلی روی پورت پیش‌فرض انجام می‌شود، این آزمون را اجرا کنید:
کد / دستورredis-cli ping
پاسخ PONG نشان می‌دهد همان مشتری در همان مسیر توانسته از Redis پاسخ بگیرد. پیام NOAUTH می‌تواند نشان دهد سرویس قابل دسترس است اما به احراز هویت نیاز دارد. Connection refused یعنی اتصال به نشانی و پورت استفاده‌شده رد شده است. هر سه نتیجه مربوط به همان محل آزمون هستند؛ اگر وردپرس از سوکت، کانتینر یا میزبان دیگری استفاده می‌کند، باید همان مسیر را جدا بررسی کنید. راهنمای رسمی Redis درباره PING رفتار این آزمون را توضیح می‌دهد.
رمز را با گزینه‌ای که داخل خط فرمان و تاریخچه دیده شود وارد نکنید. برای آزمونِ احراز هویت، از روش امن مستند سرویس خود یا مدیر آن استفاده کنید. پور‌ت Redis را برای اینترنت عمومی باز نکنید و Protected Mode یا احراز هویت را صرفاً برای ردکردن خطا خاموش نکنید؛ راهنمای امنیت Redis درباره محدودسازی دسترسی توضیح می‌دهد.

اگر خطا MISCONF یا مشکل فضای ذخیره‌سازی است

گزارش Redis را بخوانید تا دلیل واقعی مشکل ذخیره‌سازی مشخص شود. در سروری که به آن دسترسی دارید، این دو فرمان وضعیت کلی فضا و تعداد inode فایل‌سیستم‌ها را نشان می‌دهند:
کد / دستورdf -h df -i
اگر فایل‌سیستمی که Redis واقعاً داده‌های پایدارش را روی آن می‌نویسد پر است، علت مصرف فضا را پیدا و با برنامه نگهداری همان سرور اصلاح کنید. اگر گزارش از دسترسی مسیر یا خطای دیسک می‌گوید، همان مورد را بررسی کنید. خروجی این فرمان‌ها به‌تنهایی مشخص نمی‌کند کدام فایل باید حذف شود.
پایداری Redis ممکن است برای برنامه‌های دیگری هم لازم باشد. خاموش‌کردن قابلیت ذخیره‌سازی، حذف فایل داده یا اجرای FLUSHALL بدون شناخت مصرف‌کنندگان می‌تواند داده مهم را از بین ببرد. ابتدا کاربرد سرویس، نسخه پشتیبان و روش اصلاح مناسب را با مدیر آن مشخص کنید.

فعال‌سازی دوباره و کنترل نتیجه

پس از رفع علت، وضعیت واقعی Redis و مسیر اتصال وردپرس را دوباره بررسی کنید. اگر فایل drop-in را موقتاً تغییر نام داده‌اید، از روش توصیه‌شده افزونه برای فعال‌سازی دوباره استفاده کنید یا با هماهنگی مدیر سایت نام فایل سالم را به حالت قبلی برگردانید. اگر افزونه فایل را خودش بازسازی می‌کند، وجود فایل قدیمی یا جدید را بررسی کنید تا دو تنظیم متناقض نماند.
سایت، ورود مدیر و یک صفحه مهم را آزمایش کنید. اگر فروشگاه است، با حساب آزمایشی سبد و پرداخت آزمایشی را نیز ببینید. در صفحه وضعیت افزونه کش، وضعیت اتصال را بررسی کنید و گزارش خطای تازه را در چند نوبت بخوانید. دیدن یک PONG یا فعال‌بودن systemd به‌تنهایی ثابت نمی‌کند همه قابلیت‌های وردپرس و سایر مصرف‌کنندگان Redis سالم هستند.
اگر سایت فقط با خاموش‌بودن کش بالا می‌آید، نتیجه را همراه زمان خطا و نوع اتصال به مدیر سرویس بدهید؛ رمز و اطلاعات مشتری را حذف کنید. برای بررسی گزینه‌های میزبانی، صفحه هاست وردپرس نت‌آرام در دسترس است؛ راه رفع خطا به تنظیم و محل Redis همان سایت بستگی دارد.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام