Встановлення MongoDB на

Резервні копії та обслуговування

Резервне копіювання — критично важливий аспект будь-якої системи, особливо бази даних. Втрата даних може призвести до катастрофічних наслідків. Ми розглянемо, що потрібно резервувати, як це робити за допомогою mongodump та restic, і куди зберігати резервні копії.

1. Що резервувати

• Дані MongoDB: Це найголовніше. Самі бази даних, колекції, індекси.
• Файл конфігурації MongoDB: /etc/mongod.conf. Містить важливі налаштування сервера.
• SSL/TLS сертифікати та ключі: Якщо ви використовуєте TLS, переконайтеся, що файли .pem, .key, .crt також резервуються.
• Скрипти резервного копіювання: Якщо ви створюєте свої скрипти, їх також потрібно зберігати.

2. Простий скрипт авторезервування (mongodump + restic)

Для створення резервних копій MongoDB ми будемо використовувати утиліту mongodump, яка створює бінарний дамп даних. Для безпечного та ефективного зберігання резервних копій ми будемо використовувати restic — сучасний інструмент для резервного копіювання, який підтримує дедуплікацію, шифрування та різні сховища.

Встановлення restic

sudo apt install -y restic # Встановлення restic
    

Створення скрипта резервного копіювання

Створіть файл /usr/local/bin/backup_mongodb.sh:

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
    

Ініціалізація репозиторію Restic

Перед першим використанням скрипта, вам потрібно ініціалізувати репозиторій restic. Переконайтеся, що у вас налаштовані змінні оточення для доступу до S3 (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) та змінна RESTIC_PASSWORD.

# Встановіть змінні оточення для поточної сесії
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
    

Якщо ви використовуєте інший тип репозиторію (наприклад, SFTP), замініть s3:s3.amazonaws.com/... на відповідний шлях.

3. Куди зберігати резервні копії

Ніколи не зберігайте резервні копії на тому ж сервері, що й вихідні дані. У разі відмови сервера ви втратите і дані, і резервні копії.

• Зовнішній S3-сумісний сервіс: Хмарні сховища, такі як Amazon S3, DigitalOcean Spaces, Backblaze B2, або MinIO на власному сервері, є чудовим вибором. Вони надійні, масштабовані та відносно недорогі.
• Окремий VPS: Ви можете налаштувати другий, менш потужний VPS виключно для зберігання резервних копій.
• Віддалений SFTP-сервер: Якщо у вас є доступ до іншого сервера через SFTP, restic підтримує цей протокол.

4. Налаштування Cron для автоматичного запуску резервного копіювання

Щоб скрипт виконувався автоматично, додайте його до розкладу cron.

sudo crontab -e
    

Додайте наступний рядок для щоденного резервного копіювання о 03:00 ночі. Переконайтеся, що змінні оточення для restic доступні в контексті cron-завдання. Найкраще прописати їх у самому скрипті або в окремому файлі, який скрипт буде "source"ити.

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 щодо оновлення для вашої версії.

Вирішення проблем + 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, для відстеження метрик продуктивності, використання ресурсів та стану бази даних у реальному часі.
• Оптимізація запитів та індексація: Аналізуйте повільні запити та створюйте відповідні індекси для покращення швидкості виконання операцій читання у вашій базі даних.
• Реплікація та шардинг: У міру зростання вашого застосунку та збільшення навантаження розгляньте можливість налаштування реплікації для забезпечення високої доступності та стійкості до відмов, а також шардингу для горизонтального масштабування та розподілу даних по кількох серверах.