Базы данных (ProdDB)

Все production-базы данных Magnet вынесены на отдельный сервер 89.125.25.130 (ProdDB) и изолированы каждая в своём Incus-контейнере (по образцу dev-хоста Sky 89.125.90.103). Внутри контейнеров СУБД работают нативно (systemd), наружу проброшены на те же стандартные порты через proxy-устройства Incus.

Перенесены с прежнего сервера 85.198.75.53 (magnet-test.tech) 07.06.2026. Прежний сервер оставлен рабочим без изменений (как резерв/откат).

Хост

Параметр	Значение
IP / hostname	`89.125.25.130` / `ProdDB`
ОС	Ubuntu 24.04 LTS
CPU / RAM / Диск	8 vCPU / 16 GB / 160 GB (ext4, `/dev/vda1`)
Контейнеризатор	Incus 7.1 (репозиторий Zabbly)
Storage backend	`dir`, пул `default`
Сеть контейнеров	мост `incusbr0`, подсеть `10.160.43.0/24` (NAT)
Swap	общий `/swapfile` 15 GB (в `/etc/fstab`)
Firewall	отсутствует (порты БД публичны — см. Безопасность)

примечание

На хосте не установлен Docker — СУБД работают нативно внутри контейнеров. Это исключает конфликты iptables между Docker и Incus.

Контейнеры

Контейнер	СУБД	Внешний порт (на `89.125.25.130`)	SSH-порт	RAM	CPU	Внутр. IP
`mysql`	MySQL 8.0.46	3306	2201	3 GiB	4	10.160.43.72
`redis`	Redis 7.0.15	6379	2202	3 GiB	2	10.160.43.44
`mongo`	MongoDB 8.0	27017	2203	3 GiB	2	10.160.43.29
`neo4j`	Neo4j Enterprise 2025.05.1 + APOC	7687 (Bolt) + 7474 (HTTP)	2204	6 GiB	6	10.160.43.107
`backups`	backup-сервис (Node/ts-node)	—	2205	1 GiB	2	10.160.43.48

Каждый контейнер: boot.autostart=true (поднимается после перезагрузки хоста) и доступ к общему swap через raw.lxc=lxc.cgroup2.memory.swap.max=max. Суммарные лимиты памяти (16 GiB) равны физической RAM хоста — это потолки, пики поглощает swap (модель overcommit, как на эталоне).

примечание

Внутри incusbr0 контейнеры резолвят друг друга по имени (mysql, redis, mongo, neo4j). Это используется backup-сервисом для доступа к БД по внутренней сети.

Подключение к базам данных

Клиенты подключаются по внешнему IP на стандартных портах (как и на прежнем сервере — изменился только адрес):

mysql   -h 89.125.25.130 -P 3306  -u <user> -p           # MySQL
redis-cli -h 89.125.25.130 -p 6379 -a <password>          # Redis
mongosh "mongodb://<user>:<pass>@89.125.25.130:27017/?authSource=admin"   # MongoDB
cypher-shell -a bolt://89.125.25.130:7687 -u neo4j -p <pass>              # Neo4j (Bolt)
# Neo4j Browser: http://89.125.25.130:7474

Учётные данные всех СУБД перенесены с источника без изменений — приложения подключаются теми же логинами/паролями. Базы данных:

MySQL: magnet, translations (+ пользователи magnetprod, vovilonn, belts_dev, melqonyan_mher, translationsAdmin, admin, backup_user).
MongoDB: magnet-clicker (основная) + nft, lottery, roulette, arbitrage, PROGRAM_LEVELS_CONFIG (пользователи в admin: admin, mongoprod, backup_user, belts_dev, vovilonn, netdata).
Neo4j: neo4j, program1, preregistrationp1, preregistrationp2. Пользователи: neo4j, admin, backup_user, belts_dev, melqonyan_mher, vovilonn.
Redis: 16 логических БД, аутентификация по ACL (/etc/redis/users.acl).

Исключения по учётным данным

Neo4j: Neo4j не отдаёт хэши паролей наружу, поэтому пароли пяти вторичных аккаунтов (admin, backup_user, belts_dev, melqonyan_mher, vovilonn) пересозданы с временным паролем и ролями. Основной аккаунт neo4j (его используют приложения) перенесён с исходным паролем без изменений. Владельцам вторичных аккаунтов следует сбросить пароль.
MySQL: для доступа backup-сервиса по внутренней сети добавлен пользователь backup_user@'10.160.43.%' с тем же паролем и грантами, что у backup_user@'localhost'.

Доступы (SSH в контейнеры)

В каждом контейнере есть непривилегированный пользователь devuser (uid 1001, sudo без пароля). Вход — по SSH-ключу на персональный порт контейнера:

ssh devuser@89.125.25.130 -p 2201   # mysql
ssh devuser@89.125.25.130 -p 2202   # redis
ssh devuser@89.125.25.130 -p 2203   # mongo
ssh devuser@89.125.25.130 -p 2204   # neo4j
ssh devuser@89.125.25.130 -p 2205   # backups

Один devuser на контейнер используется всеми, у кого есть доступ; идентификация — по отдельной строке в ~/.ssh/authorized_keys (выдаётся и отзывается независимо).

Управление ключами

На хосте (от root) доступны вспомогательные команды:

Команда	Назначение
`proj-status`	Список контейнеров + таблица SSH-портов
`proj-addkey <контейнер> "<публичный ключ>"`	Выдать доступ (добавить ключ devuser)
`proj-listkeys <контейнер>`	Показать ключи контейнера
`proj-revokeall <контейнер>`	Удалить все ключи контейнера

proj-addkey mysql "ssh-ed25519 AAAA... ivanov@laptop"
ssh devuser@89.125.25.130 -p 2201      # сотрудник сразу может зайти

Отозвать доступ одного человека (не трогая остальных) — отредактировать файл напрямую: incus exec <контейнер> -- nano /home/devuser/.ssh/authorized_keys.

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

Backup-сервис (magnet-backups-service, TypeScript) запущен в контейнере backups под systemd (magnet-backups.service, enabled + Restart=always — переживает перезагрузку). К базам ходит по внутренней сети incusbr0 (mysql, mongo, neo4j:6362).

Расписание: дважды в сутки 0 1,13 * * * (плюс один прогон при старте сервиса).
Куда: Yandex Cloud Object Storage (S3), бакеты magnet-mysql-backups, prod-magnet-mongo-backups, prod-programs-graph-backups (neo4j: program1, neo4j), prod-preregistration-graph-backups (neo4j: preregistrationp1/p2).
Статус: MySQL, MongoDB, Neo4j (4 БД) — бэкапятся и заливаются успешно (проверено).

Ручной прогон / логи:

ssh devuser@89.125.25.130 -p 2205
sudo journalctl -u magnet-backups -f                 # логи
sudo systemctl restart magnet-backups                # форс-прогон (backup при старте)

Известные ограничения бэкапа

Redis-бэкап не работает — в конфиге сервиса (REDIS_PASSWORD) пароль не совпадает с ACL Redis (унаследовано с прежнего сервера, где бэкап Redis тоже не работал). Чтобы починить: задать паролю default-пользователя Redis известное значение и прописать его в .env сервиса.
Telegram-алерты не уходят — релей 176.12.75.106:3781 недоступен с этого хоста (внешняя зависимость; на сам бэкап не влияет, ошибки гасятся).

Снапшоты

Перед заливкой данных снимались снапшоты контейнеров (pre-data). Перед рискованными изменениями:

incus snapshot create <контейнер> pre-change-2026-06-07
incus snapshot restore <контейнер> pre-change-2026-06-07   # откат

warning

Снапшоты Incus лежат на том же диске, что и контейнеры, — это защита от ошибок изменения, но не замена бэкапам в S3.

Управление контейнерами

incus list                                   # статус + IP всех контейнеров
incus info <контейнер>                        # потребление ресурсов
incus stop|start <контейнер>                  # остановить / запустить
incus config set <контейнер> limits.memory=4GiB   # изменить лимит RAM
incus config set <контейнер> limits.cpu=4         # изменить лимит CPU

Безопасность

Порты БД публичны

Порты 3306, 6379, 27017, 7687, 7474 проброшены на 0.0.0.0 и firewall не настроен (как было на прежнем сервере). Это удобно для совместимости, но небезопасно. Рекомендуется ограничить доступ: firewall с whitelist IP приложений (incus/ufw/nftables) и/или fail2ban, либо доступ только через SSH-туннель/VPN.

Эксплуатационные замечания

Память: сумма лимитов контейнеров (16 GiB) равна физической RAM хоста; реальное потребление ниже, пики идут в swap (15 GB). При росте нагрузки поднимать лимит точечно, контролируя incus list / free -h.
Диск: бэкенд dir, контейнеры и снапшоты делят корневой раздел (160 GB). Следить за df -h /.
Сеть: новый хост 89.125.25.130 не имеет сетевого маршрута до прежнего 85.198.75.53 (важно учитывать при любых будущих переносах между ними — потребуется релей).
iptables хоста не должен переопределяться сторонними правилами, ломающими FORWARD для 10.160.43.0/24 (в частности, не ставить Docker на хост).

Хост​

Контейнеры​

Подключение к базам данных​

Доступы (SSH в контейнеры)​

Управление ключами​

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

Снапшоты​

Управление контейнерами​

Безопасность​

Эксплуатационные замечания​