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

MAATRIX

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

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

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

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

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

Установка MariaDB

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

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

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

sudo systemctl status mariadb
sudo ss -ltnp | grep 3306

Если нужна конкретная свежая мажорная версия с прямой поддержкой от разработчиков, подключите официальный репозиторий MariaDB — на сайте проекта есть генератор строк репозитория под вашу систему. Для типичного сайта версия из репозитория Ubuntu полностью подходит: она получает обновления безопасности вместе с системой, и усложнять установку без необходимости смысла нет. Заранее решать, какая версия нужна, стоит только если приложение жёстко требует конкретный релиз.

Отдельно стоит понимать разницу в путях и именах служб, потому что она сбивает с толку при переходе с MySQL. Служба в systemd называется mariadb (алиас mysql тоже работает), конфиги лежат в каталоге /etc/mysql/mariadb.conf.d/, а данные — в /var/lib/mysql. Историческое наследие MySQL сохранено намеренно, чтобы старые скрипты и инструменты не ломались. Клиентские команды при этом задублированы: и mariadb, и привычный mysql открывают одну и ту же консоль, а mariadb-dump полностью соответствует mysqldump. Если в документации вашего приложения встречаются старые имена — они продолжают работать, это не ошибка.

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

Свежая установка требует базовой гигиены. В отличие от старого MySQL, MariaDB предлагает улучшенный скрипт защиты, но принцип тот же:

sudo mariadb-secure-installation

Скрипт проведёт по шагам: переключить root на безопасную аутентификацию, удалить анонимных пользователей, запретить удалённый вход root, удалить тестовую базу и перезагрузить привилегии. Отвечайте утвердительно на всё — это минимум, без которого сервер небезопасен с первой минуты работы.

По умолчанию root в MariaDB входит через unix_socket — то есть только локально из-под системного root, без пароля по сети. Это удобно и безопасно: администрируйте базу командой sudo mariadb, а для приложений заводите отдельных пользователей с паролями. Такой подход означает, что первый барьер защиты — это доступ к серверу по SSH-ключу. Держите SSH под ключом с отключённым входом по паролю, и административный доступ к базе защищён на уровне операционной системы, а не только паролем.

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

Приложение не должно ходить в базу под root — это прямое нарушение принципа минимальных прав. Заведите отдельного пользователя с доступом только к своей базе:

sudo mariadb

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. Если создать базу в старой кодировке, позже поймаете искажения на нестандартных символах, и чинить это придётся восстановлением из дампа. Проверьте вход нового пользователя командой mariadb -u appuser -p appdb. Правило простое: одно приложение — один пользователь и одна база, так вы ограничиваете последствия возможной утечки пароля.

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

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

Разрешите серверу слушать нужный адрес в конфиге и создайте пользователя, привязанного к конкретному IP:

sudo nano /etc/mysql/mariadb.conf.d/50-server.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 и бэкап

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

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

Чем больше данных помещается в буфер, тем реже база обращается к диску и тем быстрее отвечает. Значение innodb_flush_log_at_trx_commit = 1 даёт максимальную надёжность против потери данных при сбое; 2 быстрее, но рискованнее — для большинства проектов оставляйте 1. Не крутите десятки параметров сразу: буфер решает большую часть вопроса, остальное — точечная доводка после анализа медленных запросов.

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

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

Автоматизируйте задачу через cron ежедневно ночью, храните копии за две недели и держите хотя бы одну вне сервера. Бэкап, лежащий на том же диске, что и база, не спасёт при отказе диска или случайном DROP DATABASE — вся ценность резервной копии в том, что она физически отдельно. Раз в пару месяцев обязательно проверяйте, что дамп реально восстанавливается: разверните его на тестовой базе и убедитесь, что данные на месте. Резервная копия, которую ни разу не восстанавливали, — это надежда, а не гарантия. Чтобы всё это работало стабильно, нужен VPS с гарантированными ресурсами и SSD. В MAATRIX можно арендовать сервер под MariaDB в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не нужна.

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