آموزش نصب MySQL و MariaDB روی اوبونتو با تنظیمات امن

MySQL پرکاربردترین پایگاه داده‌ی رابطه‌ای دنیاست و تقریباً هر پروژه‌ی وبی که با PHP، لاراول، وردپرس یا Node.js نوشته شده باشد، با آن سازگار است. در این راهنما گام‌به‌گام نصب MySQL روی اوبونتو را انجام می‌دهیم، سپس همان کار را با MariaDB تکرار می‌کنیم تا بتوانید آگاهانه بین این دو انتخاب کنید.

چرا پایگاه داده را روی سرور خودتان نصب کنیم؟ چون کنترل کامل نسخه، پیکربندی حافظه و سیاست بک‌آپ در دست شماست و هزینه‌ی پلکانیِ سرویس‌های مدیریت‌شده را نمی‌پردازید. داده‌ها هم روی زیرساخت خودتان می‌مانند. یک سرور ابری برای دیتابیس با حافظه‌ی کافی، برای بار کاری اکثر پروژه‌های متوسط بیش از اندازه است.

در ادامه روی Ubuntu 24.04 و 26.04 کار می‌کنیم: سرویس را نصب می‌کنیم، با mysql_secure_installation تنظیمات ناامن پیش‌فرض را می‌بندیم، کاربر و دیتابیس اختصاصی می‌سازیم، دسترسی از راه دور را محدود می‌کنیم و در پایان سراغ تیونینگ حافظه و بک‌آپ خودکار می‌رویم.

MySQL یا MariaDB؟ کدام را نصب کنیم

MariaDB انشعابی از MySQL است که پس از خرید MySQL توسط اوراکل ساخته شد. هر دو دستور mysql را دارند، هر دو پروتکل یکسانی حرف می‌زنند و برای اکثر برنامه‌ها بدون تغییر کد قابل تعویض‌اند. تفاوت‌های عملی این‌هاست:

• MariaDB کاملاً متن‌باز است، در مخزن رسمی اوبونتو نسخه‌ی به‌روزتری دارد و موتور ذخیره‌سازی و بهینه‌ساز کوئری خودش را توسعه می‌دهد.
• MySQL استاندارد صنعتی است و برخی قابلیت‌ها (مثل کلاستر گروهی و پشتیبانی کامل‌تر JSON در نسخه‌های اخیر) زودتر در آن ظاهر می‌شوند.

اگر برنامه‌ی شما به قابلیت خاصی از MySQL وابسته نیست، MariaDB انتخاب امن و بی‌دردسری است. اگر مستندات نرم‌افزارتان صراحتاً MySQL نسخه‌ی مشخصی را می‌خواهد، همان را نصب کنید. بقیه‌ی گام‌های این مقاله برای هر دو یکسان است.

پیش‌نیازها

• یک سرور ابری با Ubuntu 24.04 یا 26.04 و دسترسی root.
• برای شروع ۱ هسته پردازنده و ۲ گیگابایت حافظه کافی است. کارایی پایگاه داده بیش از هر چیز به حافظه وابسته است، پس برای بار تولیدی حافظه را بالاتر ببرید.
• اگر قرار است از یک سرور دیگر (سرور برنامه) به دیتابیس وصل شوید، آی‌پی آن سرور را آماده داشته باشید.

تمام دستورهای این راهنما با کاربر root اجرا می‌شوند. اگر با کاربر عادی کار می‌کنید، پیش از هر دستور sudo بگذارید.

گام ۱: نصب سرویس پایگاه داده

ابتدا فهرست بسته‌ها را به‌روز می‌کنیم:

apt update && apt upgrade -y

برای نصب MySQL:

apt install -y mysql-server

یا اگر MariaDB را انتخاب کرده‌اید:

apt install -y mariadb-server

فقط یکی از این دو را نصب کنید. هر دو روی پورت ۳۳۰۶ گوش می‌دهند و نصب هم‌زمانشان روی یک سرور به تداخل سرویس و فایل پیکربندی منجر می‌شود.

پس از نصب، سرویس خودکار راه می‌افتد. آن را فعال می‌کنیم تا بعد از ریبوت هم بالا بیاید و وضعیتش را بررسی می‌کنیم:

systemctl enable --now mysql      # برای MariaDB: systemctl enable --now mariadb
systemctl status mysql --no-pager

نام سرویس در MySQL برابر mysql و در MariaDB برابر mariadb است. اگر نام اشتباه را بدهید فقط پیام «واحد پیدا نشد» می‌گیرید و اتفاق بدی نمی‌افتد.

گام ۲: امن‌سازی نصب با mysql_secure_installation

نصب پیش‌فرض چند تنظیم ناامن دارد: پایگاه داده‌ی آزمایشی test که همه به آن دسترسی دارند، کاربران ناشناس و امکان ورود root از راه دور. اسکریپت رسمی همه‌ی این‌ها را یک‌جا می‌بندد:

mysql_secure_installation

اسکریپت چند پرسش می‌پرسد. پاسخ درست به هرکدام:

• افزونه‌ی سنجش قدرت رمز (VALIDATE PASSWORD) — فعال کردنش اختیاری است. اگر فعالش کنید، دیگر نمی‌توانید رمزهای ساده بگذارید؛ برای سرور تولیدی مفید است.
• رمز کاربر root — یک رمز قوی بگذارید و آن را در مدیر رمزتان ذخیره کنید.
• حذف کاربران ناشناس — بله. کاربر ناشناس یعنی اتصال بدون نام کاربری.
• ممنوع کردن ورود root از راه دور — بله. کاربر root فقط باید از خود سرور در دسترس باشد.
• حذف دیتابیس test — بله. این دیتابیس به‌طور پیش‌فرض برای همه قابل نوشتن است.
• بارگذاری دوباره‌ی جدول دسترسی‌ها — بله، تا تغییرها بلافاصله اعمال شوند.

اگر از این اسکریپت بگذرید، سرور شما با یک دیتابیس عمومیِ قابل‌نوشتن و امکان ورود root از راه دور بالا می‌آید. این ترکیب رایج‌ترین راهی است که یک پایگاه داده‌ی تازه‌نصب در چند ساعت اول اسکن و آلوده می‌شود.

گام ۳: ساخت کاربر و دیتابیس اختصاصی

هرگز برنامه‌ی خود را با کاربر root به دیتابیس وصل نکنید. برای هر برنامه یک کاربر و دیتابیس جداگانه بسازید تا اگر اعتبارنامه‌ای لو رفت، دامنه‌ی خسارت محدود بماند.

وارد محیط دستوری می‌شویم:

mysql -u root -p

و کاربر و دیتابیس را می‌سازیم:

CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'your-strong-password';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

چند نکته‌ی مهم در این چند خط:

• utf8mb4 تنها کدگذاری‌ای است که فارسی، عربی و ایموجی را کامل نگه می‌دارد. کدگذاری قدیمی utf8 در MySQL در واقع سه‌بایتی است و روی کاراکترهای چهاربایتی داده را خراب می‌کند. این تصمیم را در همان زمان ساخت دیتابیس بگیرید؛ تغییرش بعد از پر شدن جدول‌ها دردسر دارد.
• 'appuser'@'localhost' یعنی این کاربر فقط از خود سرور می‌تواند وصل شود. اگر به‌جای localhost علامت % بگذارید، کاربر از هر آی‌پی‌ای مجاز می‌شود.
• ON appdb.* دسترسی را به همین یک دیتابیس محدود می‌کند، نه کل سرور.

گام ۴: دسترسی از راه دور را چطور امن کنیم؟

اگر سرور برنامه و سرور دیتابیس یکی هستند، از این گام بگذرید؛ حالت پیش‌فرض (bind-address = 127.0.0.1) امن‌ترین حالت است و پورت ۳۳۰۶ اصلاً روی اینترنت باز نمی‌شود.

اگر واقعاً به اتصال از سرور دیگری نیاز دارید، فایل پیکربندی را باز می‌کنیم:

nano /etc/mysql/mysql.conf.d/mysqld.cnf

در MariaDB مسیر فایل /etc/mysql/mariadb.conf.d/50-server.cnf است. مقدار bind-address را به آی‌پی داخلی سرور محدود می‌کنیم:

bind-address = 10.0.0.5

از مقدار 0.0.0.0 که روی همه‌ی رابط‌های شبکه گوش می‌دهد پرهیز کنید. اگر سرورهای شما شبکه‌ی خصوصی دارند، آی‌پی همان شبکه را بگذارید تا ترافیک دیتابیس اصلاً از اینترنت عمومی عبور نکند.

سپس یک کاربر مخصوص همان آی‌پی می‌سازیم:

CREATE USER 'appuser'@'203.0.113.10' IDENTIFIED BY 'your-strong-password';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'203.0.113.10';
FLUSH PRIVILEGES;

و سرویس را دوباره راه‌اندازی می‌کنیم:

systemctl restart mysql

گام ۵: بستن فایروال

دو لایه‌ی محدودسازی لازم است: یکی در خود دیتابیس و یکی در فایروال. فایروال UFW را نصب می‌کنیم و پورت ۳۳۰۶ را فقط برای آی‌پی سرور برنامه باز می‌کنیم:

apt install -y ufw
ufw allow OpenSSH
ufw allow from 203.0.113.10 to any port 3306 proto tcp
ufw enable

قاعده‌ی from ... to any port 3306 یعنی تنها همان یک سرور به پورت دیتابیس می‌رسد. اگر دیتابیس و برنامه روی یک سرور هستند، خط دوم را اصلاً اضافه نکنید.

پیش از اجرای ufw enable مطمئن شوید قاعده‌ی OpenSSH را اضافه کرده‌اید، وگرنه ارتباط SSH فعلی شما قطع می‌شود. اگر این اتفاق افتاد، از کنسول تحت وب کنترل پنل ابر سپهر وارد سرور شوید و قاعده را اضافه کنید.

برای امن‌سازی کامل‌تر سرور (کلید SSH، Fail2ban و غیرفعال کردن ورود با رمز) راهنمای امن‌سازی سرور لینوکس را دنبال کنید.

گام ۶: تیونینگ پایه برای کارایی بهتر

مقادیر پیش‌فرض محافظه‌کارانه‌اند تا روی کوچک‌ترین سیستم‌ها هم اجرا شوند. مهم‌ترین پارامتر، اندازه‌ی استخر بافر InnoDB است. یک فایل پیکربندی جداگانه می‌سازیم تا تنظیم‌های ما با به‌روزرسانی بسته بازنویسی نشود:

nano /etc/mysql/conf.d/tuning.cnf

و محتوای زیر را برای سروری با ۴ گیگابایت حافظه در آن می‌گذاریم:

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 512M
innodb_flush_method = O_DIRECT
max_connections = 150
slow_query_log = 1
long_query_time = 1

معنای پارامترهای مهم:

• innodb_buffer_pool_size حافظه‌ای است که داده و ایندکس در آن کش می‌شوند و تعیین‌کننده‌ترین عدد برای کارایی است. حدود ۵۰ تا ۷۰ درصد حافظه‌ی سرور نقطه‌ی شروع خوبی است. اگر آن را بزرگ‌تر از حافظه‌ی موجود بگذارید، سرویس بالا نمی‌آید.
• max_connections سقف اتصال هم‌زمان است. هر اتصال حافظه مصرف می‌کند، پس بالا بردن بی‌حساب آن سرور را به swap می‌اندازد. اگر برنامه‌تان استخر اتصال دارد، عدد پیش‌فرض معمولاً کافی است.
• slow_query_log کوئری‌های کندتر از یک ثانیه را ثبت می‌کند. این لاگ نخستین جایی است که هنگام کند شدن سایت باید نگاه کنید.

پس از ذخیره، سرویس را راه‌اندازی مجدد و مقدار اعمال‌شده را بررسی می‌کنیم:

systemctl restart mysql
mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

اگر بعداً منابع سرور را از کنترل پنل ابر سپهر ارتقا دادید، این اعداد را هم متناسب با حافظه‌ی جدید به‌روز کنید؛ در غیر این صورت حافظه‌ی اضافه بلااستفاده می‌ماند.

نگهداری: به‌روزرسانی و بک‌آپ

به‌روزرسانی‌های جزئی از مسیر عادی بسته‌های سیستم می‌آیند و امن هستند:

apt update && apt upgrade -y

بک‌آپ منطقی با mysqldump گرفته می‌شود. سوییچ --single-transaction باعث می‌شود جدول‌های InnoDB بدون قفل شدن و بدون توقف سرویس خوانده شوند:

mysqldump --single-transaction --routines --triggers appdb | gzip > /root/appdb-$(date +%F).sql.gz

بدون --routines و --triggers، رویه‌های ذخیره‌شده و تریگرها در فایل خروجی نمی‌آیند و بازیابی ناقص می‌شود. بازیابی از همین فایل ساده است:

gunzip -c /root/appdb-2026-08-08.sql.gz | mysql appdb

برای اینکه بک‌آپ خودکار شود، یک کران‌جاب روزانه تعریف کنید:

crontab -e

و این خط را اضافه کنید:

0 3 * * * mysqldump --single-transaction --routines --triggers appdb | gzip > /root/backups/appdb-$(date +\%F).sql.gz

علامت درصد در کران‌جاب باید با بک‌اسلش فرار داده شود، وگرنه cron خط را نصفه اجرا می‌کند و فایل خروجی نام درستی نمی‌گیرد.

نگه‌داشتن بک‌آپ روی همان سرور کافی نیست. فایل‌ها را با بک‌آپ خودکار سرور با Restic به فضای ذخیره‌سازی بیرونی بفرستید. در کنار آن، اسنپ‌شات کنترل پنل ابر سپهر پیش از هر تغییر پرخطر سریع‌ترین راه بازگشت به وضعیت سالم است.

جمع‌بندی

با این راهنما نصب MySQL روی اوبونتو (یا MariaDB) را انجام دادید، تنظیم‌های ناامن پیش‌فرض را بستید، یک کاربر و دیتابیس ایزوله ساختید و بک‌آپ خودکار راه انداختید.

سه تصمیمی که بیشترین تفاوت را می‌سازند: اجرای mysql_secure_installation بلافاصله پس از نصب، نگه‌داشتن bind-address روی آی‌پی محدود به‌جای 0.0.0.0، و تنظیم innodb_buffer_pool_size متناسب با حافظه‌ی واقعی سرور. اگر پروژه‌ی شما به جای MySQL از PostgreSQL استفاده می‌کند، آموزش نصب PostgreSQL همین مسیر را برای آن پوشش می‌دهد.

اگر هنوز سروری برای پایگاه داده‌تان ندارید، از صفحه سرور ابری برای دیتابیس با حافظه‌ی مناسب شروع کنید و هر زمان بار کاری بیشتر شد، منابع را ارتقا دهید.

منابع:

• مستندات رسمی MySQL
• مستندات رسمی MariaDB