Август 28th, 2018 
Evgeniy Kamenev Полезные команды MongoDB
Справка по всем командам
|
1 |
> help |
Просмотр списка баз данных
|
1 |
> show dbs |
|
1 2 3 4 |
admin 0.000GB config 0.000GB local 0.000GB mydatabase 0.059GB |
Выбор базы данных
|
1 |
> use mydatabase |
|
1 |
switched to db mydatabase |
Просмотр коллекций(таблиц) в выбранной базе данных
|
1 |
> show collections |
Либо
|
1 |
> db.getCollectionNames() |
Просомтр всех данных в таблице User
|
1 |
> db.Users.find() |
Подсчет кол-ва записей в коллекции
|
1 |
> db.Users.count() |
Просмотр размера коллекции
Просмотр существующих баз данных
|
1 |
rs0:PRIMARY> show dbs |
Выбор необходимой коллекции, раз мер которой хотим подсчитать
|
1 |
rs0:PRIMARY> use local |
Просмотр существующих коллекций(таблиц) базы даных local
|
1 |
rs0:PRIMARY> show collections |
|
1 2 3 4 5 6 7 8 |
me oplog.rs replset.election replset.minvalid replset.oplogTruncateAfterPoint startup_log system.replset system.rollback.id |
Общий размер коллекции состоит из размера данных,занимаемых на файловой системе и общего размера индексов и доступен по команде
|
1 |
db.<collection_name>.totalSize() |
Например, нас интересует коллекция oplog.rs
|
1 |
rs0:PRIMARY> db.oplog.rs.totalSize() |
|
1 |
594227200 |
Общий размер всех индексов коллекции
|
1 |
db.<collection_name>.totalIndexSize() |
|
1 |
rs0:PRIMARY> db.oplog.rs.totalIndexSize() |
|
1 |
0(ноль) |
По умолчанию движок wiredTiger также сжимает индексы
Размера коллекции в байтах занимаемого на диске
|
1 |
db.<collection_name>.storageSize() |
|
1 |
rs0:PRIMARY> db.oplog.rs.storageSize() |
|
1 |
594227200 |
Фактический размера коллекции в байтах
|
1 |
db.<collection_name>.dataSize() |
|
1 |
rs0:PRIMARY> db.oplog.rs.dataSize() |
|
1 |
1037354582 |
Размера коллекции в байтах занимаемого на диске меньше чем реальный размер т.к. движок wiredTiger сжимает данные
Также значение размера коллекции на файловой системе(значение параметра storageSize)
и фактического размера коллекции(значение параметра size) доступны по команде получения статистики коллекции
|
1 |
db.<collection_name>.stats() |
просмотр размера коллекции в байтах(поля «size» , «storageSize»)
|
1 |
rs0:PRIMARY> db.oplog.rs.stats() |
|
1 2 3 4 |
... "size" : 1037310531, "storageSize" : 594227200, ... |
просмотр размера коллекции в килобайтах(поля «size» , «storageSize»)
|
1 |
rs0:PRIMARY> db.oplog.rs.stats({ scale : 1024 }) |
|
1 2 3 4 |
... "size" : 1012998, "storageSize" : 580300, ... |
https://docs.mongodb.com/manual/reference/method/db.collection.totalSize
https://docs.mongodb.com/manual/reference/method/db.collection.totalIndexSize
https://docs.mongodb.com/manual/reference/method/db.collection.stats
https://docs.mongodb.com/manual/reference/method/db.collection.storageSize
Просмотр статики базы данных(предварительно ее нужно выбрать командой use )
|
1 |
> db.stats() |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
{ "db" : "mydatabase", "collections" : 35, "views" : 0, "objects" : 134598, "avgObjSize" : 2385.4557199958394, "dataSize" : 321077569, "storageSize" : 60346368, "numExtents" : 0, "indexes" : 53, "indexSize" : 3375104, "fsUsedSize" : 25176096768, "fsTotalSize" : 49080274944, "ok" : 1 } |
Ремонтирование базы данных(предварительно ее нужно выбрать командой use )
|
1 |
> db.repairDatabase() |
|
1 |
{ "ok" : 1 } |
Просмотр логов
|
1 |
> show logs |
|
1 2 |
global startupWarnings |
|
1 |
> show log global |
|
1 |
> show log startupWarnings |
|
1 |
# tail -f /var/log/mongodb/mongod.log |
Просмотр информации о сервере
|
1 |
> db.hostInfo() |
Удаление базы данных
|
1 |
> use mydatabase |
|
1 |
switched to db mydatabase |
|
1 |
> db.dropDatabase() |
|
1 |
{ "dropped" : "mydatabase", "ok" : 1 } |
Удаление пользователя
|
1 |
> use mydb |
|
1 |
>db.dropUser("username") |
Полная расширенная информация о состоянии MongoDB
|
1 |
> db.serverStatus() |
Больше команд доступно по команде
|
1 |
>db.help() |
Оптимизация производительности
Необходимо, чтобы как MongoDB-индексы, так и MongoDB Working Set(данные/полезная информация) максимально размещались в ОЗУ
Просмотр размера индексов и размера данных(data) базы данных
|
1 |
> use mydatabase |
|
1 |
switched to db mydatabase |
|
1 |
> db.stats() |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
{ "db" : "mydatabase", "collections" : 36, "views" : 0, "objects" : 134598, "avgObjSize" : 2385.4557199958394, "dataSize" : 321077569, "storageSize" : 60350464, "numExtents" : 0, "indexes" : 53, "indexSize" : 3375104, "fsUsedSize" : 25176158208, "fsTotalSize" : 49080274944, "ok" : 1 } |
Просмотр состояния кеша движка WiredTiger
|
1 |
> db.serverStatus().wiredTiger.cache |
Просмотр маскимально допустимого размера ОЗУ,который может использовться движком WiredTiger под кеш
|
1 |
# echo "db.serverStatus().wiredTiger.cache" | mongo | grep "maximum bytes configured" |
|
1 |
"maximum bytes configured" : 268435456, |
По умолчанию должно использоваться 50% установленной на сервере ОЗУ
By default, WiredTiger uses 50% of RAM (minus 1 GB) or 256 MB for its
internal cache.
|
1 |
# free -m |
|
1 2 |
total used free shared buff/cache available Mem: 512 311 114 10 86 114 |
|
1 2 |
This parameter can be changed by setting the wiredTiger.engineConfig.cacheSizeGB parameter in the MongoDB configuration file, or by setting wiredTigerEngineRuntimeConfig |
Просмотр реально используемого размера ОЗУ под кеш
|
1 |
# echo "db.serverStatus().wiredTiger.cache" | mongo | grep "bytes currently in the cache" |
|
1 |
"bytes currently in the cache" : 209425130, |
Если размер используемого кеша приближается к максимально допустимому, то есть смысл увеличить размер максимально допустимого кеша.
Более того, важно следить за параметром
|
1 |
"tracked dirty bytes in the cache" |
Если его значение постоянно увеличивается, следует изменить размер кеша
|
1 |
# echo "db.serverStatus().wiredTiger.cache" | mongo | grep "tracked dirty" |
|
1 2 |
"tracked dirty bytes in the cache" : 0, "tracked dirty pages in the cache" : 0, |
Вот простое правило
|
1 |
tracked dirty bytes in the cache configured < bytes currently in the cache < maximum bytes |
Оптимизация 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 добавить вызов команд
|
1 2 |
echo 'never' >> /sys/kernel/mm/transparent_hugepage/enabled echo 'never' >> /sys/kernel/mm/transparent_hugepage/defrag |
4.Проверить/установить лиимты
|
1 |
# ulimit -a |
Рекомендации по лимитам
|
1 2 3 4 5 6 |
• -f (file size): unlimited • -t (cpu time): unlimited • -v (virtual memory): unlimited • -n (open files): 64000 • -m (memory size): unlimited • -u (processes/threads): 64000 |
http://docs.mongodb.org/manual/reference/ulimit/#recommended-settings
Бекап/восстановление MongoDB баз данных/коллекций средствами mongodump/mongorestore
|
1 2 3 4 5 6 7 8 9 |
The mongodump utility primarily connects to the mongod or mongos instance and dumps all data (except the local database) in BSON format. By default, if no parameters are specified to the utility, mongodump creates a directory called dump in the current working directory. Additionally, for every database on the server, it creates a subdirectory with the name of the database and, within this subdirectory, it creates a BSON file for every collection within the database. In addition to BSON files, mongodump also creates metadata files corresponding to the collection(json-files) |
Бекап всех баз данных без сжатия
|
1 |
# mkdir /root/backup |
|
1 |
# mongodump --out /root/backup |
Восстановление с такого бекапа
|
1 |
# mongorestore --drop --dir /root/backup |
Параметр —drop используется для удаления коллекции перед импортом(если она существует),во избежания ошибки duplicate key errors
Этот параметр —drop следует применять с осторожностью
Также перед фактическим восстановлением с бекапа можно выполнить команду для проверки восстановления с бекапа без его реального восстановления( т. н. Режим dryrun)
|
1 |
# mongorestore --dryRun -vvv --dir /root/backup |
Восстановление определенной коллекции(например, коллекции mycollectionname в базе данных mydb) с бекапа всех баз данных
|
1 |
# mongodump --out /root/backup |
|
1 |
# mongorestore --drop -v --dir /root/backup --nsInclude 'mydb.mycollectionname' |
Восстановление всех баз данных и всех коллекций, за исключением определенной коллекции(например, коллекции mycollectionname в базе mydb)
|
1 |
# mongorestore --drop -v --dir /root/backup --nsExclude 'mydb.mycollectionname' |
|
1 2 3 |
Namespaces can contain wildcards as well, for example, you can use the mydb.m* namespace to restore all collections within the mydb database that start with the letter m . |
Бекап всех баз данных с сжатием
|
1 |
# mongodump --gzip --out /root/backup |
Восстановление с такого бекапа
|
1 |
# mongorestore --gzip --drop --dir /root/backup |
Бекап всех баз данных с сжатем в один архив(.gz)
|
1 |
# mongodump --gzip --archive=/root/backup/mybackup.gz |
Восстановление с такого бекапа
|
1 |
# mongorestore --gzip --drop --archive=/root/backup/mybackup.gz |
Бекап определенной базы данных
|
1 |
# mongodump --gzip -d mydb |
Бекап одной коллекции из базы данных
|
1 |
# mongodump --gzip -d mydb -c mycollection |
|
1 |
# ls -l dump/mydb/ |
|
1 2 3 |
total 8 -rw-r--r-- 1 root root 1486 Aug 21 19:41 mycollection.bson.gz -rw-r--r-- 1 root root 142 Aug 21 19:41 mycollection.metadata.json.gz |
Просмотр содержимого bson-файла
|
1 |
# zcat dump/mydb/mycollection.bson.gz | bsondump --pretty |
Опция —pretty выводит в удобном/форматируемом JSON-виде
Эту опцию можно не использовать, например, в скриптах.
Бекап всей базы за исключением одной коллекции
|
1 |
# mongodump --gzip -d mydb --excludeCollection=mycollection |
Создание новой Replica Set из бекапа MongoDB
1.На текущем запущенном сервере выполняем инициализацию реплики
|
1 |
rs.initiate() |
2.Восстанавливаем данные с бекапа
|
1 |
# mongorestore --dir /root/backup |
3.Выключаем первую ноду
|
1 |
use admin |
|
1 |
db.shutdownServer({force: true}) |
4.Копируем данные с первой ноды на все secondary-ноды( вторая и третья,например)
|
1 |
# scp -r /var/lib/mongodb/* node02.mydomain.com:/var/lib/mongodb/ |
|
1 |
# scp -r /var/lib/mongodb/* node03.mydomain.com:/var/lib/mongodb/ |
|
1 |
# chown -R mongodb:mongodb /var/lib/mongodb/ |
5.Запускаем mongodb-службу на всех трех серверах
6.На первичном(мастере) выполняем добавление остальных нод в репликацию
|
1 |
rs.add('192.168.1.10:27017') |
|
1 |
rs.add('192.168.1.11:27017') |
7.Проверяем состояние репликации
|
1 |
rs.status() |
|
1 2 3 4 5 6 7 8 9 |
Clearly, this is an overly simplified example of how to create a replica set from an existing backup. An alternate method would be to restore the backup on a single node, start the secondary nodes with no data in them, and simply add them to the replica set using the rs.add() command. As this method initiates an on-the-fly sync of data between the nodes, you should add the nodes one by one. In a production environment, if the dataset is too large, it is rather preferred to do an initial sync using the data files and then let the nodes catch up with the primary node, once they are added. |
Бекап point in time replicate set
|
1 |
# mongodump --oplog --out /backups/dump/ |
|
1 |
# ls -al /backups/dump/ |
|
1 2 3 |
drwxr-xr-x 2 root root 4096 Oct 4 14:37 admin drwxr-xr-x 2 root root 4096 Oct 4 14:37 mydb -rw-r--r-- 1 root root 106333 Oct 4 15:02 oplog.bson |
Просмотр содержимое Oplog.bson-файла
|
1 |
# bsondump /backups/dump/oplog.bson |
При восстановлении с такого бекапа(который содержит oplog) в утилите mongorestore добавляем опцию —oplogReplay
Мониторинг MongoDB
|
1 |
# mongostat |
|
1 2 3 4 5 |
insert query update delete getmore command dirty used flushes vsize res qrw arw net_in net_out conn time *0 *0 *0 *0 0 2|0 0.0% 78.0% 0 1.20G 316M 0|0 1|0 160b 61.1k 1 Aug 27 17:29:09.958 *0 *0 *0 *0 0 2|0 0.0% 78.0% 0 1.20G 316M 0|0 1|0 158b 60.4k 1 Aug 27 17:29:10.953 *0 *0 *0 *0 0 1|0 0.0% 78.0% 0 1.20G 316M 0|0 1|0 156b 59.3k 1 Aug 27 17:29:11.965 …… |
По умолчанию статистика собирается/обновляется ежесекундно и выводится на стандартный вывод
Описание всех выводимых утилитой полей и поддержка дополнительных опций доступны через
|
1 |
# man mongostat |
Также можно мониторить все ноды в ReplicaSet
|
1 |
# mongostat --discover |
|
1 2 3 4 |
host insert query update delete getmore command dirty used flushes vsize res qrw arw net_in net_out conn set repl time db01:27017 *0 *0 *0 *0 0 5|0 0.2% 45.9% 0 3.05G 1.69G 0|0 1|0 370b 123k 23 rs0 SEC Aug 27 18:31:04.979 db02:27017 *0 *0 *0 *0 0 1|0 0.4% 50.2% 0 3.34G 1.85G 0|0 1|0 157b 61.3k 26 rs0 PRI Aug 27 18:31:04.980 localhost:27017 *0 *0 *0 *0 0 5|0 0.2% 45.9% 0 3.05G 1.69G 0|0 1|0 717b 124k 23 rs0 SEC Aug 27 18:31:05.975 |
В формате JSON
|
1 |
# mongostat -n 1 --json | python -m json.tool |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
{ "localhost:27017": { "arw": "1|0", "command": "4|0", "conn": "22", "delete": "*0", "dirty": "0.4%", "flushes": "0", "getmore": "0", "insert": "*0", "net_in": "560b", "net_out": "62.4k", "qrw": "0|0", "query": "*0", "repl": "SEC", "res": "1.69G", "set": "rs0", "time": "18:31:58", "update": "*0", "used": "45.9%", "vsize": "3.05G" } } |
Просмотр всех текущих операций/запросов
|
1 |
> db.currentOp() |
Каждая операция имеет свой уникальный идентификатор opid, который может быть использоваться для завершения данной операции с помощью команды db.killOP()
db.currentOp поддерживает разные опции при формировании запроса на поиск текущих соединений.
Например, найти все UPDATE-запросы выполняющиеся дольше 1 секунды в базе данных mydb
|
1 2 3 4 5 6 |
db.currentOp({ "active" : true, "secs_running" : { "$gt" : 1 }, "op": "update", "ns": /^mydb\./ }) |
Больше опций доступно из документации
https://docs.mongodb.com/manual/reference/method/db.currentOp/
Мониторинг/проверка дисковой подсистемы используемой MongoDB
|
1 |
# echo "db.serverStatus()" | mongo > /root/mongo-status.txt |
|
1 |
extra_info. page_faults |
– общее кол-во page faults в системе.
Если происходит увеличение этого кол-ва,то, возможно, оперативной памяти недостаточно, удерживать все данные(working set) в памяти и эти данные сбрасываются на диск
|
1 |
# echo "db.serverStatus()" | mongo | grep page_faults |
|
1 |
"page_faults" : 1 |
|
1 |
wiredTiger.cache.bytes currently in the cache |
– текущее использование памяти под WiredTiger кеш
|
1 |
# echo "db.serverStatus()" | mongo | grep 'bytes currently in the cache' |
|
1 |
"bytes currently in the cache" : 1900465252, |
В идеале он никогда не должен достигать максимального значения доступного кеша, который можно просмотреть командой
|
1 |
# echo "db.serverStatus().wiredTiger.cache" | mongo | grep 'maximum bytes' |
|
1 |
"maximum bytes configured" : 3758096384, |
|
1 2 |
wiredTiger.cache.pages read into cache wiredTiger.cache.pages written from cache |
Кол-во страниц прочитанных из диска и помещенных в кеш и кол-во страниц записанных/сохраненных на диске из кеша
|
1 |
# echo "db.serverStatus()" | mongo | grep -E '"pages read into cache"|"pages written from cache"' |
|
1 2 |
"pages read into cache" : 64261, "pages written from cache" : 40663, |
Высокая флюктуация этих метрик свидетельствует об интенсивном использовании дисковой подсистемы ввода/вывода
Также одним из лучших утилит для мониторинга использования дисковой подсистемы ввода/выводя является iostat
Например,
|
1 |
# iostat -k -x 1 |
Профилирование в MongoDB
Просмотр включено ли профилирование запросов(по умолчанию отключено)
Значение поле was определяет,включено ли профилирование
|
1 2 3 |
0 – отключено 1 - логирование медленных запросов 2 - логирование медленных операций |
Запросы/операции,которые выполняются дольше значения параметра slowms записываются профилятором
|
1 |
> db.getProfilingStatus() |
|
1 |
{ "was" : 0, "slowms" : 100, "sampleRate" : 1 } |
Например, включить профилирование только запросов длительностью выполнения от 20мс
|
1 |
> db.setProfilingLevel(1, 20) |
|
1 |
{ "was" : 0, "slowms" : 100, "sampleRate" : 1, "ok" : 1 } |
|
1 |
> db.getProfilingStatus() |
|
1 |
{ "was" : 1, "slowms" : 20, "sampleRate" : 1 } |
После чего можно просмотреть профилируемою коллекцию – т.е. просмотреть все запросы, записанные профилятором
|
1 |
> db.system.profile.find().pretty() |
Отключение профилирования
|
1 |
> db.setProfilingLevel(0) |
|
1 |
{ "was" : 1, "slowms" : 20, "sampleRate" : 1, "ok" : 1 } |
Аутентификация и безопасность в MongoDB
Все пользователи и все роли в MongoDB сохраняются в базе данных admin в коллекции
System.users и system.roles соответственно
Предоставим роль root пользователю mysuperuser на базу данных admin
Роль root является самой высшей ролью с максимальным набором полномочий
Предоставляя роль root на базу данных admin мы наделяем пользователя mysuperuser административными привилегиями на управление всеми пользователями,базами данных,бекап/восстановление,управление кластером и т.д.
|
1 2 3 4 5 6 7 |
> db.createUser( { user: "mysuperuser", pwd: "mysuperpassword", roles: [{role: "root", db: "admin"}] } ) |
|
1 2 3 4 5 6 7 8 9 |
Successfully added user: { "user" : "mysuperuser", "roles" : [ { "role" : "root", "db" : "admin" } ] } |
Включаем/активируем поддержку аутентифкиации в MongoDB
|
1 |
# cp /etc/mongod.conf /etc/mongod.conf~ |
|
1 |
# nano /etc/mongod.conf |
|
1 2 |
security: authorization: enabled |
|
1 |
# systemctl restart mongod |
Проверяем,что без аутентификации доступ запрещен
|
1 |
# mongo |
|
1 2 3 |
MongoDB shell version v3.6.7 connecting to: mongodb://127.0.0.1:27017 MongoDB server version: 3.6.7 |
|
1 |
> show dbs |
|
1 2 3 4 5 6 7 8 9 10 11 |
2018-08-26T15:36:36.692+0000 E QUERY [thread1] Error: listDatabases failed:{ "ok" : 0, "errmsg" : "not authorized on admin to execute command { listDatabases: 1.0, $db: \"admin\" }", "code" : 13, "codeName" : "Unauthorized" } : _getErrorWithCode@src/mongo/shell/utils.js:25:13 Mongo.prototype.getDBs@src/mongo/shell/mongo.js:65:1 shellHelper.show@src/mongo/shell/utils.js:849:19 shellHelper@src/mongo/shell/utils.js:739:15 @(shellhelp2):1:1 |
Аутентифицируемся
|
1 |
> use admin |
|
1 |
switched to db admin |
Если аутентификация прошла успешно,то команды вернет значение 1
|
1 |
> db.auth("mysuperuser", "mysuperpassword" ) |
|
1 |
1 |
|
1 |
> show dbs |
|
1 2 3 4 |
admin 0.000GB config 0.000GB local 0.000GB mydatabase 0.059GB |
Аутентификация с командной строки
|
1 |
# mongo -u "mysuperuser" -p "mysuperpassword" --authenticationDatabase "admin" |
Добавим пользователя myuser с паролем mypassword с ролью чтение/запись на базу данных mydatabase
Для этого аутентифицируемся как суперпользователь mysuperuser
|
1 |
# mongo -u "mysuperuser" -p "mysuperpassword" --authenticationDatabase "admin" |
Переключимся на нужную базу
|
1 |
> use mydatabase |
|
1 |
switched to db mydatabase |
|
1 2 3 4 5 6 7 |
> db.createUser( { user: "myuser", pwd: "mypassword", roles: [{role: "readWrite", db: "mydatabase"}] } ) |
|
1 2 3 4 5 6 7 8 9 |
Successfully added user: { "user" : "myuser", "roles" : [ { "role" : "readWrite", "db" : "mydatabase" } ] } |
Проверка пользователей и ролей,подключенных к этим пользователям
|
1 |
> db.getUsers() |
|
1 |
> use mydatabase |
|
1 |
switched to db mydatabase |
|
1 |
> db.getUsers() |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[ { "_id" : "mydatabase.myuser", "user" : "myuser", "db" : "mydatabase", "roles" : [ { "role" : "readWrite", "db" : "mydatabase" } ] } ] |
|
1 |
> use admin |
|
1 |
switched to db admin |
|
1 |
> db.getUsers() |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
[ { "_id" : "admin.mysuperuser", "user" : "mysuperuser", "db" : "admin", "roles" : [ { "role" : "root", "db" : "admin" } ] } ] |
Просмотр пользователей, назначенных им ролей в коллекции db.system.users в базе данных admin
|
1 |
> use admin |
|
1 |
switched to db admin |
|
1 |
> db.system.users.find() |
|
1 2 |
{ "_id" : "admin.mysuperuser", "user" : "mysuperuser", "db" : "admin", "credentials" : { "SCRAM-SHA-1" : { "iterationCount" : 10000, "salt" : "6340+0Hh9fGmxEuCPvGyOw==", "storedKey" : "UzWUH2Iy+YV6V1gry//RtLlV30E=", "serverKey" : "SDqQFdQ606NlkKr19fcFdHlHYBo=" } }, "roles" : [ { "role" : "root", "db" : "admin" } ] } { "_id" : "mydatabase.myuser", "user" : "myuser", "db" : "mydatabase", "credentials" : { "SCRAM-SHA-1" : { "iterationCount" : 10000, "salt" : "TBzBshwgLrPq5IucmLsh+w==", "storedKey" : "g7C6BBX6fBbLNf6Vn5K7IFbXJHE=", "serverKey" : "Zbh+NGMndfNG87GTVzLBx13mW0s=" } }, "roles" : [ { "role" : "readWrite", "db" : "mydatabase" } ] } |
Просмотр информации о пользователе, списке ролей назначенных пользователю(пользователь должен существовать в этой базе, в которой выполняется команда db.getUser)
|
1 |
# mongo -u "myuser" -p "mypassword" --authenticationDatabase "mydatabase" |
|
1 |
> use mydatabase |
|
1 |
switched to db mydatabase |
|
1 |
> db.getUser("myuser") |
|
1 2 3 4 5 6 7 8 9 10 11 |
{ "_id" : "mydatabase.myuser", "user" : "myuser", "db" : "mydatabase", "roles" : [ { "role" : "readWrite", "db" : "mydatabase" } ] } |
Обнуление пароля суперпользователя в MongoDB
1.Отключаем аутентификацию в MongoDB
|
1 |
# nano /etc/mongod.conf |
|
1 2 |
#security: # authorization: enabled |
|
1 |
# systemctl restart mongod |
2.Переключаем на базу admin
|
1 |
> use admin |
|
1 |
switched to db admin |
и выполняем команду для поиска пользователей, которые имеют назначенную роль root
|
1 |
> db.system.users.find({'roles.role': "root"}) |
|
1 |
{ "_id" : "admin.mysuperuser", "user" : "mysuperuser", "db" : "admin", "credentials" : { "SCRAM-SHA-1" : { "iterationCount" : 10000, "salt" : "6340+0Hh9fGmxEuCPvGyOw==", "storedKey" : "UzWUH2Iy+YV6V1gry//RtLlV30E=", "serverKey" : "SDqQFdQ606NlkKr19fcFdHlHYBo=" } }, "roles" : [ { "role" : "root", "db" : "admin" } ] } |
3.Изменяем пароль пользователя mysuperuser
|
1 |
> db.changeUserPassword("mysuperuser", "mynewpassword") |
4.Включаем аутентификацию в MongoDB
|
1 |
# nano /etc/mongod.conf |
|
1 2 |
security: authorization: enabled |
|
1 |
# systemctl restart mongod |
5. Проверяем корректный доступ
|
1 |
# mongo -u "mysuperuser" -p "mynewpassword" --authenticationDatabase "admin" |
Для изменения пароля обычного пользователя достаточно выполнить команду без остановки mongod-службы
|
1 |
> db.changeUserPassword("myuser", "mynewpassword") |
Источник:
Книга MongoDB Administrator’s Guide by Cyrus Dasadia
Опубликовано в рубрике 
Метки: