حفظ داده پیش از اقدام
از پوشه داده دیتابیس، فایل های MDF و LDF یا ibdata و لاگ های خطا نسخه می گیریم. روی دیتابیسی که احتمال خرابی دارد، بدون نسخه پشتیبان هیچ دستور تعمیری اجرا نمی کنیم.
خدمات فوری
رفع خطای دیتابیس و مشکلات سرور (MySQL، SQL Server، لینوکس، ویندوز)
وقتی MySQL بعد از قطع برق بالا نمی آید، SQL Server اتصال ها را رد می کند یا دیسک سرور پر شده و برنامه ها یکی یکی متوقف شده اند، رفع خطای دیتابیس منتظر نمی ماند. ما پیش از هر عیب یابی از فایل های دیتابیس و لاگ ها نسخه می گیریم، چون اولویت با حفاظت از داده است. وقتی سرویس برگشت، اگر لازم باشد بهینه سازی دیتابیس را هم پیشنهاد می کنیم تا همین مشکل دوباره پیش نیاید.
ابزارها و فناوری ها
database-os-troubleshooting
- MySQL
- MariaDB
- SQL Server
- PostgreSQL
- Percona Toolkit
- SQL Server Management Studio
- systemd
- Event Viewer
- Ubuntu
- Windows Server
5بخش کار
4خروجی
4مرحله
رفع خطای دیتابیس چیست؟
رفع خطای دیتابیس و سرور خدمتی فوری برای دیتابیس از کار افتاده، کند یا قفل شده و مشکلات سیستم عامل لینوکس و ویندوز است که در آن حفاظت از داده ها بر هر اقدامی مقدم است. نمونه اش MySQL است که بعد از قطع برق بالا نمی آید، نرم افزار حسابداری که به SQL Server وصل نمی شود یا دیسک سروری که پر شده است. قبل از هر اقدامی، پیکوسیستم از پوشه داده، فایل های MDF و LDF یا ibdata و لاگ های خطا نسخه می گیرد. بعد خطاهای InnoDB و حالت Suspect در SQL Server را عیب یابی می کند، سراغ کوئری های طولانی، deadlockها و تنظیماتی مثل innodb_buffer_pool_size می رود و فضایی را که binary log یا transaction log گرفته اند به صورت امن آزاد می کند. تحویلی شما سرویسی است که دوباره کار می کند، به همراه گزارش علت، فهرست تغییرات کانفیگ و پیشنهاد بهینه سازی.
چه زمانی به رفع خطای دیتابیس نیاز دارید؟
- MySQL بعد از ری استارت سرور بالا نمی آید و در لاگ خطای InnoDB می بینم.
- نرم افزار حسابداری پیغام می دهد به SQL Server وصل نمی شود.
- دیسک سرور پر شده و نمی دانم چه چیزی را می شود پاک کرد.
- سرور هر چند ساعت یک بار به خاطر کمبود رم پروسه ها را می بندد.
رفع خطای دیتابیس شامل چه کارهایی است؟
خطای راه اندازی و crash
خطاهای InnoDB، جدول های crashed در MyISAM، حالت Suspect یا Recovery Pending در SQL Server و ناسازگاری های بعد از آپدیت را عیب یابی می کنیم.
کندی و قفل شدن
کوئری های طولانی، deadlockها، ایندکس های ناقص و تنظیماتی مثل innodb_buffer_pool_size یا max server memory را یکی یکی نگاه می کنیم.
پر شدن دیسک
فایل های بزرگ مثل binary log، transaction log، لاگ هایی که چرخش ندارند و فایل های موقت را پیدا می کنیم و فضا را به صورت امن آزاد می کنیم.
مشکلات سیستم عامل
کمبود رم و OOM Killer، خطای بوت، سرویس های systemd از کار افتاده و خطاهای Event Viewer در ویندوز سرور هم جزو این کار است.
بعد از رفع خطای دیتابیس چه چیزی تحویل می گیرید؟
- سرویس دیتابیس یا سرور برگشته به حالت کاری
- گزارش علت مشکل و اقدام های انجام شده
- فهرست تغییرات کانفیگ با مقدار قبلی و جدید
- پیشنهاد برای بهینه سازی و جلوگیری از تکرار
راهنمای رفع خطای دیتابیس
بهینه سازی MySQL: کدام تنظیمات واقعاً اثر دارند؟
بعد از innodb_buffer_pool_size، مقدار max_connections بیشترین اشتباه را دارد. هر اتصال بافرهای خودش مثل sort_buffer_size و join_buffer_size را می گیرد، پس عدد بزرگ همراه با بافرهای بزرگ در ساعت پربار رم را تمام می کند و OOM Killer سرویس MySQL را می بندد. اندازه redo log، که در نسخه های جدید با innodb_redo_log_capacity تنظیم می شود، هم روی سرعت نوشتن اثر مستقیم دارد.
از کپی کردن فایل my.cnf آموزش های قدیمی پرهیز کنید. Query Cache در MySQL 8.0 حذف شده و وجود query_cache_size در کانفیگ باعث می شود سرویس اصلاً اجرا نشود. تغییرات را یکی یکی اعمال کنید و اثر هر کدام را با pt-query-digest و slow query log بسنجید.
افزایش سرعت SQL Server: تنظیمات پیش فرضی که باید عوض شوند
مقدار پیش فرض max server memory عملاً نامحدود است و SQL Server تا جایی که بتواند رم می گیرد. روی سروری که سرویس های دیگر هم دارد، این یعنی کمبود حافظه برای سیستم عامل و کندی کل سرور. مقدار cost threshold for parallelism هم به طور پیش فرض 5 است که برای بیشتر بارهای کاری جدید پایین است و کوئری های کوچک را بی دلیل موازی اجرا می کند.
خطای رایج دیگر، فعال بودن Auto Shrink یا اجرای Shrink زمان بندی شده است که فایل ها را کوچک و ایندکس ها را پراکنده می کند و دیتابیس دوباره مجبور به رشد می شود. به روز نبودن Statistics و نگهداری نشدن ایندکس ها هم از علت های رایج کندی تدریجی اند.
کرش شدن سیستم یا دیتابیس: علت را در کدام لاگ پیدا کنیم؟
در لینوکس، دستور journalctl -b -1 لاگ بوت قبلی را نشان می دهد و برای ری استارت های ناگهانی اولین جای بررسی است. عبارت Out of memory: Killed process در خروجی dmesg یعنی کرنل پروسه ای را به خاطر کمبود رم بسته است. لاگ خطای MySQL معمولاً در /var/log/mysql یا /var/lib/mysql قرار دارد.
در ویندوز سرور، رویداد Kernel-Power با شناسه 41 و رویداد 6008 خاموش شدن غیرعادی را ثبت می کنند و رویداد 1001 نشان می دهد صفحه آبی رخ داده و فایل Minidump ساخته شده است. SQL Server هم لاگ خودش را در فایل ERRORLOG داخل پوشه Log محل نصب نگه می دارد.
high availability در SQL Server و MySQL: کی لازم است؟
وقتی توقف چند ساعته دیتابیس مستقیماً فروش یا تولید را متوقف می کند، بازیابی از بکاپ دیگر به تنهایی کافی نیست. در SQL Server گزینه ها Always On Availability Groups، Failover Cluster Instance و Log Shipping هستند. نسخه Standard فقط Basic Availability Group را با یک دیتابیس در هر گروه پشتیبانی می کند. در MySQL و MariaDB، Replication و Galera Cluster رایج اند.
High Availability جای بکاپ را نمی گیرد، چون دستور DROP یا حذف اشتباه داده در چند ثانیه روی همه نسخه ها تکرار می شود.
مراحل رفع خطای دیتابیس
-
01
تماس و شرح خطا
پیغام خطا، زمان شروع مشکل و تغییرات اخیر را می گویید. اگر اسکرین شات یا لاگ دارید، برایمان بفرستید.
-
02
دسترسی و نسخه برداری
از طریق دسترسی ریموت امن وارد می شویم و پیش از هر تغییری از داده ها و لاگ ها نسخه می گیریم.
-
03
عیب یابی و رفع
علت را پیدا و رفع می کنیم. اقدام هایی که احتمال از دست رفتن داده دارند، فقط با تأیید شما انجام می شوند.
-
04
تست و گزارش
اتصال برنامه ها و سلامت داده را همراه شما تست می کنیم و بعد گزارش به دستتان می رسد.
سؤالات متداول درباره رفع خطای دیتابیس
رفع فوری مشکل با بهینه سازی دیتابیس چه فرقی دارد؟
رفع فوری سرویس را در لحظه بحران برمی گرداند. بهینه سازی دیتابیس کاری برنامه ریزی شده است که تحلیل کوئری ها، ایندکس گذاری و تنظیم کانفیگ بر اساس بار واقعی را در بر می گیرد. بعد از رفع مشکل، معمولاً بهینه سازی را هم پیشنهاد می کنیم تا بحران تکرار نشود.
دیتابیس MySQL ما کرش کرده. داده ها از دست رفته اند؟
کرش شدن MySQL لزوماً به معنای از دست رفتن داده نیست. InnoDB در بسیاری از موارد با recovery خودکار یا با حالت innodb_force_recovery دوباره بالا می آید. کار اشتباه در این مرحله، مثل پاک کردن فایل های ib_logfile، می تواند آسیب را جدی کند، پس تا بررسی ما سرویس را پشت سر هم ری استارت نکنید.
بدون دسترسی ریموت هم می توانید کمک کنید؟
برای بیشتر مشکلات دیتابیس و سیستم عامل دسترسی ریموت امن لازم است. اگر سیاست شرکت اجازه دسترسی از بیرون نمی دهد، کار از طریق جلسه اشتراک صفحه با همکار شما یا حضور در محل هماهنگ می شود.
جست وجوهای مرتبط
- بهینه سازی MySQL
- افزایش سرعت SQL Server
- بازیابی دیتابیس SQL
- high availability SQL Server
- ابزار مانیتورینگ SQL Server
- کرش شدن سیستم
خدمات مرتبط
فوری
گزارش مشکل فوری
برای قطعی کامل، تماس تلفنی سریع ترین راه است. اگر نمی توانید تماس بگیرید، فرم را پر کنید تا با شما تماس بگیریم.
همین حالا تماس بگیرید 09981213905- 01تماس و گرفتن شرح مشکل.
- 02مهار آسیب و حفظ لاگ ها پیش از هر تغییری.
- 03رفع مشکل و گزارش علت و کارهای انجام شده.