Установка MongoDB на VPS: базовая настройка и безопасность

Что мы настраиваем и зачем

В этом руководстве мы сосредоточимся на установке и настройке MongoDB на собственном виртуальном приватном сервере (VPS). MongoDB — это популярная документоориентированная база данных NoSQL, которая идеально подходит для современных веб-приложений, требующих гибкой схемы, высокой производительности и масштабируемости. В отличие от традиционных реляционных баз данных, MongoDB хранит данные в формате BSON (двоичный JSON), что делает ее очень удобной для работы с неструктурированными или полуструктурированными данными.

В итоге, по завершении этого туториала, вы получите полностью настроенный и защищенный экземпляр MongoDB, который будет готов к приему подключений от ваших приложений. Вы сможете управлять базой данных, создавать пользователей с различными правами доступа и быть уверенными в безопасности хранимых данных.

Почему стоит выбрать self-hosted MongoDB на VPS вместо облачных решений? Самостоятельное размещение предоставляет полный контроль над конфигурацией сервера, оптимизацией производительности и затратами. Для многих проектов, особенно на начальных этапах или при наличии специфических требований к безопасности и местоположению данных, собственный VPS может быть значительно экономичнее, чем управляемые облачные сервисы, такие как MongoDB Atlas, AWS DocumentDB или Azure Cosmos DB. Это также отличный способ глубоко понять работу базы данных и инфраструктуры.

Какой VPS-конфиг нужен под эту задачу

Выбор подходящего VPS-конфига критически важен для производительности и стабильности вашей базы данных MongoDB. Требования могут сильно варьироваться в зависимости от объема данных, интенсивности запросов и количества одновременных подключений. Мы ориентируемся на типовые задачи, такие как развертывание GitLab, Mattermost, Minecraft-сервера или ноды криптовалюты, где MongoDB может использоваться как часть стека.

Минимальные требования для небольшой нагрузки (разработка, тестовые среды, личные проекты):

• CPU: 2 ядра. Для MongoDB важно не только количество ядер, но и их производительность.
• RAM: 4 ГБ. MongoDB активно использует оперативную память для кэширования данных (WiredTiger Cache), что значительно повышает скорость работы. Меньше 4 ГБ может привести к интенсивному использованию диска и снижению производительности.
• Диск: 50 ГБ NVMe SSD. Скорость дисковой подсистемы — один из самых важных факторов для MongoDB. NVMe SSD обеспечивают значительно более высокие показатели IOPS (операций ввода-вывода в секунду) по сравнению с обычными SSD или HDD.
• Сеть: 1 Гбит/с. Для большинства задач этого достаточно.

Рекомендуемый VPS-план для умеренной нагрузки (небольшие продакшн-приложения, средние проекты):

Для более серьезных задач, где предполагается активная работа с данными и несколько одновременных пользователей, рекомендуется следующий конфиг:

• CPU: 4 ядра.
• RAM: 8-16 ГБ. Чем больше данных кэшируется в RAM, тем быстрее запросы.
• Диск: 160-320 ГБ NVMe SSD. Объем диска должен быть достаточен для текущих данных и их роста в течение нескольких лет, а также для бэкапов.
• Сеть: 1 Гбит/с.

Подходящий VPS с указанными характеристиками можно арендовать у проверенного провайдера, который предлагает NVMe SSD и гарантированную производительность.

Когда нужен dedicated сервер, а не VPS

Dedicated сервер следует рассматривать, если:

• Очень большие объемы данных: Сотни гигабайт или терабайты данных, требующие максимальной производительности дисковой подсистемы.
• Высокие требования к IOPS: Интенсивные операции чтения/записи, которые могут быть ограничены на VPS из-за общего использования ресурсов.
• Максимальная изоляция и безопасность: Полный контроль над аппаратным обеспечением, отсутствие "соседей" на том же физическом сервере.
• Специализированное оборудование: Необходимость в специфических RAID-контроллерах, высокопроизводительных сетевых картах или GPU для определенных задач.

Для большинства средних проектов VPS с хорошими NVMe SSD будет вполне достаточно. Если вы планируете развернуть большой GitLab, высоконагруженный SaaS или требовательную криптовалютную ноду, то подходящий dedicated сервер может быть более оправданным выбором.

Локация: на что влияет

Выбор локации VPS влияет на:

• Задержку (latency): Чем ближе сервер к вашим пользователям или к серверу приложения, которое будет подключаться к MongoDB, тем ниже будет задержка.
• Соответствие законодательству: В некоторых случаях требуется хранить данные в определенной юрисдикции (например, GDPR в Европе).
• Стоимость: Цены на VPS могут варьироваться в зависимости от дата-центра и региона.

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

Подготовка сервера

Перед установкой MongoDB необходимо провести минимальную настройку свежего VPS. Это обеспечит базовую безопасность и удобство управления. Мы будем использовать Ubuntu Server 24.04 LTS как наиболее распространенную и поддерживаемую операционную систему.

1. Подключение по SSH и обновление системы

Подключитесь к вашему VPS как пользователь root (или пользователь, предоставленный провайдером) через SSH. Затем обновите все пакеты до последних версий.

ssh root@ВАШ_IP_АДРЕС_VPS
sudo apt update && sudo apt upgrade -y
    

Эта команда обновляет список доступных пакетов и устанавливает все обновления системы.

2. Создание нового пользователя с правами sudo

Работа под пользователем root небезопасна. Создайте нового пользователя и предоставьте ему права sudo.

adduser ваш_пользователь
    

Следуйте инструкциям, чтобы установить пароль и заполнить информацию о пользователе. Затем добавьте пользователя в группу sudo:

usermod -aG sudo ваш_пользователь
    

Теперь вы можете выйти из сессии root и подключиться под новым пользователем:

exit
ssh ваш_пользователь@ВАШ_IP_АДРЕС_VPS
    

Все последующие команды, требующие прав администратора, выполняйте с префиксом sudo.

3. Настройка SSH-ключей (рекомендуется)

Для повышения безопасности рекомендуется использовать SSH-ключи вместо паролей. Если у вас еще нет пары ключей, создайте их на своей локальной машине:

ssh-keygen -t rsa -b 4096
    

Затем скопируйте публичный ключ на ваш VPS:

ssh-copy-id ваш_пользователь@ВАШ_IP_АДРЕС_VPS
    

После успешного копирования ключа, отредактируйте файл конфигурации SSH на сервере, чтобы отключить аутентификацию по паролю и запретить вход для root.

sudo nano /etc/ssh/sshd_config
    

Найдите и измените (или добавьте) следующие строки:

# Запретить вход для root
PermitRootLogin no

# Отключить аутентификацию по паролю (после проверки входа по ключу)
PasswordAuthentication no

# Убедитесь, что аутентификация по ключам разрешена
PubkeyAuthentication yes
    

Сохраните изменения (Ctrl+O, Enter) и выйдите (Ctrl+X). Перезапустите службу SSH:

sudo systemctl restart sshd
    

ВАЖНО: Прежде чем закрыть текущую SSH-сессию, откройте новое окно терминала и попробуйте подключиться к серверу, используя новый пользователь и SSH-ключ. Убедитесь, что вы можете войти. Если нет, исправьте ошибки, прежде чем закрывать текущую сессию, иначе вы можете потерять доступ к серверу.

4. Настройка брандмауэра (UFW)

UFW (Uncomplicated Firewall) — это удобный инструмент для управления брандмауэром. По умолчанию он блокирует все входящие соединения. Сначала разрешите SSH, затем включите UFW.

sudo ufw allow OpenSSH         # Разрешить SSH-соединения
sudo ufw enable                # Включить UFW. Подтвердите 'y'
sudo ufw status                # Проверить статус UFW
    

Пока порт MongoDB (27017) закрыт. Мы откроем его позже, после установки и базовой настройки.

5. Установка Fail2Ban

Fail2Ban сканирует логи сервера на предмет подозрительной активности (например, многочисленных неудачных попыток входа по SSH) и временно блокирует IP-адреса злоумышленников.

sudo apt install -y fail2ban   # Установить Fail2Ban
sudo systemctl enable fail2ban # Включить автозапуск при загрузке
sudo systemctl start fail2ban  # Запустить службу
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # Создать локальную копию для настроек
    

Откройте /etc/fail2ban/jail.local и убедитесь, что секция [sshd] активна (enabled = true). Вы также можете настроить bantime (время блокировки) и findtime (период для обнаружения попыток).

sudo nano /etc/fail2ban/jail.local
    

Найдите секцию [DEFAULT] и, при желании, измените:

bantime = 1d                 # Блокировать на 1 день
findtime = 10m               # Если за 10 минут...
maxretry = 5                 # ...было 5 неудачных попыток
    

Перезапустите Fail2Ban для применения изменений:

sudo systemctl restart fail2ban
    

Теперь ваш сервер имеет базовую защиту, и мы готовы к установке MongoDB.

Установка ПО — пошагово

Мы будем устанавливать MongoDB версии 7.0, которая является актуальной и стабильной на 2026 год, на Ubuntu Server 24.04 LTS. Установка будет производиться из официального репозитория MongoDB, что гарантирует получение актуальных обновлений и патчей безопасности.

1. Импорт публичного GPG-ключа MongoDB

Для проверки целостности пакетов MongoDB необходимо импортировать публичный GPG-ключ.

sudo apt install -y gnupg curl # Установка утилит gnupg и curl, если они еще не установлены
curl -fsSL https://www.mongodb.org/static/pgp/server-7.0.asc | \
   sudo gpg --dearmor -o /usr/share/keyrings/mongodb-server-7.0.gpg # Импорт ключа и сохранение в keyring
    

Эта команда загружает ключ и сохраняет его в директории /usr/share/keyrings/, делая его доступным для APT.

2. Добавление репозитория MongoDB в список источников APT

Теперь необходимо добавить URL официального репозитория MongoDB в список источников пакетов вашей системы. Это позволит APT находить и устанавливать пакеты MongoDB.

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-7.0.gpg ] https://repo.mongodb.org/apt/ubuntu $(lsb_release -cs)/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list
    

Эта команда добавляет новую строку в файл /etc/apt/sources.list.d/mongodb-org-7.0.list, указывая APT, где искать пакеты MongoDB 7.0 для вашей архитектуры (amd64 или arm64) и версии Ubuntu ($(lsb_release -cs) автоматически определит кодовое имя вашей версии Ubuntu, например, noble для 24.04 LTS).

3. Обновление индекса пакетов APT

После добавления нового репозитория необходимо обновить индекс пакетов, чтобы APT узнал о доступных пакетах MongoDB.

sudo apt update # Обновить список доступных пакетов
    

Вы должны увидеть информацию о пакетах из репозитория MongoDB в выводе этой команды.

4. Установка пакетов MongoDB

Теперь, когда репозиторий настроен, можно установить MongoDB и связанные утилиты. Пакет mongodb-org включает в себя сервер MongoDB (mongod), клиент командной строки (mongosh), а также утилиты для работы с базой данных (mongodump, mongorestore, mongoimport, mongoexport).

sudo apt install -y mongodb-org # Установить все компоненты MongoDB
    

Эта команда установит MongoDB 7.0 и все необходимые зависимости.

5. Запуск и включение службы MongoDB

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

sudo systemctl start mongod    # Запустить службу MongoDB
sudo systemctl enable mongod   # Включить автозапуск MongoDB при старте системы
    

Теперь MongoDB должна быть запущена и готова к работе.

6. Проверка статуса службы MongoDB

Убедитесь, что служба MongoDB работает корректно.

sudo systemctl status mongod   # Проверить статус службы MongoDB
    

Вы должны увидеть вывод, указывающий на то, что служба mongod активна (active (running)).

7. Проверка соединения с MongoDB через mongosh

Подключитесь к локальной базе данных MongoDB с помощью клиента командной строки mongosh.

mongosh # Подключиться к локальному экземпляру MongoDB
    

Если вы видите приглашение test> или >, значит, MongoDB успешно установлена и работает. Введите exit, чтобы выйти из клиента.

Конфигурация

После установки MongoDB по умолчанию работает без аутентификации и принимает соединения только с localhost (127.0.0.1). Для продакшн-среды это неприемлемо. Мы настроим аутентификацию, ограничим сетевой доступ и, опционально, включим TLS/SSL для шифрования соединений.

1. Настройка файла конфигурации MongoDB (mongod.conf)

Основной файл конфигурации MongoDB находится по адресу /etc/mongod.conf. Откройте его для редактирования:

sudo nano /etc/mongod.conf
    

Включение аутентификации

Это самый важный шаг для безопасности. Найдите секцию security и добавьте или раскомментируйте строку authorization: enabled:

# /etc/mongod.conf
...
security:
  authorization: enabled
...
    

Настройка сетевого доступа (bindIp)

По умолчанию bindIp установлен в 127.0.0.1, что означает, что MongoDB принимает соединения только с локальной машины. Если ваше приложение находится на том же VPS, это безопасно. Если же приложение находится на другом сервере или вы хотите получить доступ к MongoDB удаленно, вам нужно изменить bindIp. НИКОГДА не устанавливайте bindIp: 0.0.0.0 без адекватной настройки брандмауэра и аутентификации!

Если вы планируете доступ из определенного IP-адреса, укажите его:

# /etc/mongod.conf
...
net:
  port: 27017
  bindIp: 127.0.0.1,ВАШ_IP_ПРИЛОЖЕНИЯ # Добавьте IP вашего приложения или другого сервера
...
    

Если вы уверены, что ваш брандмауэр UFW настроен очень строго, можно временно указать 0.0.0.0, но это должно быть только после настройки UFW, как описано ниже.

Сохранение и перезапуск MongoDB

Сохраните изменения (Ctrl+O, Enter) и выйдите (Ctrl+X). Затем перезапустите службу MongoDB:

sudo systemctl restart mongod
    

Теперь MongoDB требует аутентификации для всех подключений.

2. Создание административного пользователя

После включения аутентификации вы не сможете подключиться к MongoDB без учетных данных. Поэтому необходимо создать административного пользователя. Для этого подключитесь к mongosh, но уже с аутентификацией. Так как аутентификация только что была включена, вы можете подключиться как localhost без учетных данных один раз, чтобы создать первого пользователя.

mongosh --port 27017 --authenticationDatabase admin # Подключаемся к базе admin
    

Внутри mongosh выполните следующие команды:

use admin
db.createUser(
   {
     user: "mongoAdmin",
     pwd: passwordPrompt(), // Введите пароль при запросе
     roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase" ]
   }
)
exit
    

Теперь вы можете подключиться к MongoDB с использованием созданного пользователя:

mongosh --port 27017 --authenticationDatabase admin -u mongoAdmin -p # Вас попросят ввести пароль
    

После успешного входа вы увидите приглашение admin> или >.

3. Создание пользователя для приложения

Для каждого приложения, использующего MongoDB, рекомендуется создавать отдельного пользователя с минимально необходимыми правами.

use your_app_db # Переключиться на базу данных вашего приложения (создаст ее, если не существует)
db.createUser(
   {
     user: "appUser",
     pwd: passwordPrompt(), // Введите пароль при запросе
     roles: [ { role: "readWrite", db: "your_app_db" } ] // Предоставить права только на чтение/запись в конкретной БД
   }
)
exit
    

Это гарантирует, что даже если учетные данные приложения будут скомпрометированы, злоумышленник не получит полный доступ ко всем базам данных.

4. Настройка брандмауэра (UFW) для MongoDB

Теперь, когда MongoDB защищена аутентификацией, можно открыть порт 27017, но только для разрешенных IP-адресов.

sudo ufw allow from ВАШ_IP_ПРИЛОЖЕНИЯ to any port 27017 # Разрешить доступ только с IP-адреса вашего приложения
sudo ufw status # Проверить статус UFW
    

Если вы хотите разрешить доступ из нескольких IP-адресов, повторите команду ufw allow для каждого из них. Если ваше приложение находится на том же сервере, вам не нужно открывать порт 27017 наружу, достаточно bindIp: 127.0.0.1.

5. Настройка TLS/SSL для шифрования соединений (опционально, но рекомендуется)

Для обеспечения конфиденциальности и целостности данных при передаче между клиентом и сервером MongoDB рекомендуется использовать TLS/SSL. Это особенно важно, если MongoDB доступна извне локальной сети.

Для настройки TLS вам потребуются сертификаты. Вы можете использовать самоподписанные сертификаты для тестирования или внутренние корпоративные сертификаты. Для публичных серверов рекомендуется использовать сертификаты от доверенного центра сертификации (CA), например, Let's Encrypt.

Создание самоподписанного сертификата (для примера)

Для генерации самоподписанного сертификата и ключа в одном файле .pem:

sudo mkdir -p /etc/ssl/mongodb
sudo openssl req -newkey rsa:2048 -new -nodes -x509 -days 365 -keyout /etc/ssl/mongodb/mongodb.key -out /etc/ssl/mongodb/mongodb.crt
sudo cat /etc/ssl/mongodb/mongodb.key /etc/ssl/mongodb/mongodb.crt | sudo tee /etc/ssl/mongodb/mongodb.pem
sudo chown -R mongodb:mongodb /etc/ssl/mongodb/
sudo chmod -R 600 /etc/ssl/mongodb/
    

sudo nano /etc/mongod.conf
    

# /etc/mongod.conf
...
net:
  port: 27017
  bindIp: 127.0.0.1,ВАШ_IP_ПРИЛОЖЕНИЯ
  ssl:
    mode: requireTLS # Все соединения должны использовать TLS
    PEMKeyFile: /etc/ssl/mongodb/mongodb.pem
    CAFile: /etc/ssl/mongodb/mongodb.pem # Если используете самоподписанный, CAFile может быть тем же
    allowConnectionsWithoutCertificates: false # Требовать клиентские сертификаты (можно установить в true, если не нужны)
...
    

sudo systemctl restart mongod
    

mongosh --host ВАШ_IP_АДРЕС_VPS --port 27017 --authenticationDatabase admin -u mongoAdmin -p --tls --tlsCAFile /etc/ssl/mongodb/mongodb.pem --tlsAllowInvalidHostnames # --tlsAllowInvalidHostnames только для самоподписанных
    

sudo apt install -y restic # Установка restic
    

sudo nano /usr/local/bin/backup_mongodb.sh
    

#!/bin/bash

# Параметры MongoDB
MONGO_USER="mongoAdmin"
MONGO_PASS="ВАШ_ПАРОЛЬ_АДМИНА" # В продакшене лучше использовать .env или переменные окружения
MONGO_AUTH_DB="admin"
MONGO_HOST="127.0.0.1" # Или IP, с которого разрешен доступ
MONGO_PORT="27017"

# Параметры бэкапа
BACKUP_DIR="/var/backups/mongodb_tmp"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
LOG_FILE="/var/log/mongodb_backup.log"

# Параметры Restic
# ВАЖНО: Вместо прямого указания пароля, используйте переменную окружения RESTIC_PASSWORD
# или файл с паролем, защищенный правами доступа.
# export RESTIC_PASSWORD="ВАШ_RESTIC_ПАРОЛЬ"
RESTIC_REPO="s3:s3.amazonaws.com/ВАШ_S3_БАКЕТ/mongodb_backups" # Пример S3. Может быть minio, B2, SFTP и т.д.
# export AWS_ACCESS_KEY_ID="ВАШ_AWS_KEY_ID"
# export AWS_SECRET_ACCESS_KEY="ВАШ_AWS_SECRET_KEY"

# Создание временной директории для дампа
mkdir -p $BACKUP_DIR/$TIMESTAMP || { echo "Не удалось создать директорию $BACKUP_DIR/$TIMESTAMP" >> $LOG_FILE; exit 1; }

echo "[$TIMESTAMP] Начат бэкап MongoDB..." >> $LOG_FILE

# Создание дампа MongoDB
mongodump --host $MONGO_HOST --port $MONGO_PORT --authenticationDatabase $MONGO_AUTH_DB \
          -u $MONGO_USER -p "$MONGO_PASS" --out $BACKUP_DIR/$TIMESTAMP >> $LOG_FILE 2>&1

if [ $? -ne 0 ]; then
    echo "[$TIMESTAMP] Ошибка при создании дампа MongoDB." >> $LOG_FILE
    rm -rf $BACKUP_DIR/$TIMESTAMP # Удалить неудачный дамп
    exit 1
fi

echo "[$TIMESTAMP] Дамп MongoDB успешно создан. Размер: $(du -sh $BACKUP_DIR/$TIMESTAMP | awk '{print $1}')" >> $LOG_FILE

# Инициализация репозитория restic, если он еще не существует
# restic init --repo $RESTIC_REPO # Выполнить вручную один раз

# Создание бэкапа с помощью restic
echo "[$TIMESTAMP] Загрузка бэкапа в репозиторий Restic..." >> $LOG_FILE
restic backup $BACKUP_DIR/$TIMESTAMP \
              --repo $RESTIC_REPO \
              --host $(hostname) \
              --tag "mongodb-daily" \
              --verbose >> $LOG_FILE 2>&1

if [ $? -ne 0 ]; then
    echo "[$TIMESTAMP] Ошибка при загрузке бэкапа Restic." >> $LOG_FILE
    exit 1
fi

echo "[$TIMESTAMP] Бэкап Restic успешно завершен." >> $LOG_FILE

# Очистка старых снимков (политика хранения)
echo "[$TIMESTAMP] Очистка старых бэкапов (keep-daily 7, keep-weekly 4, keep-monthly 6)..." >> $LOG_FILE
restic forget --repo $RESTIC_REPO \
              --prune \
              --tag "mongodb-daily" \
              --keep-daily 7 \
              --keep-weekly 4 \
              --keep-monthly 6 \
              --verbose >> $LOG_FILE 2>&1

if [ $? -ne 0 ]; then
    echo "[$TIMESTAMP] Ошибка при очистке старых бэкапов Restic." >> $LOG_FILE
    exit 1
fi

echo "[$TIMESTAMP] Очистка старых бэкапов завершена." >> $LOG_FILE

# Удаление временных файлов дампа
rm -rf $BACKUP_DIR/$TIMESTAMP
echo "[$TIMESTAMP] Временная директория $BACKUP_DIR/$TIMESTAMP удалена." >> $LOG_FILE

echo "[$TIMESTAMP] Бэкап завершен. Проверка репозитория:" >> $LOG_FILE
restic check --repo $RESTIC_REPO >> $LOG_FILE 2>&1
if [ $? -ne 0 ]; then
    echo "[$TIMESTAMP] Ошибка при проверке репозитория Restic." >> $LOG_FILE
    exit 1
fi
echo "[$TIMESTAMP] Репозиторий Restic проверен." >> $LOG_FILE
    

sudo chmod +x /usr/local/bin/backup_mongodb.sh
    

# Установите переменные окружения для текущей сессии
export AWS_ACCESS_KEY_ID="ВАШ_AWS_KEY_ID"
export AWS_SECRET_ACCESS_KEY="ВАШ_AWS_SECRET_KEY"
export RESTIC_PASSWORD="ВАШ_RESTIC_ПАРОЛЬ"

# Инициализация репозитория (выполняется ОДИН раз)
restic init --repo s3:s3.amazonaws.com/ВАШ_S3_БАКЕТ/mongodb_backups
    

sudo crontab -e
    

0 3    /usr/local/bin/backup_mongodb.sh >> /var/log/mongodb_backup_cron.log 2>&1
    

Эта запись будет запускать скрипт ежедневно в 3 часа ночи и перенаправлять весь вывод в файл /var/log/mongodb_backup_cron.log.

5. Обновления: rolling vs maintenance window

• Обновления ОС: Регулярно запускайте sudo apt update && sudo apt upgrade -y. Для продакшн-серверов рекомендуется проводить обновления в заранее определенное окно обслуживания (maintenance window), чтобы минимизировать риски.
• Обновления MongoDB: Обновление самой MongoDB (например, с 7.0 до 8.0) требует тщательного планирования и тестирования. Для одиночной ноды на VPS это обычно означает остановку службы (maintenance window). Для кластеров (replica sets) возможны rolling upgrades без простоя, но это выходит за рамки данного руководства. Всегда читайте официальную документацию MongoDB по обновлению для вашей версии.

Troubleshooting + FAQ

Даже при тщательной настройке могут возникнуть проблемы. Этот раздел поможет вам диагностировать и решать наиболее распространенные из них.

MongoDB не запускается или не доступна

Проблема: После перезагрузки сервера или изменения конфигурации MongoDB не запускается, или вы не можете к ней подключиться.

Что проверить:

1. Статус службы: sudo systemctl status mongod. Ищите ошибки в выводе, например, failed или exited.
2. Логи MongoDB: sudo tail -f /var/log/mongodb/mongod.log. Здесь будут подробные сообщения об ошибках при запуске или работе.
3. Файл конфигурации: sudo nano /etc/mongod.conf. Проверьте синтаксис YAML, особенно отступы. Неправильный bindIp или ошибки в секции security/net.ssl являются частыми причинами.
4. Доступ к файлам: Убедитесь, что пользователь mongodb имеет права на чтение/запись в /var/lib/mongodb и /var/log/mongodb, а также на чтение /etc/mongod.conf и TLS-сертификатов.
5. Занятый порт: sudo netstat -tuln | grep 27017. Убедитесь, что другой процесс не занимает порт 27017.

Как фиксить: Исправьте ошибки в mongod.conf, проверьте права доступа (sudo chown -R mongodb:mongodb /var/lib/mongodb /var/log/mongodb), затем попробуйте перезапустить службу: sudo systemctl restart mongod.

Ошибка "Authentication failed"

Проблема: Вы пытаетесь подключиться к MongoDB, но получаете ошибку "Authentication failed".

Что проверить:

1. Имя пользователя и пароль: Убедитесь, что вы используете правильные учетные данные.
2. База данных аутентификации: Убедитесь, что вы указываете правильную базу данных для аутентификации (например, --authenticationDatabase admin для административного пользователя).
3. Включена ли аутентификация: Проверьте, что в /etc/mongod.conf присутствует security.authorization: enabled. Если нет, включите, перезапустите MongoDB и создайте пользователя.

Как фиксить: Перепроверьте учетные данные. Если вы забыли пароль администратора, см. FAQ ниже.

Какой VPS-конфиг минимально подойдёт для MongoDB?

Для базовых задач, таких как разработка, небольшие личные проекты или тестовые среды, минимально достаточным будет VPS с 2 ядрами CPU, 4 ГБ оперативной памяти и 50 ГБ NVMe SSD диска. Однако, для любой продакшн-среды, даже с небольшой нагрузкой, настоятельно рекомендуется иметь не менее 4 ядер CPU, 8 ГБ RAM и 160 ГБ NVMe SSD. Это обеспечит стабильную работу и достаточную производительность для кэширования данных и обработки запросов.

Что выбрать — VPS или dedicated для этой задачи?

Выбор между VPS и dedicated сервером зависит от масштаба вашего проекта, требований к производительности, безопасности и бюджету. VPS отлично подходит для большинства средних проектов, где требуется гибкость, масштабируемость и экономичность. Он идеален для стартапов, небольших SaaS-приложений, игровых серверов для небольшой группы пользователей или криптовалютных нод, не требующих экстремальной производительности. Dedicated сервер необходим для высоконагруженных систем, больших объемов данных (терабайты), критически важных приложений с высокими требованиями к IOPS, или если вам нужна полная изоляция и максимальный контроль над аппаратным обеспечением. Если ваш проект активно растет и упирается в лимиты VPS, переход на dedicated будет логичным шагом.

Как сбросить пароль администратора MongoDB?

Если вы забыли пароль администратора, вам нужно временно отключить аутентификацию. Отредактируйте /etc/mongod.conf, закомментируйте или удалите строку security.authorization: enabled. Перезапустите MongoDB. Подключитесь к mongosh без аутентификации, переключитесь на базу admin, удалите старого административного пользователя (или обновите его пароль), затем создайте нового. После этого верните security.authorization: enabled в конфиг и перезапустите MongoDB.

Почему MongoDB потребляет так много RAM?

MongoDB активно использует оперативную память для кэширования данных (через движок WiredTiger). Это нормальное поведение, предназначенное для повышения производительности, поскольку чтение данных из RAM значительно быстрее, чем с диска. Если вы видите, что MongoDB потребляет много RAM, это часто хороший знак, указывающий на эффективное кэширование. Однако, если система начинает использовать своп, это признак нехватки RAM, и вам следует рассмотреть возможность увеличения объема памяти.

Нужно ли использовать репликацию для одной ноды на VPS?

Для одиночной ноды на VPS репликация в классическом смысле (создание нескольких копий данных на разных серверах) не имеет смысла, так как нет других серверов. Однако, вы можете настроить "одиночный репликасет" (single-node replica set). Это необходимо, если вы планируете использовать определенные функции MongoDB, такие как транзакции или Change Streams, которые требуют репликасета для работы. Для базовой установки без этих специфических требований, одиночный репликасет не является обязательным, но и не повредит.

Как ограничить доступ к MongoDB только для моего приложения?

Это достигается двумя ключевыми шагами:

1. Настройка bindIp в /etc/mongod.conf: Укажите конкретный IP-адрес вашего приложения (или нескольких IP-адресов), с которого разрешены подключения. Если приложение на том же сервере, используйте 127.0.0.1.
2. Настройка брандмауэра (UFW): Разрешите входящие соединения на порт 27017 только с IP-адреса вашего приложения: sudo ufw allow from ВАШ_IP_ПРИЛОЖЕНИЯ to any port 27017. Это обеспечит защиту на уровне сети.

MongoDB не запускается после перезагрузки сервера. Что делать?

Первым делом проверьте логи MongoDB: sudo tail -n 100 /var/log/mongodb/mongod.log. Частые причины:

• Повреждение базы данных: Иногда при некорректном завершении работы или нехватке места на диске данные могут повредиться. Попробуйте запустить MongoDB с опцией --repair (осторожно, может занять много времени).
• Нехватка места на диске: Проверьте df -h. Если диск заполнен, MongoDB не сможет создать новые файлы или лог-записи.
• Неправильные права доступа: Убедитесь, что пользователь mongodb имеет полные права на директории /var/lib/mongodb и /var/log/mongodb.
• Ошибки в mongod.conf: Неправильный синтаксис или неверные параметры могут препятствовать запуску.

Выводы и следующие шаги

Поздравляем! Вы успешно установили, настроили и защитили экземпляр MongoDB 7.0 на вашем VPS под управлением Ubuntu Server 24.04 LTS. Теперь у вас есть надежная и производительная база данных, готовая к интеграции с вашими приложениями. Вы реализовали базовые, но крайне важные меры безопасности, такие как аутентификация, ограничение сетевого доступа через брандмауэр и, опционально, шифрование трафика с помощью TLS/SSL. Также вы настроили автоматическое резервное копирование, что является краеугольным камнем любой продакшн-системы.

Дальнейшие шаги для оптимизации и масштабирования вашей установки MongoDB могут включать:

• Мониторинг производительности: Интегрируйте MongoDB с системами мониторинга, такими как Prometheus и Grafana, для отслеживания метрик производительности, использования ресурсов и состояния базы данных в реальном времени.
• Оптимизация запросов и индексация: Анализируйте медленные запросы и создавайте соответствующие индексы для улучшения скорости выполнения операций чтения в вашей базе данных.
• Репликация и шардинг: По мере роста вашего приложения и увеличения нагрузки рассмотрите возможность настройки репликации для обеспечения высокой доступности и устойчивости к отказам, а также шардинга для горизонтального масштабирования и распределения данных по нескольким серверам.