خطای Error establishing a database connection
سرویس MySQL متوقف شده (اغلب بهدست OOM Killer)، wp-config تغییر کرده، سقف اتصالها پر شده یا جدولی آسیب دیده است.
پشتیبانی اضطراری · عیبیابی دیتابیس و سیستمعامل
بهینه سازی دیتابیس سرور و عیب یابی فوری دیتابیس و سیستم عامل
بهینهسازی دیتابیس سرور برای کوئری کند، قفل جدول، خطای اتصال به دیتابیس، دیسک پر یا load ناگهانی سرور است. تیم کانفیگ سرور علت را در MySQL، MariaDB، PostgreSQL یا SQL Server و در لینوکس یا Windows Server پیدا میکند، پیش از هر تغییر پرریسک از داده نسخه پشتیبان میگیرد و اصلاحات را مرحلهبهمرحله انجام میدهد.
MySQL · MariaDB · PostgreSQL
SQL Server
Linux · Windows Server
WordPress · WooCommerce
تا رسیدن کارشناس این کارها را انجام ندهید
- فایلهای ib_logfile یا پوشه #innodb_redo را پاک نکنید. برای کامل کردن تراکنشهای نیمهتمام پس از کرش لازماند و حذفشان داده را ناسازگار میکند.
- innodb_force_recovery را روی ۴ یا بیشتر نگذارید. طبق مستندات MySQL ممکن است فایلهای داده را برای همیشه خراب کند؛ این کار فقط روی کپی داده انجام شود.
- سرویس را پشتسرهم ریاستارت یا با kill -9 متوقف نکنید. بازیابی پس از کرش را طولانیتر و پرریسکتر میکند.
- برای خالی کردن دیسک، binlog، پوشه pg_wal یا لاگهای باز را دستی پاک نکنید. Replication و بازیابی خراب میشود و فایل باز با rm فضایی آزاد نمیکند.
- fsck را روی پارتیشن mountشده اجرا نکنید. خرابی فایلسیستم را گستردهتر میکند؛ این کار از حالت rescue انجام میشود.
- در SQL Server گزینه REPAIR_ALLOW_DATA_LOSS یا Shrink را اجرا نکنید. اولی ممکن است داده حذف کند و دومی معمولاً لاگ تراکنش پرشده را درمان نمیکند.
- در ساعت اوج، OPTIMIZE TABLE یا «بهینهسازی» افزونهها را روی جدولهای بزرگ اجرا نکنید. فضای دیسک اضافه میخواهد و بار سنگینی روی دیسک میگذارد.
چه زمانی به این خدمت نیاز دارید؟
نشانههایی که میگویند دیتابیس یا سیستمعامل گلوگاه سرور شماست
کوئریها کند شدهاند و CPU دیتابیس پر است
معمولاً چند کوئری بدون ایندکس بیشتر زمان را میگیرند؛ slow query log و EXPLAIN نشان میدهند کدام کوئری و به چه دلیل.
جدولها قفل میشوند یا deadlock رخ میدهد
پیام Waiting for table metadata lock در MySQL یا گزارش deadlock در SQL Server یعنی تراکنشها منتظر یکدیگرند و ترتیب دسترسی و ایندکسها باید بازبینی شوند.
دیسک پر شده، رم تمام میشود یا سرویس بالا نمیآید
خطای No space left on device، OOM Killer یا سرویسی که پس از بهروزرسانی failed میماند، مشکل سیستمعامل است و اغلب اول دیتابیس را از کار میاندازد.
بهینهسازی دیتابیس
در بهینهسازی دیتابیس سرور چه کارهایی انجام میدهیم؟
کوئریهای پرهزینه را پیدا میکنیم، ایندکسها را اصلاح میکنیم و پیکربندی موتور را با بار واقعی هماهنگ میکنیم. اگر دیتابیس خراب شده باشد، اول داده امن میشود.
بهینهسازی MySQL و MariaDB
تنظیم InnoDB متناسب با رم و بار واقعی سرور.
- تحلیل slow query log با pt-query-digest
- تنظیم innodb_buffer_pool_size، max_connections و redo log
- استفاده از MySQLTuner فقط بهعنوان نقطه شروع
بهینهسازی کوئریها و ایندکسگذاری
بیشترین بهبود معمولاً از چند کوئری پرتکرار میآید.
- خواندن طرح اجرا با EXPLAIN و EXPLAIN ANALYZE
- ایندکسگذاری در دیتابیس بر اساس کوئریهای واقعی
- پیشنهاد بازنویسی کوئری با مقایسه قبل و بعد
بهینهسازی PostgreSQL
کندی اغلب از bloat جدولها و autovacuum تنظیمنشده است.
- تحلیل کوئریها با pg_stat_statements و تنظیم autovacuum، shared_buffers و work_mem
- راهاندازی PgBouncer برای اتصالهای زیاد
بهینهسازی دیتابیس SQL Server
برای نرمافزارهای حسابداری، ERP و سامانههای سازمانی.
- یافتن کوئریهای پرهزینه با Query Store و DMVها
- تحلیل blocking و deadlock graph از system_health
- تنظیم max server memory، MAXDOP و tempdb
بهینهسازی دیتابیس وردپرس و ووکامرس
افزونه بهینهسازی دیتابیس وردپرس فقط بخشی از کار را انجام میدهد.
- کاهش دادههای autoload در wp_options
- بررسی جدولهای حجیم wp_postmeta و Action Scheduler
- راهاندازی کش آبجکت Redis
تعمیر دیتابیس و رفع کرش
وقتی سرویس اجرا نمیشود، اول داده حفظ میشود و بعد سراغ سرعت میرویم.
- تشخیص علت کرش از error log: دیسک، رم یا جدول آسیبدیده
- innodb_force_recovery کنترلشده روی کپی داده و گرفتن dump سالم
- تعمیر دیتابیس وردپرس
- تعمیر جدولهای MyISAM
راهنمای کامل
راهنمای بهینهسازی دیتابیس سرور: کوئری، ایندکس، حافظه و بازیابی پس از کرش
بهینهسازی دیتابیس سرور معمولاً با پیدا کردن چند کوئری پرهزینه شروع میشود. روی بیشتر سایتها و نرمافزارهای سازمانی، بخش بزرگی از بار دیتابیس از تعداد کمی کوئری پرتکرار میآید و بیشترین بهبود هم از اصلاح همانها به دست میآید. تنظیمات حافظه در مرحله بعد میآیند. اگر سرویس کرش کرده باشد ترتیب کار عوض میشود و حفظ داده جلوتر از هر کار دیگری است.
پیدا کردن کوئریهای پرهزینه پیش از تغییر تنظیمات
در MySQL و MariaDB، slow query log را با long_query_time مناسب روشن کنید و خروجی را با pt-query-digest خلاصه کنید. این ابزار کوئریهای مشابه را گروه میکند و نشان میدهد کدام گروه بیشترین زمان کل را گرفته است؛ کوئریای که هر بار کوتاه است ولی هزاران بار اجرا میشود، گاهی از یک کوئری کند تکی مهمتر است. در PostgreSQL همین کار را pg_stat_statements و در SQL Server، Query Store و DMVها انجام میدهند.
بعد از پیدا کردن کوئری، طرح اجرای آن را با EXPLAIN بخوانید. اگر نوع دسترسی ALL است یا تعداد ردیفهای بررسیشده به کل جدول نزدیک است، دیتابیس برای پیدا کردن چند ردیف همه جدول را میخواند. EXPLAIN ANALYZE زمان واقعی هر مرحله را هم نشان میدهد، اما خود کوئری را اجرا میکند؛ روی UPDATE یا DELETE در دیتابیس اصلی از آن استفاده نکنید.
ایندکسگذاری درست و خطاهای رایج
ایندکس را برای کوئریهایی بسازید که واقعاً اجرا میشوند. در ایندکس چندستونی ترتیب ستونها مهم است و ایندکسی که با ستون a شروع شده، به کوئریای که فقط روی ستون b فیلتر میکند کمکی نمیکند. شرط LIKE با علامت % در ابتدای عبارت، یا اعمال تابع روی ستون در WHERE، هم معمولاً جلوی استفاده از ایندکس را میگیرد.
هر ایندکس نوشتن را کندتر میکند و فضا میگیرد، پس ساختن ایندکس روی همه ستونها راهحل نیست و ایندکسهای تکراری یا بیاستفاده باید حذف شوند. OPTIMIZE TABLE یا دکمه «بهینهسازی» افزونههای وردپرس جای ایندکس درست را نمیگیرد و روی جدول بزرگ در ساعت اوج، دیسک را درگیر میکند. در وردپرس و ووکامرس، حجم دادههای autoload در wp_options و اندازه جدول wp_postmeta اغلب اثر بیشتری دارند.
تقسیم حافظه بین دیتابیس، PHP و سیستمعامل
innodb_buffer_pool_size تعیین میکند چه مقدار از داده و ایندکسهای InnoDB در رم بماند. روی سروری که فقط دیتابیس اجرا میکند میتوان بخش بزرگی از رم را به آن داد، اما روی سرور مشترک با وبسرور و PHP-FPM باید سهم هر کدام را جدا حساب کرد. max_connections را هم بیحساب بالا نبرید، چون هر اتصال بافرهای خودش را دارد و در اوج ترافیک مجموع مصرف رم از حد میگذرد و OOM Killer دیتابیس را میبندد.
در PostgreSQL، shared_buffers حافظه اشتراکی را تعیین میکند و work_mem برای هر عملیات مرتبسازی یا hash در هر کوئری جداگانه مصرف میشود؛ مقدار بزرگ work_mem همراه اتصالهای زیاد رم را تمام میکند و PgBouncer تعداد اتصالهای واقعی را پایین نگه میدارد. در SQL Server اگر max server memory تنظیم نشود، سرویس تا جایی که بتواند رم میگیرد و خود Windows Server کند میشود. اگر کندی مزمن است و فوری نیست، گزارش رایگان عملکرد سرور گلوگاه را در همه لایهها بررسی میکند.
وقتی دیتابیس کرش کرده: ترتیب کار امن
پیش از هر تلاش برای راهاندازی دوباره، از پوشه داده کپی بگیرید؛ وقتی سرویس متوقف است، این کپی سادهترین نسخه پشتیبان است. بعد error log دیتابیس و لاگ سیستمعامل را بخوانید تا معلوم شود علت دیسک پر، کمبود رم یا جدول آسیبدیده است. اگر دیسک با binlog پر شده، فضا را با PURGE BINARY LOGS از داخل دیتابیس آزاد کنید، چون حذف دستی فایلهای binlog، Replication و بازیابی را خراب میکند.
اگر InnoDB بالا نمیآید، innodb_force_recovery را از مقدار کم و فقط روی کپی داده امتحان کنید، از داده dump سالم بگیرید و آن را در نمونه تازه بازگردانید. طبق مستندات MySQL، مقدار ۴ یا بیشتر ممکن است فایلهای داده را برای همیشه خراب کند. اگر دیسک آسیب فیزیکی دیده یا داده حذف شده، کار از بهینهسازی گذشته و به بازیابی اطلاعات سرور نیاز دارید.
زمان و هزینه بهینهسازی دیتابیس به چه بستگی دارد؟
موتور دیتابیس، حجم داده و تعداد کوئریهای پرهزینه پایه برآورد هستند. کرش و خرابی داده کار را طولانیتر میکند، چون پیش از هر اصلاح باید نسخه پشتیبان گرفته و سالم بودن داده بررسی شود. اگر کوئریهای کند از کد برنامه میآیند، پیشنهاد بازنویسی را تحویل میدهیم و اجرای آن با تیم توسعه است.
برای برآورد، موتور و نسخه دیتابیس، سیستمعامل، پیام خطا، زمان شروع مشکل و نوع دسترسی موجود را بفرستید. بررسی اولیه رایگان است و برآورد کار پیش از شروع اعلام میشود. برای پایش دائمی و هشدار پیش از کرش بعدی، خدمات مانیتورینگ را ببینید.
رمز دیتابیس یا root را در پیام اولیه نفرستید. روش امن دسترسی پس از بررسی اولیه هماهنگ میشود.
سیستمعامل سرور
عیبیابی و بهینهسازی سیستمعامل: لینوکس و Windows Server
در عیبیابی سرور لینوکس و Windows Server، منابع، سرویسها و لاگها را همزمان با دیتابیس بررسی میکنیم. اگر کندی مزمن است و فوری نیست، گزارش رایگان عملکرد سرور را درخواست کنید.
پر شدن دیسک و اتمام inode
No space left on device گاهی یعنی inodeها تمام شده یا فایل حذفشدهای هنوز باز است.
- یافتن مصرفکننده فضا با du، df -i و lsof +L1
- تنظیم logrotate و حجم journald
- پاکسازی امن binlog با PURGE BINARY LOGS
مصرف رم بالا و OOM Killer
با تمام شدن رم، کرنل لینوکس فرایندی را میبندد و آن فرایند اغلب دیتابیس است.
- تشخیص رویداد OOM از dmesg و journalctl
- تقسیم رم بین دیتابیس، PHP-FPM و کش
- تنظیم oom_score_adj و MemoryMax در systemd
load بالا، دیسک کند و iowait
load بالا بدون مصرف CPU یعنی فرایندها منتظر دیسکاند.
- بررسی iowait با iostat و iotop
- یافتن کرونجاب یا بکاپ پرمصرف در ساعت اوج
- بررسی steal time در سرور مجازی
سرویسهای failed و kernel panic
علت سرویسی که بالا نمیآید معمولاً در لاگ نوشته شده است.
- تحلیل systemctl –failed و journalctl و بررسی kernel panic و بوت ناموفق از کنسول
- بازگرداندن کرنل یا بسته مشکلساز
کندی و خطاهای Windows Server
بهینهسازی ویندوز سرور اغلب از رمی شروع میشود که SQL Server بیسقف اشغال کرده است.
- تحلیل Event Viewer و Performance Monitor
- تعیین سقف رم SQL Server
- آزادسازی درایو سیستم و بررسی سرویسهای متوقف
فرآیند اجرای کار
چهار مرحله عیبیابی فوری دیتابیس و سیستمعامل
تثبیت و حفظ داده
پیش از هر اقدام پرریسک از پوشه داده یا dump نسخه پشتیبان میگیریم و سرویس را با کمترین ریسک برمیگردانیم.
پیدا کردن علت ریشهای
لاگ دیتابیس، slow query log و قفلها، و در سیستمعامل dmesg، journalctl یا Event Viewer را بررسی میکنیم.
اصلاح مرحلهای
تغییرات یکییکی و ترجیحاً در ساعت کمترافیک اعمال میشوند و اثر هر کدام اندازهگیری میشود.
گزارش و پیشگیری
گزارش علت، تغییرات و مقایسه قبل و بعد را همراه با پیشنهاد پایش و بکاپ تحویل میگیرید.
محدوده خدمت عیبیابی دیتابیس و سیستمعامل
شامل این خدمت
- عیبیابی کندی، قفل، deadlock و خطای اتصال به دیتابیس
- پیکربندی MySQL، MariaDB، PostgreSQL و SQL Server
- تحلیل کوئریهای کند و ایندکسگذاری
- بهینهسازی دیتابیس وردپرس و ووکامرس
- رفع پر شدن دیسک، اتمام inode، OOM و سرویسهای failed
- عیبیابی کندی Windows Server
- راهاندازی دیتابیس پس از کرش و گزارش مکتوب
خارج از این خدمت
- ریکاوری دیتابیس از دیسک آسیبدیده یا داده حذفشده در بازیابی اطلاعات سرور
- سرور آلوده به بدافزار در رفع هک و مالور
- پایش دائمی و هشدار در خدمات مانیتورینگ
- بازنویسی کد برنامه؛ فقط پیشنهاد اصلاح ارائه میشود
- تعویض قطعات سختافزاری خراب
چرا کانفیگ سرور؟
بهینهسازی دیتابیس سرور با نسخه پشتیبان پیش از هر تغییر پرریسک
تجربه عملی روی لینوکس با cPanel یا DirectAdmin، وردپرس و ووکامرس، و SQL Server روی Windows Server.
01
دیتابیس و سیستمعامل با هم
هر دو لایه را یک تیم بررسی میکند، چون مشکل سیستمعامل اغلب اول دیتابیس را از کار میاندازد.
02
نسخه پشتیبان پیش از تعمیر
هیچ تعمیر پرریسکی بدون نسخه پشتیبان و مسیر بازگشت انجام نمیشود.
03
گزارش علت ریشهای
گزارش نهایی میگوید مشکل از کجا آمد و چه کاری جلوی تکرارش را میگیرد.
04
بررسی اولیه رایگان
پیش از هر تعهدی، مسیر عیبیابی را با شما مرور میکنیم.
سوالات متداول
پرسشهای رایج درباره بهینهسازی دیتابیس و عیبیابی سرور
بهینه سازی دیتابیس سرور چه فرقی با افزونه بهینهسازی دیتابیس وردپرس دارد؟
افزونهها فقط دادههای اضافه مثل رونوشتها و transientها را پاک میکنند، اما بهینهسازی دیتابیس سرور کوئریهای کند، ایندکسها و تنظیمات موتور دیتابیس را هم با رم و بار واقعی هماهنگ میکند.
خطای Error establishing a database connection را چطور رفع کنم؟
اول مطمئن شوید سرویس MySQL یا MariaDB اجرا میشود و دیسک پر نیست، سپس اطلاعات wp-config.php را با کنترلپنل مقایسه کنید. اگر سرویس پشتسرهم متوقف میشود، لاگ خطا و رویدادهای OOM را ببینید؛ نصب دوباره وردپرس کمکی نمیکند.
slow query log چیست و چطور فعال میشود؟
slow query log فهرست کوئریهایی است که از زمان مشخصی طولانیتر اجرا شدهاند. در MySQL و MariaDB با slow_query_log=1 و long_query_time، مثلاً ۱ ثانیه، فعال میشود؛ معادل آن در PostgreSQL تنظیم log_min_duration_statement است.
ایندکسگذاری در دیتابیس چیست و آیا همیشه سرعت را بیشتر میکند؟
ایندکس، مثل فهرست کتاب، پیدا کردن ردیفها را بدون خواندن کل جدول ممکن میکند، اما همیشه سرعت را بیشتر نمیکند. نوشتن را کندتر میکند و فضا میگیرد، پس باید بر اساس کوئریهای واقعی ساخته شود و روی همه ستونها لازم نیست.
خطای No space left on device با وجود فضای خالی دیسک یعنی چه؟
احتمالاً inodeها تمام شدهاند؛ inode در لینوکس برای هر فایل مصرف میشود و میلیونها فایل کش یا سشن آن را پر میکنند. حالت دیگر فایل حذفشدهای است که هنوز باز است؛ df -i و lsof +L1 هر دو را نشان میدهند.
OOM Killer چیست و چرا دیتابیس را متوقف میکند؟
OOM Killer بخشی از کرنل لینوکس است که هنگام تمام شدن رم فرایندی را میبندد تا سیستم از کار نیفتد. دیتابیس معمولاً بیشترین رم را دارد و قربانی میشود؛ راهحل تقسیم درست رم است و افزودن swap بهتنها کافی نیست.
آیا بهینهسازی دیتابیس یا سیستمعامل باعث قطعی یا از دست رفتن داده میشود؟
بعضی تغییرها ریاستارت سرویس لازم دارند و قطعی کوتاهی ایجاد میکنند؛ این ریاستارتها در زمان هماهنگشده با شما انجام میشوند. پیش از تغییرات پرریسک نسخه پشتیبان گرفته میشود تا در صورت بروز مشکل بتوان به وضعیت قبل برگشت.
دیتابیس یا سرور از کار افتاده است؟ مشکل را همین حالا گزارش دهید
موتور و نسخه دیتابیس، سیستمعامل، پیام خطا و زمان شروع مشکل را در تلگرام بنویسید. رمز عبور نفرستید؛ کارشناس کانفیگ سرور پس از بررسی اولیه رایگان، روش امن دسترسی و برآورد کار را اعلام میکند.
