Как установить и настроить MySQL на VPS

MAATRIX

MySQL на VPS — это надёжная база под сайты, CMS и приложения, которую вы полностью контролируете сами. Никаких лимитов shared-хостинга на число подключений, размер базы и запросы в секунду: только ваши ресурсы и ваши правила. Ниже — рабочий путь от чистого сервера до защищённого MySQL: установка из официального репозитория, первичная защита, создание пользователей и баз, настройка удалённого доступа, базовый тюнинг InnoDB и резервное копирование.

Что нужно перед установкой

MySQL нетребователен к старту: 1–2 ядра и 2 ГБ RAM хватает под сайт на WordPress, небольшой интернет-магазин или API. Основной ресурс, который ест MySQL, — оперативная память под кэш InnoDB, поэтому при росте базы и трафика увеличивайте именно RAM. Для нагруженного проекта берите 4 ГБ и больше.

Локация зависит от аудитории. Для российских проектов логичен RU-сервер: минимальный пинг и хранение персональных данных в стране согласно 152-ФЗ. Если база обслуживает зарубежный сервис — подойдут US или UK с их близостью к внешним API и низкой задержкой до Европы.

Примеры даны для Ubuntu 24.04 LTS. Работаем под пользователем с sudo, доступ по SSH-ключу. Перед установкой обновите систему командой sudo apt update && sudo apt upgrade -y, чтобы не тянуть заведомо устаревшие пакеты и не ловить конфликты зависимостей позже.

Установка MySQL

В репозитории Ubuntu лежит рабочая версия MySQL 8, и для большинства задач её достаточно. Установка предельно простая:

sudo apt update
sudo apt install -y mysql-server
sudo systemctl enable --now mysql

Проверьте, что сервер запустился и слушает порт:

sudo systemctl status mysql
sudo ss -ltnp | grep 3306

Если нужна самая свежая версия напрямую от Oracle с оперативными обновлениями, подключите официальный APT-репозиторий MySQL: скачайте deb-пакет конфигурации с dev.mysql.com, установите его и обновите список пакетов. Для типичного сайта или приложения версия из штатного репозитория Ubuntu полностью подходит и получает обновления безопасности вместе с системой, так что усложнять без нужды не стоит.

Первичная защита базы

Свежая установка MySQL небезопасна по умолчанию: пустые тестовые базы, анонимные пользователи, разрешённый удалённый вход root. Всё это закрывает штатный скрипт:

sudo mysql_secure_installation

Он проведёт по шагам: задать политику надёжности паролей, удалить анонимных пользователей, запретить удалённый вход root, удалить тестовую базу. Отвечайте «да» на всё, кроме тех пунктов, что осознанно хотите оставить. Это минимум гигиены, без которого сервер небезопасен с первой минуты.

В MySQL 8 root по умолчанию входит через auth_socket — то есть только локально из-под системного root, без пароля по сети. Это удобно и безопасно: администрируйте базу командой sudo mysql, а для приложений заводите отдельных пользователей с паролями. Не переключайте root на парольную аутентификацию без реальной необходимости — сокетный вход надёжнее.

Стоит понимать, чем эта модель отличается от привычной по старым версиям. Раньше при установке MySQL спрашивал пароль root и складывал его в парольную аутентификацию, из-за чего утёкший пароль открывал полный доступ к серверу по сети. Сокетная аутентификация убирает этот риск в принципе: чтобы войти под root, нужно уже иметь права root на самой машине. Поэтому первый и главный барьер — это доступ к серверу по SSH-ключу, а не пароль базы. Держите SSH под ключом, отключите вход по паролю, и административный доступ к MySQL защищён на уровне операционной системы.

Создание пользователя и базы

Приложение никогда не должно ходить в базу под root. Создайте отдельного пользователя с доступом только к своей базе:

sudo mysql

CREATE DATABASE appdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'слоЖный_Пароль_2026';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Обратите внимание на кодировку utf8mb4 — это полноценный UTF-8 с поддержкой эмодзи и всех символов, в отличие от урезанного utf8, который в MySQL исторически хранит только три байта. Для новых баз всегда используйте utf8mb4, иначе позже поймаете странные ошибки на нестандартных символах. Проверьте вход нового пользователя: mysql -u appuser -p appdb.

Удалённый доступ к MySQL

По умолчанию MySQL слушает только localhost, и это правильно. Если база и приложение на одном сервере, ничего менять не нужно. Открывать порт наружу стоит лишь при подключении внешнего клиента, и делать это надо аккуратно.

Сначала разрешите серверу слушать нужный адрес в конфиге:

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

bind-address = 10.0.0.5

Затем создайте пользователя, привязанного к конкретному внешнему адресу, а не к % (любой хост):

CREATE USER 'appuser'@'10.0.0.20' IDENTIFIED BY 'пароль';
GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'10.0.0.20';

Обязательно закройте порт 3306 фаерволом для всех, кроме доверенных адресов: sudo ufw allow from 10.0.0.20 to any port 3306. Самый безопасный вариант — вообще не открывать порт в интернет, а ходить в базу через SSH-туннель или приватную сеть между серверами. Открытый в мир 3306 сканируется ботами постоянно и становится целью перебора паролей в первые же часы.

Базовый тюнинг InnoDB

Главный параметр производительности MySQL — размер буфера InnoDB. Он кэширует данные и индексы в памяти, и от него зависит почти всё. Ориентир для сервера с 4 ГБ RAM — отдать под буфер 50–70% памяти:

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

innodb_buffer_pool_size = 2G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 1
max_connections = 150

innodb_buffer_pool_size — сердце настройки: чем больше данных помещается в память, тем меньше обращений к диску. innodb_flush_log_at_trx_commit = 1 даёт максимальную надёжность (данные не теряются при сбое), но чуть медленнее; значение 2 быстрее, но рискованнее при аварийном выключении. Для большинства проектов оставляйте 1. После правки перезапустите сервер: sudo systemctl restart mysql и проверьте журнал на ошибки.

Не гонитесь за десятками параметров сразу. На практике буфер InnoDB решает 80% вопроса производительности, остальное — точечная доводка под конкретную нагрузку. Прежде чем крутить настройки вслепую, включите лог медленных запросов (slow_query_log) и посмотрите, что реально тормозит. Очень часто оказывается, что дело не в конфиге сервера, а в отсутствии индекса на часто запрашиваемом столбце — и один правильный индекс ускоряет сайт сильнее, чем любой тюнинг памяти. Меняйте параметры по одному, замеряйте результат, и только тогда двигайтесь дальше. Слепое копирование чужих «идеальных конфигов» из интернета чаще вредит, чем помогает, потому что они писались под другое железо и другую нагрузку.

Резервное копирование

База без бэкапа — потенциальная катастрофа. Простейший и надёжный способ для сайтов и небольших баз — логический дамп через mysqldump:

mysqldump -u root --single-transaction --routines --triggers appdb > /var/backups/appdb_$(date +%F).sql

Флаг --single-transaction снимает согласованную копию без блокировки таблиц InnoDB — сайт продолжает работать во время бэкапа. Восстановление так же просто: mysql -u root appdb < /var/backups/appdb_2026-08-24.sql. Автоматизируйте задачу через cron ежедневно ночью и храните копии за две недели.

Для больших баз, где дамп занимает часы, смотрите в сторону физического бэкапа (Percona XtraBackup) или реплики. И главное правило: держите хотя бы одну копию вне сервера. Чтобы всё это работало без сюрпризов, нужен VPS с гарантированными ресурсами и SSD. В MAATRIX можно арендовать сервер под MySQL в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не нужна.

Частые вопросы