محتوای آموزشی وبلاگ نت‌آرام
هنگام ثبت سفارش یا ویرایش داده، خطای Lock wait timeout exceeded با کد
1205 ظاهر می‌شود. تصور کنید دو نفر می‌خواهند هم‌زمان یک برگه را تغییر دهند؛ نفر دوم باید منتظر بماند تا نفر اول کارش را تمام کند. اگر انتظار از حد مجاز بیشتر شود، دیتابیس این خطا را می‌دهد.راه‌حل همیشه زیادکردن زمان انتظار یا قطع همه اتصال‌ها نیست. باید ببینیم چه کاری منتظر مانده و چه تراکنشی راه آن را بسته است. در فروشگاه، پیش از تکرار عملیات مالی، وضعیت سفارش و پرداخت را نیز جداگانه بررسی کنید تا کار دوباره ثبت نشود.
۱۲۰۵ با بن‌بست چه تفاوتی دارد؟
در انتظار قفل، یک عملیات منتظر آزادشدن داده‌ای است که عملیات دیگری در اختیار دارد و فرصت انتظار تمام می‌شود. در deadlock، دو یا چند تراکنش ممکن است به شکلی منتظر هم باشند که پیشرفت ممکن نباشد؛ موتور دیتابیس معمولاً یکی را برای شکستن چرخه برمی‌گرداند. پیام و کد دقیق را بخوانید؛ راه بررسی و رفتار بازگشت یکسان نیست.
در تنظیم معمول InnoDB، خطای انتظار قفل اغلب فقط همان دستور منتظر را برمی‌گرداند، نه الزاماً همه تغییرات قبلی تراکنش را. اگر گزینه خاصی برای بازگردانی کل تراکنش فعال باشد، رفتار متفاوت است. مستند MySQL درباره خطاهای InnoDB این تفاوت را توضیح می‌دهد. بنابراین «خطا دیدم، پس هیچ تغییری ذخیره نشده» فرض امنی نیست.
قدم اول: اثر واقعی خطا را مشخص کنید
زمان خطا، نام برنامه، نوع عملیات و شماره سفارش یا شناسه امن درخواست را ثبت کنید. در فروشگاه، وضعیت سفارش را در پیشخوان و نتیجه تراکنش را در پنل درگاه مقایسه کنید. اگر پرداخت موفق شده، دوباره دکمه پرداخت یا ثبت را پشت سر هم نزنید. نتیجه بانک، یادداشت سفارش و عملیات دیتابیس ممکن است هم‌زمان یکسان نشده باشند.
اگر خطا فقط زمان ورود دسته‌ای محصولات یا اجرای گزارش سنگین دیده می‌شود، آن کار را مشخص کنید. اگر تقریباً همه بخش‌ها کند هستند، ممکن است چند عامل از جمله صف و منابع سرور هم دخیل باشند. از روی یک پیام درباره علت نهایی قضاوت نکنید.
قدم دوم: تراکنش‌های منتظر را در زمان بروز مشکل ببینید
این بخش نیاز به حساب مدیریتی با مجوز مناسب دارد. در هاست اشتراکی ممکن است فقط میزبان بتواند اطلاعات همه اتصال‌ها را ببیند. در MySQL نسخه‌ای که جدول‌های مربوط را ارائه می‌دهد، مدیر می‌تواند در یک نشست SQL فقط‌خواندنی این دستور را اجرا کند:
کد / دستورSELECT * FROM performance_schema.data_lock_waits;
این پرسش قفل‌ها را تغییر نمی‌دهد؛ ردیف‌ها رابطه تراکنش درخواست‌کننده و مسدودکننده را در لحظه نمونه‌گیری نشان می‌دهند. ستون‌های
REQUESTING_ENGINE_TRANSACTION_ID و BLOCKING_ENGINE_TRANSACTION_ID به شناسایی دو طرف کمک می‌کنند. خروجی خالی، مخصوصاً بعد از پایان انتظار، ثابت نمی‌کند قبلاً قفلی وجود نداشته است. ممکن است مجوز یا امکانات لازم هم در دسترس نباشد.مدیر می‌تواند آن اطلاعات را با
performance_schema.data_locks و فهرست تراکنش‌ها تطبیق دهد تا جدول، نوع قفل، مدت و برنامه مرتبط را بشناسد. ساختار ابزارهای نظارت در MySQL و MariaDB و نسخه‌های مختلف متفاوت است؛ از دستور مناسب همان نسخه استفاده کنید. راهنمای رسمی MySQL رابطه این جدول‌ها را شرح می‌دهد.گزارش ممکن است نام جدول، شناسه کاربر یا پرس‌وجوهای حساس داشته باشد. آن را در دسترس عمومی قرار ندهید. اگر مجوز کافی ندارید، این محدودیت را دور نزنید؛ زمان و شناسه خطا را به مدیر پایگاه داده بدهید تا همان لحظه نمونه‌گیری کند.
قدم سوم: علت نگه‌داشتن قفل را برطرف کنید
تراکنش طولانی یا بازمانده: اگر یک برنامه تراکنش را شروع کرده و پایان نداده، مالک برنامه باید علت را پیدا کند و در مسیر درست
COMMIT یا ROLLBACK انجام دهد. دستور بازگشت فقط در همان نشست و با شناخت اثر آن معنا دارد؛ اجرای آن در نشست دیگر تراکنش مسدودکننده را حل نمی‌کند.کار دسته‌ای بزرگ: ورود یا اصلاح تعداد زیاد ردیف ممکن است قفل را طولانی نگه دارد. در محیط آزمایشی کار را در دسته‌های کوچک‌تر و با ثبت نتیجه هر دسته طراحی کنید. اگر عملیات میان دسته‌ها وابستگی دارد، ترتیب و سازگاری داده باید قبل از اجرا بررسی شود.
پرس‌وجوی کند یا فاقد شاخص مناسب: مدیر برنامه می‌تواند طرح اجرای پرس‌وجو و شاخص‌ها را با نسخه آزمایشی و داده مشابه بررسی کند. افزودن شاخص بدون سنجش ممکن است نوشتن داده را کند کند و فضای زیادی بگیرد؛ پیش و پس از تغییر زمان، قفل و بار را مقایسه کنید.
اتصال رهاشده: اگر تراکنش مربوط به یک برنامه مشخص است، با مالک آن هماهنگ کنید. قطع اتصال می‌تواند کار انجام‌نشده را برگرداند و زمان بازیابی داشته باشد. انتخاب تصادفی یک شناسه در فهرست پردازش‌ها یا راه‌اندازی مجدد کل MySQL ممکن است به کاربران دیگر آسیب بزند.
آیا زمان انتظار را زیاد کنیم؟
افزایش
innodb_lock_wait_timeout می‌تواند در بعضی کارهای طولانی زمان بیشتری برای آزادشدن قفل بدهد، اما قفل معیوب را رفع نمی‌کند و ممکن است کاربران بیشتر منتظر بمانند. این تنظیم برای نوع خاصی از انتظار قفل InnoDB کاربرد دارد و برای هر نوع قفل یکسان نیست. فقط مدیر، پس از اندازه‌گیری و با برنامه بازگشت، باید درباره تغییر آن تصمیم بگیرد.اگر برنامه پس از خطا نیاز به تلاش مجدد دارد، توسعه‌دهنده باید وضعیت کل تراکنش را بشناسد، در صورت مناسب بودن آن را امن برگرداند و تنها عملیات قابل تکرار یا دارای شناسه یکتا را دوباره اجرا کند. برای پرداخت و ارسال پیام، تکرار بدون بررسی نتیجه قبلی می‌تواند اثر واقعی دوباره ایجاد کند.
از کجا بفهمیم مشکل برطرف شده است؟
سناریوی مشکل را ابتدا با داده آزمایشی و بار کنترل‌شده تکرار کنید. سپس در زمان واقعی، تعداد خطاهای ۱۲۰۵، مدت انتظار و صحت نتیجه عملیات را مقایسه کنید. برای سفارش، هم وضعیت فروشگاه و هم تراکنش درگاه را ببینید. خالی‌شدن یک نمونه فهرست قفل‌ها به‌تنهایی کافی نیست.
در هاست پربازدید و ووکامرس، زمان دقیق خطا، شماره سفارش و گزارش بدون اطلاعات محرمانه به مدیر سرویس کمک می‌کند قفل را به کار مربوط وصل کند. افزایش منابع هاست ممکن است در برخی فشارها مفید باشد، ولی تراکنش باز یا پرس‌وجوی اشتباه را خودبه‌خود اصلاح نمی‌کند.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام