Основные команды администрирования MongoDB для начинающих

Администрирование MongoDB начинается в mongosh, но цель не в том, чтобы запомнить каждую команду. Цель — знать, как безопасно осмотреться, подтвердить, где вы находитесь, вносить небольшие изменения осознанно и избегать разрушительных команд в неправильной базе данных.

Если вы новичок в MongoDB, сначала потренируйтесь выполнять эти команды на локальном экземпляре или в тестовой базе данных, которую можно удалить. Некоторые команды в этом руководстве, такие как dropDatabase() и drop(), безвозвратно удаляют данные. MongoDB сделает то, что вы попросите; он не будет знать, что вы хотели выполнить команду где-то ещё.

Подключение с помощью mongosh

Для локального экземпляра MongoDB на порту по умолчанию подключитесь с помощью:

mongosh

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

mongosh "mongodb://[email protected]:27017/admin"

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

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

db

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

Список баз данных и переключение между ними

Показать видимые базы данных:

show dbs

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

Переключить контекст базы данных с помощью use:

use myAppDB

MongoDB не создает базу данных сразу после выполнения use. Она создается при первой записи данных, например, при вставке документа или явном создании коллекции.

Проверьте текущую базу данных еще раз:

db

Для скриптов предпочтительнее использовать явные дескрипторы баз данных, чтобы код меньше зависел от контекста оболочки:

const appdb = db.getSiblingDB("myAppDB")
appdb.getCollectionNames()

Коллекции: список, создание, просмотр, удаление

Список коллекций в текущей базе данных:

show collections

Или используйте JavaScript:

db.getCollectionNames()

Явно создайте коллекцию, когда вам нужны такие опции, как валидация, ограниченное поведение или выбор кластеризации/индексов, поддерживаемых вашей версией MongoDB:

db.createCollection("logs")

Большинство коллекций приложений создаются автоматически при первой вставке, но явное создание понятнее для административной настройки.

Просмотр статистики коллекции:

db.orders.stats()

Посмотреть индексы:

db.orders.getIndexes()

Удаление коллекции — разрушительное действие:

db.logs.drop()

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

db
db.getCollectionNames()
db.logs.countDocuments({})

Для очень больших коллекций countDocuments({}) может быть затратным. В этом случае используйте метаданные, выборку или операционные панели вместо выполнения массовых подсчетов во время пикового трафика.

Вставка тестового документа и его запрос

Даже администраторам нужны основы CRUD для проверки. Вставьте небольшой документ:

db.healthcheck.insertOne({ source: "admin-test", createdAt: new Date() })

Прочитайте его обратно:

db.healthcheck.find({ source: "admin-test" }).sort({ createdAt: -1 }).limit(5)

Удалите только тестовый документ:

db.healthcheck.deleteMany({ source: "admin-test" })

Используйте конкретные фильтры. Избегайте массовых удалений во время обучения. Команда типа deleteMany({}) удаляет все документы в коллекции.

Основы управления пользователями

Команды для пользователей выполняются в той базе данных, где определен пользователь. Административные пользователи часто создаются в admin. Пользователи приложений могут быть созданы в базе данных приложения, в зависимости от вашей модели безопасности.

Переключитесь на admin:

use admin

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

db.createUser({
  user: "appAdmin",
  pwd: passwordPrompt(),
  roles: [
    { role: "userAdminAnyDatabase", db: "admin" },
    { role: "readWriteAnyDatabase", db: "admin" }
  ]
})

Для обычного приложения используйте более узкие разрешения. Например, приложение, которое только читает и записывает в myAppDB, не должно получать широкие административные роли:

use myAppDB

db.createUser({
  user: "myAppUser",
  pwd: passwordPrompt(),
  roles: [
    { role: "readWrite", db: "myAppDB" }
  ]
})

Список пользователей в текущей базе данных:

show users

Обновляйте роли осторожно:

db.grantRolesToUser("myAppUser", [ { role: "read", db: "reporting" } ])

Удаляйте роли так же осознанно:

db.revokeRolesFromUser("myAppUser", [ { role: "read", db: "reporting" } ])

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

Статус сервера и текущие операции

serverStatus возвращает большой документ со счетчиками и информацией о времени выполнения:

db.serverStatus()

Новичкам обычно не нужен весь документ. Извлеките нужные разделы:

db.serverStatus().connections
db.serverStatus().mem
db.serverStatus().opcounters

Текущие операции могут помочь, когда что-то зависло или работает медленно:

db.currentOp()

На загруженном сервере отфильтруйте:

db.currentOp({ active: true, secs_running: { $gte: 5 } })

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

Проверки набора реплик

Если ваше развертывание является набором реплик, эти команды распространены:

rs.status()
rs.conf()

rs.status() показывает участников, состояние здоровья, состояние, информацию об optime и то, какой узел является первичным. Запускайте ее, когда приложения сообщают об ошибках записи, когда узел перезапустился или когда подозревается отставание репликации.

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

db.hello()

В старых примерах может использоваться isMaster(). Новые версии MongoDB поддерживают hello; вы все еще можете увидеть старую команду в существующих скриптах.

Опасные команды требуют ритуалов

Для разрушительной работы не торопитесь. Простой ритуал предотвращает реальные сбои:

db
show collections
// подтвердите имя хоста или строку подключения в подсказке терминала или заметках
// подтвердите план резервного копирования или восстановления, если это рабочая среда
db.collectionName.drop()

Для удаления базы данных:

use databaseToRemove
db.dropDatabase()

Эта команда удаляет текущую базу данных. Опасность не в синтаксисе; опасность в неправильном контексте.

Контрольный список для начинающих администраторов

Когда вы подключаетесь к среде MongoDB, привыкните к этой последовательности:

db
show dbs
use myAppDB
show collections
db.orders.getIndexes()
db.serverStatus().connections
db.currentOp({ active: true })

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

Администрирование MongoDB становится гораздо менее пугающим, когда вы относитесь к mongosh сначала как к инструменту проверки, а затем как к инструменту изменений. Смотрите, подтверждайте, затем действуйте. Используйте узкие роли, запрашиваемые пароли, отфильтрованные запросы и явные имена баз данных. Эта привычка важнее, чем запоминание длинного списка команд.

Внимательно читайте размеры баз данных и коллекций

Новички часто используют show dbs как инструмент оценки размера, но это только отправная точка. Движки хранения, сжатие, индексы и удаленное пространство могут сделать числа размеров неожиданными. Используйте статистику коллекций, когда вам нужно больше деталей:

db.orders.stats()

Посмотрите также на размер индекса:

db.orders.totalIndexSize()

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

db.orders.getIndexes()
db.orders.find({ customerId: "c123" }).explain("executionStats")

Не удаляйте индексы без необходимости в рабочей среде. Индекс, который выглядит неиспользуемым, может поддерживать ежемесячный отчет или редко используемый экран администратора. Прежде чем удалять его, проверьте журналы запросов, владельцев приложений и мониторинг.

Базовое понимание резервного копирования

Администрирование командной строки всегда должно быть связано с привычками резервного копирования. Перед разрушительным обслуживанием знайте, как создается резервная копия базы данных и как было протестировано восстановление. В самостоятельно управляемой MongoDB вы можете увидеть mongodump и mongorestore для логического резервного копирования:

mongodump --uri "mongodb://user@host:27017/myAppDB" --out ./backup

Для крупных производственных систем могут быть более подходящими снимки файловой системы, снимки облачного провайдера, Ops Manager или резервные копии Atlas. Суть для новичка проста: не считайте drop, deleteMany или изменения ролей обратимыми, если у вас нет проверенного пути восстановления.

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

Проверяйте журналы, когда команд недостаточно

mongosh показывает ответы сервера, но не заменяет журналы. Если пользователи сообщают о медленных запросах, ошибках аутентификации или колебаниях подключений, проверьте журналы MongoDB и журналы вашей платформы. В самостоятельно управляемых развертываниях Linux журналы могут находиться в /var/log/mongodb/, в зависимости от пакета и конфигурации. В контейнерах используйте журналы среды выполнения контейнера. В Atlas используйте интерфейс Atlas и загружаемые журналы.

Распространенная ошибка новичков — смотреть на serverStatus(), в то время как реальная подсказка находится в журналах за пределами MongoDB: ошибка аутентификации, проблема DNS, несоответствие TLS или истощение пула подключений приложения.

Знайте разницу между ролями базы данных и доступом к операционной системе

Пользователи MongoDB — это не пользователи Linux. Создание myAppUser в MongoDB не создает учетную запись оболочки. Предоставление кому-либо SSH-доступа к серверу базы данных не дает им автоматически разрешений базы данных, хотя может дать им опасный косвенный доступ, если сервер плохо настроен.

Держите эти уровни раздельно:

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

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

Более безопасная привычка для рабочих оболочек

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

db.runCommand({ connectionStatus: 1 })
db
db.hello()

connectionStatus показывает аутентифицированных пользователей и роли. db показывает контекст. hello дает информацию о топологии. Эти три проверки предотвращают удивительное количество ошибок.

Для рутинной проверки используйте учетную запись только для чтения. Переключайтесь на привилегированную учетную запись только для конкретного окна изменений. Это небольшое трение полезно. Оно заставляет вас замечать, когда вы собираетесь сделать что-то, что может изменить данные.

Когда остановиться и попросить помощи

Некоторые команды MongoDB дружественны к новичкам; некоторые — нет. Будьте осторожны с перенастройкой набора реплик, метаданными шардирования, принудительными перенастройками, завершением операций, сжатием коллекций и изменением настроек аутентификации в работающей системе. Эти действия могут повлиять на доступность.

Если команда изменяет топологию кластера или удаляет данные, сделайте паузу и получите второе мнение. Лучшие администраторы — не те, кто печатает быстрее всех. Они — те, кто знает, когда команда требует резервного копирования, окна обслуживания и еще одной пары глаз.

Понимание уровня чтения и уровня записи на высоком уровне

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

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

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

Будьте осторожны с примерами, скопированными из интернета

Синтаксис MongoDB менялся со временем. Старые сообщения в блогах могут использовать устаревшую оболочку mongo вместо mongosh, старые имена помощников или команды, которые все еще работают, но больше не предпочтительны. Некоторые примеры также выполняются с отключенной аутентификацией, что не является безопасным предположением для рабочей среды.

При копировании команды задайте три вопроса:

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

Если команда разрушительна, добавьте четвертый вопрос: как восстановиться, если что-то пойдет не так?

Используйте Compass и Atlas, не отказываясь от оболочки

Графические инструменты полезны. MongoDB Compass может помочь просмотреть документы, индексы и планы запросов. Atlas предоставляет мониторинг, резервное копирование, оповещения и управление пользователями для размещенных кластеров. Эти инструменты часто проще для визуальной проверки, чем вывод сырой оболочки.

Тем не менее, изучите команды оболочки. Во время инцидентов, автоматизации, сред, доступных только через SSH, или при проверке документации точная команда mongosh легче передается, чем "нажмите на третью вкладку в интерфейсе". Лучший рабочий процесс — не оболочка против GUI. Используйте GUI для исследования и оболочку для четкого выражения повторяемых действий.