MongoDB-полезные команды для бекапа,мониторинга,оптимизации производительности и безопасности

Полезные команды MongoDB

Справка по всем командам

 

Просмотр списка баз данных

 

Выбор базы данных

 

Просмотр коллекций(таблиц) в выбранной базе данных

Либо

 

Просомтр всех данных в таблице User

 

Подсчет кол-ва записей в коллекции

 

Просмотр статики базы данных(предварительно ее нужно выбрать командой use )

 

Ремонтирование базы данных(предварительно ее нужно выбрать командой use )

 

Просмотр логов

 

Просмотр информации о сервере

 

Удаление базы данных

 

Удаление пользователя

 

Полная расширенная информация о состоянии MongoDB

Больше команд доступно по команде

 

Оптимизация производительности
Необходимо, чтобы как MongoDB-индексы, так и MongoDB Working Set(данные/полезная информация) максимально размещались в ОЗУ

Просмотр размера индексов и размера данных(data) базы данных

 

Просмотр состояния кеша движка WiredTiger

 

Просмотр маскимально допустимого размера ОЗУ,который может использовться движком WiredTiger под кеш

По умолчанию должно использоваться 50% установленной на сервере ОЗУ
By default, WiredTiger uses 50% of RAM (minus 1 GB) or 256 MB for its
internal cache.

 

Просмотр реально используемого размера ОЗУ под кеш

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

 

Более того, важно следить за параметром

Если его значение постоянно увеличивается, следует изменить размер кеша

Вот простое правило

 

Оптимизация MongoDB-прооизводительности

1.Использовать XFS-файловую систему вместо Ext4, особенно если используется движок WiredTiger(XFS использует параллельный дисковый ввод/вывод,что значительно улучшает производительность по сравнеию с EXT4)
http://dochub.mongodb.org/core/prodnotes-filesystem
2. Использовать SSD-диски вместо HDD
3.Отключить Transparent Huge Page(THP) Для отключения THP В Unit-файл/init-скрипт MongoDB добавить вызов команд

4.Проверить/установить лиимты

Рекомендации по лимитам

http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings

 

Бекап/восстановление MongoDB баз данных/коллекций средствами mongodump/mongorestore

 

Бекап всех баз данных без сжатия

 

Восстановление с такого бекапа

Параметр —drop используется для удаления коллекции перед импортом(если она существует),во избежания ошибки duplicate key errors
Этот параметр —drop следует применять с осторожностью

Также перед фактическим восстановлением с бекапа можно выполнить команду для проверки восстановления с бекапа без его реального восстановления( т. н. Режим dryrun)

 

Восстановление определенной коллекции(например, коллекции mycollectionname в базе данных mydb) с бекапа всех баз данных

Восстановление всех баз данных и всех коллекций, за исключением определенной коллекции(например, коллекции mycollectionname в базе mydb)

 

Бекап всех баз данных с сжатием

Восстановление с такого бекапа

 

Бекап всех баз данных с сжатем в один архив(.gz)

Восстановление с такого бекапа

 

Бекап определенной базы данных

Бекап одной коллекции из базы данных

Просмотр содержимого bson-файла

Опция —pretty выводит в удобном/форматируемом JSON-виде
Эту опцию можно не использовать, например, в скриптах.

 

Бекап всей базы за исключением одной коллекции

 

Создание новой Replica Set из бекапа MongoDB
1.На текущем запущенном сервере выполняем инициализацию реплики

2.Восстанавливаем данные с бекапа

3.Выключаем первую ноду

4.Копируем данные с первой ноды на все secondary-ноды( вторая и третья,например)

5.Запускаем mongodb-службу на всех трех серверах
6.На первичном(мастере) выполняем добавление остальных нод в репликацию

7.Проверяем состояние репликации

 

Бекап point in time replicate set

Просмотр содержимое Oplog.bson-файла

При восстановлении с такого бекапа(который содержит oplog) в утилите mongorestore добавляем опцию —oplogReplay

 

Мониторинг MongoDB

По умолчанию статистика собирается/обновляется ежесекундно и выводится на стандартный вывод

Описание всех выводимых утилитой полей и поддержка дополнительных опций доступны через

Также можно мониторить все ноды в ReplicaSet

В формате JSON

Просмотр всех текущих операций/запросов

Каждая операция имеет свой уникальный идентификатор opid, который может быть использоваться для завершения данной операции с помощью команды db.killOP()

db.currentOp поддерживает разные опции при формировании запроса на поиск текущих соединений.
Например, найти все UPDATE-запросы выполняющиеся дольше 1 секунды в базе данных mydb

Больше опций доступно из документации
https://docs.mongodb.com/manual/reference/method/db.currentOp/

 

Мониторинг/проверка дисковой подсистемы используемой MongoDB

 

– общее кол-во page faults в системе.
Если происходит увеличение этого кол-ва,то, возможно, оперативной памяти недостаточно, удерживать все данные(working set) в памяти и эти данные сбрасываются на диск

 

– текущее использование памяти под WiredTiger кеш

В идеале он никогда не должен достигать максимального значения доступного кеша, который можно просмотреть командой

 

Кол-во страниц прочитанных из диска и помещенных в кеш и кол-во страниц записанных/сохраненных на диске из кеша

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

Также одним из лучших утилит для мониторинга использования дисковой подсистемы ввода/выводя является iostat
Например,

 

Профилирование в MongoDB
Просмотр включено ли профилирование запросов(по умолчанию отключено)
Значение поле was определяет,включено ли профилирование

Запросы/операции,которые выполняются дольше значения параметра slowms записываются профилятором

Например, включить профилирование только запросов длительностью выполнения от 20мс

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

Отключение профилирования

 

Аутентификация и безопасность в MongoDB

Все пользователи и все роли в MongoDB сохраняются в базе данных admin в коллекции
System.users и system.roles соответственно

Предоставим роль root пользователю mysuperuser на базу данных admin
Роль root является самой высшей ролью с максимальным набором полномочий
Предоставляя роль root на базу данных admin мы наделяем пользователя mysuperuser административными привилегиями на управление всеми пользователями,базами данных,бекап/восстановление,управление кластером и т.д.

Включаем/активируем поддержку аутентифкиации в MongoDB

Проверяем,что без аутентификации доступ запрещен

Аутентифицируемся

Если аутентификация прошла успешно,то команды вернет значение 1

Аутентификация с командной строки

Добавим пользователя myuser с паролем mypassword с ролью чтение/запись на базу данных mydatabase
Для этого аутентифицируемся как суперпользователь mysuperuser

Переключимся на нужную базу

Проверка пользователей и ролей,подключенных к этим пользователям

 

 

Просмотр пользователей, назначенных им ролей в коллекции db.system.users в базе данных admin

Просмотр информации о пользователе, списке ролей назначенных пользователю(пользователь должен существовать в этой базе, в которой выполняется команда db.getUser)

Обнуление пароля суперпользователя в MongoDB
1.Отключаем аутентификацию в MongoDB

2.Переключаем на базу admin

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

3.Изменяем пароль пользователя mysuperuser

4.Включаем аутентификацию в MongoDB

5. Проверяем корректный доступ

Для изменения пароля обычного пользователя достаточно выполнить команду без остановки mongod-службы

 

Источник:
Книга MongoDB Administrator’s Guide by Cyrus Dasadia

Комментирование и размещение ссылок запрещено.

Комментарии закрыты.

Яндекс.Метрика