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

خطای MySQL server has gone away؛ چرا ارتباط پایگاه داده قطع می‌شود؟

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

انتشار:
توسط تیم فنی نت‌آرام
۳ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله خطای MySQL server has gone away؛ چرا ارتباط پایگاه داده قطع می‌شود؟ در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
عملیات سایت یا وارد کردن یک فایل دیتابیس شروع می‌شود و ناگهان پیام MySQL server has gone away دیده می‌شود. معنی ساده پیام این است که ارتباط برنامه با سرور پایگاه داده از بین رفته است. علت می‌تواند پایان زمان انتظار، درخواست بزرگ، قطع شبکه یا توقف خود سرویس باشد.

چه زمانی پیام رخ می‌دهد؟

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

آیا خود سرویس قطع شده است؟

اگر دسترسی مدیریت دارید، وضعیت سرویس را در ابزار مدیریت همان سرور و گزارش خطای پایگاه داده در زمان حادثه ببینید. نام سرویس ممکن است mysql، mysqld یا mariadb باشد. اگر سرویس پس از خطا دوباره شروع شده، علت راه‌اندازی مجدد را از گزارش پیدا کنید. ری‌استارت مکرر بدون خواندن خطا ممکن است شواهد را از بین ببرد.

اندازه و زمان انتظار را بخوانید

در یک نشست MySQL با مجوز مشاهده، این دو فرمان فقط مقدار فعلی را نشان می‌دهند:
کد / دستورSHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'max_allowed_packet';
عدد wait_timeout مربوط به برخی اتصال‌های غیرفعال است و max_allowed_packet سقف بسته را نشان می‌دهد. این دو را صرفاً چون در اینترنت توصیه شده زیاد نکنید. در خطای فایل بزرگ، اندازه درخواست و محدودیت سمت برنامه و سرور را با هم مقایسه کنید. گاهی وارد کردن داده در بخش‌های مناسب یا اصلاح برنامه راه بهتری است.
برای نمونه، اگر wait_timeout مقدار 28800 را نشان دهد، این مقدار برای نشست مورد بررسی به ثانیه است؛ یعنی حدود هشت ساعت. اگر برنامه پس از بیکاری طولانی می‌خواهد از همان اتصال قدیمی استفاده کند، توسعه‌دهنده باید شیوه بازکردن اتصال تازه یا مدیریت اتصال را در همان برنامه بررسی کند. اگر خطا فقط هنگام وارد کردن یک ردیف حجیم رخ می‌دهد، اندازه آن ردیف و محدودیت سمت ابزار واردکننده را با مقدار سمت سرور مقایسه کنید. این دو سناریو راه‌حل یکسان ندارند و اعداد نشست آزمایشی لزوماً تنظیم همان اتصال برنامه را نشان نمی‌دهند.

قبل از تکرار عملیات نوشتن

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

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

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