Системный журнал — практичная база знаний по VPS и Linux
Системный журнал Системный журнал
MariaDB • PostgreSQL • Linux • VPS • Базы данных

MariaDB или PostgreSQL для VPS: выбор, установка и базовая настройка

6 мин чтения Урок 5 из 6

MariaDB и PostgreSQL — зрелые реляционные СУБД, но они решают задачи немного по-разному. Выбирать нужно не по абстрактному рейтингу, а по требованиям приложения, доступной памяти, навыкам команды и процедуре резервного восстановления. Для одного сайта обычно устанавливают одну СУБД, а не обе.

Короткий выбор

  • MariaDB — естественный выбор для WordPress и многих PHP-приложений, ожидающих совместимость с MySQL.
  • PostgreSQL — сильный вариант для сложных запросов, строгой модели данных, расширений, геоданных, аналитики и приложений, изначально рассчитанных на PostgreSQL.
  • Требование приложения важнее предпочтения администратора. Если разработчик и миграции поддерживают только одну СУБД, не заменяйте её без тестов.

Сравнение по практическим критериям

Критерий MariaDB PostgreSQL
Типичный сценарий WordPress, PHP CMS, MySQL-совместимые приложения Сложные веб-приложения, данные с жёсткими ограничениями, GIS, аналитика
Совместимость Высокая с экосистемой MySQL, но не абсолютная Собственная экосистема и SQL-диалект
Расширения Плагины движков и серверные возможности Развитая система расширений, включая PostGIS
Администрирование Привычно для классического LAMP/LEMP Роли, схемы и гибкая модель прав
Резервные копии mariadb-dump, mariadb-backup pg_dump, pg_dumpall, pg_basebackup

Перед установкой

free -h
df -hT /
ss -lntup
cat /etc/os-release

На маленьком VPS оставьте запас памяти приложению и ядру. Значения по умолчанию дистрибутива обычно безопаснее случайного «тюнинга» из интернета. Сначала измерьте нагрузку, затем изменяйте буферы и число соединений.

Установка MariaDB

Для максимальной предсказуемости начните с пакетов вашего выпуска Debian или Ubuntu:

sudo apt update
sudo apt install mariadb-server mariadb-client
sudo systemctl enable --now mariadb
sudo systemctl status mariadb --no-pager

Проверьте версию и подключение через локальный сокет:

mariadb --version
sudo mariadb -e 'SELECT VERSION();'

На Debian/Ubuntu административный вход root часто использует Unix socket. Не меняйте его на простой пароль без необходимости.

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

sudo mariadb
CREATE DATABASE appdb
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

CREATE USER 'appuser'@'localhost'
  IDENTIFIED BY 'ЗАМЕНИТЕ_НА_ДЛИННЫЙ_ПАРОЛЬ';

GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Не используйте административного пользователя приложения. Выдавайте права только на его базу.

Проверка:

mariadb -u appuser -p appdb \
  -e 'SELECT DATABASE(), CURRENT_USER();'

Базовая безопасность MariaDB

sudo mariadb-secure-installation

На пакетной установке часть рекомендаций уже применена. Читайте каждый вопрос: бездумное изменение root-аутентификации может сломать системные скрипты.

Проверьте сетевой сокет:

sudo mariadb -e "SHOW VARIABLES LIKE 'bind_address';"
ss -lntp | grep 3306

Если база нужна только локальному приложению, она не должна слушать публичный адрес. Firewall — дополнительный слой, но основное ограничение задаётся bind-address и правами пользователей.

Установка PostgreSQL

sudo apt update
sudo apt install postgresql postgresql-client
sudo systemctl enable --now postgresql
sudo systemctl status postgresql --no-pager

Проверьте кластеры и версию:

pg_lsclusters
sudo -u postgres psql -c 'SELECT version();'

Создание роли и базы PostgreSQL

sudo -u postgres psql
CREATE ROLE appuser
  LOGIN
  PASSWORD 'ЗАМЕНИТЕ_НА_ДЛИННЫЙ_ПАРОЛЬ';

CREATE DATABASE appdb OWNER appuser;
\c appdb
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
GRANT CREATE ON SCHEMA public TO appuser;
\q

Проверка локального TCP-подключения:

psql "host=127.0.0.1 dbname=appdb user=appuser" \
  -c 'SELECT current_database(), current_user;'

Как PostgreSQL управляет доступом

Сетевые адреса задаются параметром listen_addresses, а правила клиентов — в pg_hba.conf. Узнайте фактические пути:

sudo -u postgres psql -Atc \
"SHOW config_file; SHOW hba_file; SHOW listen_addresses;"

После изменений сначала проверьте конфигурацию:

sudo -u postgres psql -c 'SELECT pg_reload_conf();'
sudo journalctl -u postgresql --since '-10 minutes' --no-pager

Не добавляйте правило 0.0.0.0/0 с парольной аутентификацией ради удобства. Для удалённого доступа используйте приватную сеть или VPN, ограниченный CIDR, TLS и отдельную роль.

Не открывайте базу в интернет

Для приложения на том же VPS используйте localhost или Unix socket. Если приложение находится на другом сервере:

  • создайте приватную сеть или VPN;
  • ограничьте firewall точным адресом источника;
  • включите шифрование;
  • выдайте минимальные права;
  • отслеживайте попытки входа и число соединений.

Проверка потребления ресурсов

systemctl status mariadb postgresql --no-pager
ps -eo pid,comm,rss,%mem,%cpu --sort=-rss | head
ss -lntp | grep -E '3306|5432'

Не устанавливайте огромный buffer pool или shared_buffers по проценту из случайной статьи. На VPS память делят база, PHP/приложение, Nginx, контейнеры и файловый кэш.

Логическая резервная копия MariaDB

sudo mariadb-dump \
  --single-transaction \
  --routines --events --triggers \
  appdb | gzip > appdb-$(date +%F).sql.gz

Проверка архива:

gzip -t appdb-$(date +%F).sql.gz
zcat appdb-$(date +%F).sql.gz | head

Логическая резервная копия PostgreSQL

Custom format удобен для выборочного и параллельного восстановления:

sudo -u postgres pg_dump -Fc appdb \
  > appdb-$(date +%F).dump

Список объектов:

pg_restore --list appdb-$(date +%F).dump | head

Роли и глобальные объекты сохраняются отдельно:

sudo -u postgres pg_dumpall --globals-only \
  > postgres-globals-$(date +%F).sql

Проверка после установки

  • Служба активна и не имеет ошибок в journal.
  • База слушает только ожидаемый адрес.
  • Приложение входит отдельным непривилегированным пользователем.
  • Кодировка и часовой пояс соответствуют требованиям.
  • Создан тестовый дамп и выполнено восстановление в отдельную тестовую базу.
  • В мониторинге есть свободный диск, память, соединения и ошибки.

Когда миграция между СУБД оправдана

Миграция MariaDB → PostgreSQL или обратно — не смена одного пакета. Нужно преобразовать типы, SQL, индексы, автоинкременты, процедуры и код приложения. Проводите её только при измеримой выгоде, с тестовым контуром и планом отката.

Итог

Для WordPress и MySQL-совместимого приложения выбирайте MariaDB. Для приложения, которое использует возможности PostgreSQL или требует сложной модели данных, выбирайте PostgreSQL. Установите одну СУБД из надёжного репозитория, держите её на локальном интерфейсе, создайте отдельную роль приложения и проверьте восстановление дампа до запуска в продакшен.

Обновления и переходы между крупными версиями

Пакетное обновление внутри поддерживаемой ветки и переход на новую крупную версию базы — разные операции. Перед major upgrade:

  • прочитайте примечания к выпуску СУБД и пакетов дистрибутива;
  • создайте логический dump и отдельную файловую или физическую копию;
  • проверьте расширения, кодировки и колляции;
  • восстановите данные на тестовом сервере;
  • измерьте время миграции и подготовьте откат.

PostgreSQL меняет внутренний формат между крупными версиями; применяют dump/restore, pg_upgrade или репликацию. Для MariaDB внимательно проверяют совместимость движков, системных таблиц и приложения. Наличие snapshot не отменяет логический дамп, который можно проверить независимо.

Минимальный мониторинг базы

Кроме доступности процесса отслеживайте соединения, медленные запросы, размер данных, ошибки и свободное место:

sudo mariadb -e 'SHOW GLOBAL STATUS LIKE "Threads_connected";'
sudo -u postgres psql -c \
"SELECT count(*) AS connections FROM pg_stat_activity;"
df -hT /var/lib/mysql /var/lib/postgresql 2>/dev/null

Аварийное завершение из-за полного диска может повредить сервис и заблокировать запись. Оповещение должно приходить заранее, а не при достижении 100%.