پیام database error همیشه به معنی خراب شدن جدول نیست. credential اشتباه، تمام شدن disk، down بودن MySQL، timeout یا محدودیت connection نتیجه مشابه می‌سازند. Repair فقط برای خرابی قابل اثبات table مناسب است و روی همه engineها و انواع آسیب نتیجه یکسان ندارد.
پاسخ سریع: ابتدا backup فیزیکی یا logical قابل بازیابی بگیرید، فضای دیسک و سلامت MySQL را بررسی کنید، نام جدول و متن دقیق خطا را از log پیدا کنید و سپس ابزار repair متناسب با engine را در پنجره نگهداری اجرا کنید. هیچ جدول production را بدون backup drop یا truncate نکنید.
نشانه خرابی واقعی چیست؟
- پیام‌هایی مانند table marked as crashed
- خطای خواندن index یا corruption در log دیتابیس
- شکست CHECK TABLE برای جدول مشخص
- بازیابی ناقص پس از crash یا مشکل storage
عبارت «Error establishing a database connection» به‌تنهایی corruption را ثابت نمی‌کند. ابتدا راهنمای خطای اتصال دیتابیس را بررسی کنید.
قبل از تعمیر
- نوشتن‌های سایت را متوقف یا maintenance window تعیین کنید.
- از دیتابیس و فایل‌ها backup بگیرید و اندازه فایل را کنترل کنید.
- فضای disk، inode و سلامت storage را بررسی کنید.
- engine و جدول آسیب‌دیده را مشخص کنید.
- RPO و راه rollback را ثبت کنید.
اگر فروشگاه فعال است، restore قدیمی می‌تواند سفارش و پرداخت جدید را از بین ببرد. زمان backup و داده‌های پس از آن باید روشن باشد.
ابزار داخلی وردپرس
وردپرس صفحه repair دارد که با تعریف موقت زیر فعال می‌شود:
define( 'WP_ALLOW_REPAIR', true );صفحه repair احراز هویت معمول مدیریت را لازم ندارد؛ بنابراین ثابت را فقط در بازه کوتاه فعال و بلافاصله حذف کنید. URL را عمومی نکنید. این ابزار همه انواع خرابی یا engineها را درمان نمی‌کند.
WP-CLI
wp db check
wp db repairابتدا check را اجرا کنید. repair عملیات تغییر‌دهنده است و باید با backup، root صحیح سایت و کاربر مجاز انجام شود. خروجی ابزار MySQL را بخوانید؛ موفقیت فرمان به معنی رفع علت storage نیست.
InnoDB و MyISAM یکسان نیستند
REPAIR TABLE عمدتاً برای engineهایی مانند MyISAM کاربرد دارد و راه عمومی تعمیر InnoDB نیست. برای InnoDB باید log سرور، crash recovery، backup و راهنمای نسخه دقیق MySQL/MariaDB بررسی شود. فعال کردن force recovery و export در سطح سرور کار پیشرفته و پرریسک است و نباید به‌عنوان دستور کپی‌کردنی ارائه شود.
بعد از repair
جدول را دوباره check کنید، log MySQL و PHP را بخوانید و login، ذخیره نوشته، cron و checkout را آزمایش کنید. اگر corruption برمی‌گردد، RAM، disk، filesystem، خاموشی ناگهانی و نسخه دیتابیس باید بررسی شوند. تعمیر علامت بدون رفع علت قابل اتکا نیست.
اگر سایت هنوز بالا نمی‌آید چه کنیم؟
نتیجه موفق repair فقط سلامت ساختار قابل بررسی جدول را گزارش می‌کند. ممکن است اتصال، privilege، prefix، فایل تنظیمات یا داده application همچنان ایراد داشته باشد. نام دیتابیس، user و host را با محیط جاری تطبیق دهید، اما رمز را در خروجی فرمان یا تیکت منتشر نکنید. سپس اولین خطای تازه را از log بخوانید؛ پیام قدیمی cacheشده مبنای مناسبی برای تغییر بعدی نیست.
اگر سایت خوانده می‌شود ولی نوشتن شکست می‌خورد، فضای آزاد، read-only شدن filesystem، privilege کاربر و وضعیت replica را بررسی کنید. اگر فقط یک قابلیت مانند جستجو یا سفارش مشکل دارد، جدول‌های مرتبط و query خطادار را پیدا کنید و همه دیتابیس را بی‌هدف دستکاری نکنید.
Backup مناسب این حادثه چیست؟
یک dump تازه حتی از دیتابیس معیوب می‌تواند برای بازیابی رکوردهای سالم ارزش داشته باشد، ولی نباید تنها نسخه قابل اتکا را با آن جایگزین کرد. نسخه سالم قبلی را immutable نگه دارید، checksum و امکان خواندن فایل را بررسی کنید و زمان هر نسخه را ثبت کنید. برای سایت تراکنشی، اختلاف میان آخرین backup سالم و لحظه حادثه باید جداگانه مدیریت شود.
صرف دیدن فایل dump به معنی قابل restore بودن نیست. restore باید روی محیط جدا، با نسخه سازگار دیتابیس، آزمایش شود. این آزمون نباید روی دیتابیس production یا با نام مبهمی انجام شود که خطر اتصال اشتباه برنامه را بالا ببرد.
تشخیص خرابی زیرساختی
corruption تکرارشونده را یک مشکل WordPress فرض نکنید. پیام‌های I/O، reset شدن میزبان، کمبود فضای volume، خطای filesystem و shutdown اجباری می‌توانند علت اصلی باشند. وضعیت سرویس و kernel log را در همان بازه زمانی بررسی کنید و قبل از reboot شتاب‌زده شواهد لازم را نگه دارید.
روی سرویس مدیریت‌شده، repair سطح فایل یا تغییر پارامترهای recovery را خودسرانه اجرا نکنید؛ محدودیت‌ها و رویه provider را دنبال کنید. روی سرور خودمدیریت نیز کپی مستقیم فایل‌های data directory میان نسخه‌ها روش مهاجرت عمومی و امنی نیست.
چک‌لیست بازگشت سرویس
- تأیید check جدول‌های آسیب‌دیده و مرور log تازه
- آزمون read و write با داده غیرحساس
- آزمون ورود، cron، جستجو و عملیات اصلی کسب‌وکار
- کنترل سفارش‌های ایجادشده در بازه حادثه
- فعال‌سازی دوباره ترافیک و مانیتورینگ تدریجی
- ثبت علت، تغییرات و اقدام پیشگیرانه
اشتباه‌های خطرناک
- اجرای SQL ناشناخته یا حذف جدول خراب
- restore دیتابیس قدیمی فروشگاه بدون ادغام داده تازه
- فعال ماندن WP_ALLOW_REPAIR
- نسبت دادن هر connection error به corruption
- بهینه‌سازی همه جدول‌ها هنگام کمبود disk
چه زمانی متخصص لازم است؟
اگر InnoDB بالا نمی‌آید، چند جدول آسیب دیده یا storage error وجود دارد، تغییر بیشتر ممکن است شانس بازیابی را کم کند. سرویس رفع مشکل فنی وردپرس می‌تواند دیتابیس، backup و لایه سیستم را هماهنگ بررسی کند.
پرسش‌های متداول
آیا repair داده حذف می‌کند؟
بسته به نوع خرابی و engine احتمال از دست رفتن رکورد وجود دارد؛ backup قبل از اقدام ضروری است.
آیا optimize همان repair است؟
خیر. هدف و رفتار متفاوت‌اند و optimize درمان عمومی corruption نیست.
چرا خرابی دوباره رخ می‌دهد؟
مشکل disk، crash، کمبود فضا یا shutdown نامناسب ممکن است هنوز باقی باشد.