سرور مجازی برای دیتابیس؛ رم پادشاه است، دیسک وزیرش
وقتی پایگاه‌داده‌ی شما کند می‌شود، کل برنامه کند می‌شود — حتی اگر وب‌سرور سریع‌ترین جهان باشد. این یعنی انتخاب سرور مجازی برای دیتابیس، با کمک راهنمای جامع سرور مجازی ایران، یکی از حساس‌ترین تصمیم‌های زیرساختی است که می‌گیرید: منبع اشتباه، یعنی سایت کند، سبد خرید رهاشده و در نهایت مشتری از دست رفته.
در این راهنما درباره‌ی سرور مجازی برای دیتابیس، تصمیم‌های واقعی استقرار پایگاه‌داده روی VPS را مرور می‌کنیم: چرا رم مهم‌تر از CPU است، کی باید دیتابیس را روی سرور جداگانه ببرید، تنظیمات اولیه‌ای که همه‌ی پروژه‌ها لازم دارند، و امنیت و بکاپی که در روز بد تفاوت بین «پنج دقیقه قطعی» و «پنج روز بحران» را می‌سازد. برای مبادی، راهنمای کامل سرور مجازی را هم بخوانید.
چرا رم مهم‌ترین منبع دیتابیس است
موتورهای پایگاه‌داده داده‌ی داغ را در RAM نگه می‌دارند (shared buffers در PostgreSQL، InnoDB buffer pool در MySQL). روی یک سرور مجازی برای دیتابیس قاعده‌ی تجربی ساده است: اگر کل مجموعه‌ی داده‌ی فعال شما در RAM جا می‌شود، سرور سریع است؛ اگر نه، دیسک کش می‌شود و همه‌چیز کند می‌شود. به همین دلیل برای سرور مجازی برای دیتابیس، ارتقای رم معمولاً اولین و اقتصادی‌ترین حرکت است.
- دیتابیس کوچک (تا چند صد مگابایت داده فعال): ۲ گیگابایت رم کافی است.
- دیتابیس متوسط (چند گیگابایت، تراکنش متوسط): ۴ تا ۸ گیگابایت رم + NVMe.
- دیتابیس بزرگ (ده‌ها گیگابایت، تراکنش بالا): ۱۶ گیگابایت به بالا، دیسک اختصاصی NVMe، و احتمالاً تفکیک master/replica.
برای برآورد سایز پروژه‌تان از ماشین‌حساب انتخاب سرور استفاده کنید و سپس قیمت سرور مجازی و پلن‌های سرور ابری ایران را مقایسه کنید.
IOPS: چرا NVMe برای دیتابیس غیرقابل‌مذاکره است
دیتابیس برخلاف سایت دانلود، با خواندن و نوشتن‌های ریز و بی‌وقفه کار می‌کند. معیار اینجا IOPS (تعداد عملیات در ثانیه) است، نه ظرفیت. یک SSD SATA حدود چند صد IOPS می‌دهد، یک NVMe چند ده‌هزار. تفاوت در کوئری‌های همزمان کاملاً محسوس است: جایی که SSD صف می‌سازد، NVMe فوراً جواب می‌دهد. روی هر سرور مجازی برای دیتابیس که write دارد (یعنی تقریباً همه)، NVMe را اولویت قرار دهید. مقایسه‌ی کامل در راهنمای NVMe در برابر SSD.
یک سرور یا دو سرور؟ لحظه‌ی تفکیک
در شروع کار با سرور مجازی برای دیتابیس، دیتابیس و وب‌سرور روی یک VPS مشکلی نیست — ساده و ارزان. ولی سه نشانه‌ی زنگ خطر وجود دارد: (۱) مصرف رم به حد بالا می‌رسد و وب‌سرور و دیتابیس شروع به رقابت بر سر منابع می‌کنند. (۲) سایت روی ترافیک سنگین، کندی دیتابیس را نشان می‌دهد در حالی که CPU وب‌سرور هنوز راحت است. (۳) می‌خواهید وب‌سرور را بدون قطعی دیتابیس آپدید یا مقیاس کنید.
در این نقطه از رشد سرور مجازی برای دیتابیس، دیتابیس را روی سرور مجزا ببرید. مزایا: منابع اختصاصی، امنیت بهتر (دیتابیس فقط از داخل شبکه‌ی خصوصی در دسترس)، و امکان آپگرید مستقل. روی استانی مثل مرجع کامل سرور مجازی ایران با شبکه‌ی داخلی سریع، تفکیک معمولاً پینگ تک‌رقمی دارد.
تنظیمات اولیه‌ای که هیچ‌وقت نباید جا بیفتد
- Connection pooling: اتصال مستقیم هر درخواست به دیتابیس، گران است. از PgBouncer (PostgreSQL) یا پروکسی مشابه استفاده کنید.
- تنظیم حافظه: buffer pool/shared buffers را به‌جای پیش‌فرضِ کوچک، روی حدود ۵۰-۷۰٪ رم اختصاص دهید (تنها وقتی دیتابیس روی سرور خودش است).
- ایندکس‌ها: کوئری‌های کند را با EXPLAIN پیدا کنید و ایندکس اضافه کنید. گاهی یک ایندکس، صدها برابر بهتر از ارتقای سخت‌افزار جواب می‌دهد.
- نصب امن: دیتابیس را فقط روی localhost یا آی‌پی داخلی listen کنید؛ هرگز مستقیم روی اینترنت.
- رمز عبور قوی + کاربر مجزا برای هر اپلیکیشن: از root user دیتابیس برای اپلیکیشن استفاده نکنید.
بکاپ دیتابیس؛ چیزی که در روز بد می‌سوزد یا نجات می‌دهد
بکاپ فایل خام دیتابیس در حال اجرا، بکاپ نیست — ممکن است ناقص یا خراب باشد. از ابزارهای snapshot منطقی استفاده کنید (pg_dump برای PostgreSQL، mysqldump یا Percona XtraBackup برای MySQL). حداقل: بکاپ روزانه خودکار + نگهداری چند نسل + تست بازگردانی. اگر داده‌ی سرور مجازی برای دیتابیس حیاتی است، استراتژی ۳-۲-۱ (سه نسخه، دو رسانه، یک مکان دیگر) را پیاده کنید. و حتماً یک بار بازگردانی را تمرین کنید — بکاپ تست‌نشده، بکاپ نیست.
امنیت دیتابیس روی سرور مجازی
- فایروال: پورت دیتابیس (۵۴۳۲ PostgreSQL، ۳۳۰۶ MySQL) را فقط برای سرور وب باز کنید، نه برای کل اینترنت. با ابزار بررسی پورت از بیرون تست کنید که واقعاً بسته است.
- رمزگذاری در حال انتقال: اتصال بین وب‌سرور و دیتابیس روی شبکه‌ی عمومی باید TLS داشته باشد.
- به‌روزرسانی: نسخه‌های قدیمی موتور دیتابیس، آسیب‌پذیری‌های شناخته‌شده دارند. آپدیت‌های امنیتی را جدی بگیرید.
- مانیتورینگ: تعداد اتصال، کوئری‌های کند و فضای دیسک را زیر نظر بگیرید. راهنمای مانیتورینگ نقطه‌ی شروع است.
ابزارهای رایگان داماش برای دیتابیس
- ماشین‌حساب انتخاب سرور — سایز متناسب با تراکنش.
- بررسی باز بودن پورت — تأیید اینکه پورت دیتابیس به اینترنت باز نیست.
- آی‌پی من چیست؟ — وقتی فقط سرور وب باید به دیتابیس وصل شود.
- محاسبه‌گر SLA — اگر دیتابیس ۹۹.۹٪ باید بالا بماند، یعنی چند دقیقه قطعی در ماه؟
محاسبه‌ی واقعی رم: فرمولی که پول شما را نجات می‌دهد
بیشتر مدیرانی که سرور مجازی برای دیتابیس می‌خرند، رم را «خیلی بزرگ» سفارش می‌دهند چون نمی‌دانند دقیقاً چه مقدار نیاز است. فرمول تجربی برای یک سرور مجازی برای دیتابیس پروداکشن: مجموع حجم ایندکس‌های فعال شما، به علاوه‌ی ۲۰ درصد برای sort و join موقت. اگر دیتابیس شما ۲۰ گیگابایت ایندکس فعال دارد، رمِ ۲۴ گیگابایت می‌تواند کل آن را در حافظه نگه دارد و دیسک تقریباً هیچ‌وقت برای read لمس نمی‌شود. این یعنی سرعت هزاران بار بالاتر، چون دسترسی به RAM نانوثانیه‌ای است ولی IOPS دیسک چه NVMe چه SSD، میلی‌ثانیه‌ای.
روی سرور مجازی برای دیتابیس، نشانه‌ی بی‌رم بودن واضح است: CPU usage پایین، load average بالا، و در خروجی top می‌بینید فرآیند دیتابیس بیشترِ وقتش را در حالت iowait است. یعنی پردازنده منتظر دیسک است. در این حالت ارتقای CPU هیچ کمکی نمی‌کند — فقط رم کمک می‌کند.
انتخاب موتور دیتابیس بر اساس بار کاری
انتخاب موتور سرور مجازی برای دیتابیس بین MySQL/MariaDB و PostgreSQL فقط سلیقه نیست. MySQL برای بارهای OLTP ساده (خواندن و نوشتنِ زیاد از جداول کوچک) فوق‌العاده است و پلتفرم‌های مثل وردپرس و فروشگاه‌های اینترنتی با آن بهترین عملکرد را دارند. PostgreSQL وقتی برنده می‌شود که داده‌ی پیچیده دارید: JSON-heavy کوئری‌ها، آنالیز روی میلیون‌ها ردیف، full-text search فارسی، یا typeهای پیشرفته. هر دو روی سرور مجازی برای دیتابیس در ایران به خوبی اجرا می‌شوند، ولی تنظیمات رم هر کدام متفاوت است.
یک قانون برای سرور مجازی برای دیتابیس در سایت‌های ایرانی: اگر فروشگاه وردپرسی دارید، MariaDB معمولاً سریع‌تر و سبک‌تر است. اگر اپلیکیشن اختصاصی با کوئری‌های تحلیلی دارید، PostgreSQL را جدی بگیرید. انتقال بعدی بین این دو دردسر دارد، پس از روز اول درست انتخاب کنید.
جدول مقایسه‌ی پیکربندی دیتابیس روی VPS
| منبع | دیتابیس کوچک (<۵GB) | دیتابیس متوسط (۵-۵۰GB) | دیتابیس بزرگ (>۵۰GB) |
|---|---|---|---|
| رم | ۴ گیگابایت | ۸-۱۶ گیگابایت | ۳۲ گیگابایت یا بیشتر |
| دیسک | SSD کافی | NVMe ۲۰۰-۵۰۰ گیگابایت | NVMe با IOPS بالا + RAID |
| CPU | ۲ هسته | ۴ هسته | ۸ هسته با فرکانس بالا |
| شبکه | ۱ گیگابیت | ۱-۲.۵ گیگابیت | پورت اختصاصی ۲.۵ گیگابیت |
| استراتژی | یک سرور | تفکیک وب و دیتابیس | Master-Replica + ProxySQL |
replication: وقتی
یک سرور دیگر کافی نیست
دیتابیس تک‌نقطه‌ای روی سرور مجازی برای دیتابیس، بزرگترین گلوگاه هر سایت پرترافیک است. راه حل استاندارد برای سرور مجازی برای دیتابیس: یک Master برای نوشتن و یک یا چند Replica برای خواندن. اکثر سایت‌ها ۸۰-۹۰ درصد کوئری‌هایشان read است، پس فشار را روی Replicaها می‌اندازید و Master فقط write انجام می‌دهد. روی سرور مجازی ایران این کار ساده است چون شما کنترل کامل شبکه‌ی داخلی دارید و تأخیر بین سرورها در دیتاسنتر یکسان، زیر میلی‌ثانیه است.
یک تله‌ی رایج در سرور مجازی برای دیتابیس: replication asynchronous است، یعنی یک ثانیه پس از نوشتن روی Master، هنوز روی Replica نیست. اگر منطق برنامه شما بلافاصله بعد از ثبت سفارش، همان سفارش را از Replica می‌خواند، آن را پیدا نمی‌کند. راه حل: نوشتن‌های بحرانی را مستقیم از Master بخوانید، یا semi-sync replication را فعال کنید.
چک‌لیست امنیتی دیتابیس که در روز اول باید انجام دهید
- دیتابیس را هرگز روی پورت پیش‌فرض و در دسترس عمومی قرار ندهید؛ فقط localhost یا IPهای سرورهایتان.
- روی سرور مجازی برای دیتابیس، پسورد root را از مقدار پیش‌فرض عوض کنید و از کلید SSH برای ورود استفاده کنید.
- کاربر اختصاصی برای هر اپلیکیشن بسازید، فقط با دسترسی به دیتابیس خودش — نه root.
- firewall را فعال کنید و فقط IPهای ضروری را باز بگذارید.
- query logging را روی محیط پروداکشن غیرفعال کنید چون هم دیسک را پر می‌کند و هم رم.
- از
mysql_secure_installationیا معادل آن اجرا بگیرید.
دقیقاً همین شش قدم، ۹۰ درصد حملات رایج به سرور مجازی برای دیتابیس را خنثی می‌کند. بدافزارها و ربات‌هایی که دیتابیس‌های روباز را اسکن می‌کنند، در هر ساعت هزاران سرور را چک می‌کنند؛ شما با این اقدامات از لیست هدفشان خارج می‌شوید.
مانیتورینگ دیتابیس: شش معیار که باید زیر نظر باشد
سرور مجازی برای دیتابیس مثل قلب سایت است؛ اگر متوقف شود، همه چیز متوقف می‌شود. این معیارها را مانیتور کنید: (۱) cache hit ratio — اگر زیر ۹۵ درصد افتاد یعنی رم کم است. (۲) slow queries — کوئری‌های بالای یک ثانیه را پیدا و ایندکس بزنید. (۳) connection count — نزدیک شدن به max_connections یعنی نشتی اتصال در برنامه. (۴) replication lag — وقتی بالای چند ثانیه رفت، کاربران داده‌ی قدیمی می‌بینند. (۵) دیسک پر شدن — دیتابیس وقتی دیسکش پر شود فوراً خراب می‌شود. (۶) uptime — هر ریاستارت غیرمنتظره یک هشدار است.
ابزارهای رایگان مانیتورینگ سرور مجازی برای دیتابیس مثل Prometheus + Grafana یا حتی netdata این‌ها را به‌صورت خودکار می‌دهند. روی یک سرور مجازی ایران نصبشان کنید و آلارم تلگرامی بگیرید — قبل از اینکه مشتری‌تان به شما بگوید سایت کند شده.
مهاجرت دیتابیس بدون قطعی
انتقال سرور مجازی برای دیتابیس به سرور جدید پر از استرس است، ولی روش درست آن وجود دارد. اول replication را از سرور قدیم به سرور جدید برقرار کنید (نه برعکس). صبر کنید تا داده‌ها همگام شوند — برای دیتابیس ۱۰ گیگابایتی روی شبکه‌ی داخلی، چند دقیقه طول می‌کشد. بعد برنامه را به‌طور موقت روی حالت read-only بگذارید، مطمئن شوید replication lag صفر است، سپس connection string را به سرور جدید تغییر دهید. کل قطعی: زیر یک دقیقه.
بزرگترین اشتباه، dump گرفتن از سرور مجازی برای دیتابیس و import کردن روی سرور جدید، در حالی که سایت هنوز روی قدیمی کار می‌کند. این یعنی داده‌های جدید در دیتابیس جدید نیستند و باید با ریستورت دستی جبران شوند.
یک نمونه‌ی واقعی: فروشگاه اینترنتی با ۲۰ هزار سفارش روزانه
فرض کنید فروشگاهی دارید که روزانه ۲۰ هزار سفارش ثبت می‌کند و هر کاربر در هر صفحه چند کوئری اجرا می‌کند. این یعنی روزانه چند میلیون کوئری. دیتابیس شما ۸۰ گیگابایت است که ۲۵ گیگابایتش ایندکس فعال. با فرمولی که گفتیم، رمِ ۳۲ گیگابایت کل ایندکس را در حافظه نگه می‌دارد و cache hit ratio روی ۹۹.۸٪ می‌ماند. سرعت پاسخ کوئری‌ها زیر ۲ میلی‌ثانیه می‌شود، چون هیچ IOPS دیسکی رخ نمی‌دهد.
حالا اگر همان سایت را روی سروری با ۸ گیگابایت رم اجرا کنید، فقط یک‌سوم ایندکس در RAM جا می‌گیرد. cache hit ratio به ۸۵٪ افت می‌کند، یعنی ۱۵ درصد کوئری‌ها به دیسک می‌روند. این ترافیک دیسک را ده‌ها برابر می‌کند و p99 latency از ۲ میلی‌ثانیه به ۴۰ میلی‌ثانیه می‌رسد. کاربر تاخیر را حس می‌کند و گوگل هم در Core Web Vitals آن را می‌بیند. پولی که برای ارتقای رم دادید، چند برابرش را از طریق نرخ تبدیل و رتبه‌ی جستجو برمی‌گرداند.
تعمیر و نگهداری دوره‌ای دیتابیس
دیتابیس مثل ماشین است؛ بدون سرویس دوره‌ای خراب می‌شود. سه کار که ماهی یک‌بار باید انجام دهید: ANALYZE TABLE برای به‌روزرسانی آمار کوئری‌پلنر (در MySQL/MariaDB)، VACUUM در PostgreSQL برای بازیافت فضای مرده، و بررسی ایندکس‌های بی‌مصرف که فقط نوشتن را کند می‌کنند. این کارها را در ساعات کم‌بار (نزدیک به صبح) انجام دهید چون روی جداول بزرگ قفل می‌گذارند.
یکی دیگر از کارهای مهم: بررسی slow log. کوئری‌هایی که بیش از یک ثانیه طول می‌کشند، معمولاً ایندکس مناسب ندارند. پیدا کردن و اضافه کردن یک ایندکس ساده، می‌تواند یک کوئری را از ۸ ثانیه به ۲۰ میلی‌ثانیه ببرد. هیچ ارتقای سخت‌افزاری به اندازه‌ی یک ایندکس درست، تأثیر ندارد.
چه زمانی سرور دیتابیس باید جدا شود؟
در ابتدا همه‌چیز روی یک سرور است و درست هم کار می‌کند. ولی سه نشانه می‌گوید زمان تفکیک فرا رسیده: اول، وقتی CPU load به دلیل دیتابیس بالای ۷۰٪ است و وب‌سرور از گرسنگی رنج می‌برد. دوم، وقتی رم دیتابیس با وب‌سرور و کش تقلا می‌کند و cache eviction زیاد می‌شود. سوم، وقتی می‌خواهید وب‌سرور را scale کنید ولی دیتابیس را نمی‌توانید جابجا کنید چون همه‌چیز به هم گره خورده.
تفکیک سرور مجازی برای دیتابیس، ساده‌ترین قدم کاشش (scaling) است. یک سرور برای وب + کش با رم متوسط، و یک سرور با رم بزرگ فقط برای دیتابیس. هزینه‌ی تقریباً یکسانی، ولی دو برابر ظرفیت.
سوالات متداول درباره سرور مجازی برای دیتابیس
PostgreSQL یا MySQL؟
هر دو برای اکثر پروژه‌ها عالی‌اند. PostgreSQL در کوئری‌های پیچیده، نوع‌های داده‌ی غنی و یکپارچگی تراکنشی قدرتمندتر است. MySQL/MariaDB در پروژه‌های وب ساده و میزبانی اشتراکی رایج‌تر است. اگر هیچ ترجیحی ندارید، با یکی شروع کنید؛ مهاجرت بعدی دردسر دارد ولی غیرممکن نیست.
چقدر رم برای دیتابیس لازم است؟
قاعده: اگر مجموعه‌ی داده‌ی فعال (نه کل داده، بخش داغ آن) در RAM جا می‌شود، سرور سریع است. برای شروع ۲ گیگابایت، برای پروژه‌های متوسط ۴ تا ۸ گیگابایت. مصرف واقعی را با مانیتورینگ ببینید، حدس نزنید.
آیا می‌شود دیتابیس و سایت روی یک سرور باشد؟
بله، برای شروع کاملاً منطقی و اقتصادی. وقتی رم به حد رسید یا می‌خواهید وب‌سرور را مستقل مقیاس کنید، دیتابیس را جدا کنید. علائم تفکیک: رقابت بر سر رم، کندی زیر ترافیک سنگین، نیاز به آپدیت بدون قطعی.
بکاپ دیتابیس چقدر بزرگ می‌شود؟
بستگی به داده‌ها دارد. دیتابیس با متن و لاگ تراکنش می‌تواند سریع رشد کند. بکاپ فشرده معمولاً بسیار کوچک‌تر از حجم خام است. چند نسل نگه دارید و فضای ذخیره‌سازی را در پلن بررسی کنید.
دیتابیس روی سرور ایران برای کاربران خارج هم خوب است؟
برای کاربران ایرانی عالی است. برای کاربران خارجی، پینگ سرور ایران تاخیر ایجاد می‌کند؛ در این حالت معمولاً API روی سرور خارجی و دیتابیس نزدیک آن بهتر است، یا از cache مرزی استفاده کنید.
IP تست قبل از خرید برای دیتابیس هم مهم است؟
بله. پینگ و پورت دیتاسنتر مقصد را از شبکه‌ی خودتان تست کنید تا مطمئن شوید تاخیر بین سرور وب و دیتابیس پایین است. در تفکیک، این تاخیر مستقیماً روی سرعت هر کوئری اثر می‌گذارد.
منبع تکمیلی: مستندات رسمی PostgreSQL درباره replication.
جمع‌بندی
سرور مجازی برای دیتابیس یعنی اول رم، بعد NVMe، بعد CPU. با یک سرور شروع کنید، با مانیتورینگ رشد را ببینید و وقتی علائم تفکیک ظاهر شد، دیتابیس را مستقل کنید. بکاپ منطقی روزانه + تست بازگردانی، و فایروال روی پورت دیتابیس، حداقل‌هایی هستند که جا نمی‌افتند. قیمت‌ها را ببینید و اگر در انتخاب سایز شک دارید، قبل از خرید مشاوره بگیرید.
منابع و مطالعهٔ بیشتر
برای عمیق‌شدن در این موضوع، مطالعهٔ پایگاه داده (Database) در ویکی‌پدیا را توصیه می‌کنیم.
