11
декабря
4

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



Mongo — это специальная объектно-ориентированная база данных или хранилище структурированных данных, что-то среднее между привычной реляционной СУБД и key-value хранилищем. Хранение данных происходит в виде JSON-подобных документов (document-based). Без особых трудностей mongod может работать с базой, насчитывающей несколько миллионов объектов. Имеется поддержка динамических запросов, индексов, профилирование запросов, репликация и поддержка fail-over.
MongoDB целесообразно использовать для хранения постоянно изменяющихся данных для сайта,т.е. гибкой работы с информацией в реальном времени, а также, отлично справляется с задачами кэширования.

Комплект поставки и запуск

После установки программы на FreeBSD имеем следующие исполняемые файлы:

cat /var/db/pkg/mongodb-1.6.2/+CONTENTS | grep "^bin/"
bin/mongo
bin/mongod
bin/mongodump
bin/mongoexport
bin/mongofiles
bin/mongoimport
bin/mongorestore
bin/mongos
bin/mongosniff
bin/mongostat 

а также устанавливается rc-скрипт etc/rc.d/mongod для управления сервисом, где можно найти достаточно полезную информацию, как на мой взгляд:

name="mongod"
command=/usr/local/bin/${name}
command_args="-f $mongod_config --dbpath $mongod_dbpath --logappend
--logpath $mongod_dbpath/mongod.log --fork" 

Там же и описано какие строки можно прописать в /etc/rc.conf для включения сервиса и работы с определенными параметрами, если настройки по умолчанию чем-то не устраивают:
mongod_enable=’NO’ — запускать ли демон при старте системы;
mongod_config=»/usr/local/etc/mongodb.conf» — какой файл с конфигурацией будет считываться при старте демона;
mongod_dbpath=»/var/db/mongodb» — место расположения баз данных;
mongod_user=»mongodb» — от какого пользователя будет работать mongod;
также дополнительно можно прописать mongod_flags, которые равноценны настройкам в $mongod_config.
Параметр —fork при запуске MongoDB указывается чтобы процесс запустился как нормальный демон, после ключа -f идет какой файл конфигурации использовать,
—logappend —logpath — писать лог работы в файл и где он находится. Кроме параметров в коммандной строке также используется конфигурационный файл. Например, в rc.conf можно указать:

mongod_flags="--master --nohttpinterface --cpu --verbose" 

или то же самое в mongodb.conf:

master = true
cpu = true
verbose=true
nohttpinterface = true 

где:
master — используется при репликации;
cpu — периодически пишет в лог использование CPU и I/O wait;
verbose — подробнее запись в лог;
nohttpinterface — отключить HTTP интерфейс.
Также полезными могут быть: bind_ip = 127.0.0.1, noauth = true — не использовать аутентификацию при доступе к БД.

Как разобрались выше, обслуживающим подключения процессом выступает mongod:

ps auxww | grep mongod | grep -v grep
mongodb 15381  4.9  2.5 97484 25748  ??  S    10:53PM   0:00.03
/usr/local/bin/mongod --master --nohttpinterface --cpu --verbose
-f /usr/local/etc/mongodb.conf --dbpath /var/db/mongodb
--logappend --logpath /var/db/mongodb/mongod.log --fork 

Управление и диагностика

В комплекте поставки содержится, как и в СУБД mysqld, интерактивный shell — bin/mongo, с помощью которого можно выполнять административные функции, которыми из самых полезных, можно считать:
help — посмотреть справку;
db.help() — получить справку по db methods;
db.commandHelp(«ismaster») — справка по определенной команде (здесь «ismaster»);
show dbs — список существующих БД;
show tables / show collections — список таблиц/коллекций текущей базы;
show users — список пользователей в текущей БД;
use <db name> — сделать текущей БД <db name>;
db.getName() / db — посмотреть текущую БД;
db.version() — вывести версию программы;
db.getMongo() — список текущих подключений;

управления пользователями:
db.addUser (username, password) — добавить;
db.removeUser(username) — удалить;

копирования БД с одного сервера на другой и удаления БД:
db.cloneDatabase(fromhost)
db.copyDatabase(fromdb, todb, fromhost)

или в другом формате:
db.runCommand( { copydb : 1, fromdb : …, todb : …, fromhost : … } );
db.dropDatabase()

работа с текущими операциями:
db.currentOp() — показать в текущей БД;
db.killOp() — убить текущую операцию в базе;

диагностические команды состояния и репликации:
db.printCollectionStats()
db.stats()
db.serverStatus()
db.getReplicationInfo()
db.printReplicationInfo()
db.printSlaveReplicationInfo()
db.isMaster()

управление сервером:
db.repairDatabase() — восстановление базы после краха;
db.shutdownServer() — остановить сервер БД.

Нужно учесть, что некоторые административные операции можно выполнить только когда текущей базой является «admin», к примеру, db.runCommand(«shutdown»). Либо, не переходя в эту базу, можно использовать команды _adminCommand, например, db._adminCommand(«shutdown»).
За состоянием сервера можно также следить с помощью утилиты mongostat, которая в реальном времени выводит статистику для работающего демона:

mongostat -v -d test 1
Sat Dec 11 00:37:56 creating new connection to:127.0.0.1
connected to: 127.0.0.1
insert/s query/s update/s delete/s getmore/s command/s flushes/s locked % idx miss %    q t|r|w  conn       time
0       0        0        0         0         1         0        0          0      0|0|0     1   00:37:57
0       0        0        0         0         1         0        0          0      0|0|0     1   00:37:58
0       0        0        0         0         1         0        0          0      0|0|0     1   00:37:59 

-v — более информативный вывод;
-d — какая база данных используется;
число в конце — это время между вызовами.

Как показывает справка mongostat —help мы видим перед собой:

Fields
inserts/s    - # of inserts per second
query/s      - # of queries per second
update/s     - # of updates per second
delete/s     - # of deletes per second
getmore/s    - # of get mores (cursor batch) per second
command/s    - # of commands per second
flushes/s    - # of fsync flushes per second
mapped       - # amount of data mmaped (total data size) megabytes
visze        - # virtual size of process in megabytes
res          - # resident size of process in megabytes
faults/s     - # of pages faults/sec (linux only)
locked       - # percent of time in global write lock
idx miss     - # percent of btree page misses (sampled)
q t|r|w      - # lock queue lengths (total|read|write)
conn         - # number of open connections 

Резервирование (backup)

Как и при использовании любой СУБД, нужно периодически делать резервные копии имеющихся данных, как и настроек и данных других сервисов. Не хотелось бы оказаться на месте тех системных администраторов, которые ЕЩЕ не делают бекап или УЖЕ делают бекап, т.е. в момент перехода между этими двумя состояниями.
Есть несколько способов достичь желаемого:

Fsync, Write Lock and Backup
Подразумевает под собой очистку всех записей, блокирования для предотвращения записей в последующем времени и затем бекапа файлов данных. Естественно, когда установлен режим блокирования, никакие записи не происходят, что может достаточно негативно повлиять на работу сервиса, который использует mongodb. Как управлять блокированием для снятия snapshots:

> use admin
switched to db admin
> db.runCommand({fsync:1,lock:1});
{  "info" : "now locked against writes,
use db.$cmd.sys.unlock.findOne() to unlock", "ok" : 1  }
> db.$cmd.sys.unlock.findOne()
{ "ok" : 1, "info" : "unlock requested" }
> db.currentOp() 

Shutdown and Backup
Простой метод, подразумевающий под собой остановку СУБД на некоторое время.

/usr/local/etc/rc.d/mongod stop
cp /var/db/mongodb/bd.*
/var/db/mongodb/bd 

Exports
Среди установленных утилит можно найти mongodump, которая снимает дамп на работающей системе, наподобие mysqldump в mysqld. При запуске без аргументов mongodump в текущей директории создает каталог dump и подкаталоги с названиями баз данных, в которых и будет находиться дамп.

Полезными ключами могут послужить:
-d <db name> — какую БД бекапить;
-o <out_dir> — в какую директорию сохранять.

Для заливки дампа на сервер используется mongorestore, которой обычно будет достаточно задать какую БД использовать и указать файл или директорию, которые нужно восстановить с бекапа (подробнее # mongorestore —help).

Целесообразно будет поднять репликацию и делать резервные копии со Slave-сервера, потому как тогда кроме того, что всегда будет бекапный сервер готовый, в случае падения master-а, стать основным (failover), но и будет доступно получение дампа без последствий на работу и производительность сервиса. Более детально про Master-Slave репликацию Mongodb описано в следующей статье.

Логирование

По умолчанию MongoDB сообщения своей работы выводит на стандартный вывод, т.е. экран. С помощью параметра —logpath <file> указывается в какой файл будут писаться эти сообщения, а —quiet или -v — задается меньший или больший уровень информативности.
Для ротации логов нужно самостоятельно посылать сингал -SIGUSR1 процессу mongod:

killall -SIGUSR1 mongod 

или

kill -SIGUSR1 <mongod process id> 

что, впоследствии, приводит к переименованию текущего лога в название файла на подобии mongod.log.2010-12-10T23-36-03, которые потом удобно удалять по дате, указанной в названии.

Восстановление БД

Если произошла неприятность в виде потери питания (machine crash) или некорректного завершения MongoDB (kill -9 termination), то предстоит процедура восстановления базы (repairDatabase command). Эта команда проверяет все данные на испорченность, удаляет найденые некорректные и собирает файлы данных. Repair — аналог работы fsck.
Если slave crashes, нужно запустить демон c параметром —repair, и после окончания работы запустить демон в нормальном режиме.
Для запуска восстановления в интерактивном режиме для всех БД, включая базу local:

db.repairDatabase() 

Время выполнения, как обычно, зависит от размера БД.

Масштабируемость и отказоустойчивость

MongoDB обладает возможностями репликации данных, что благоприятно влияет на повышение отказоустойчивости, избыточности данных и улучшение масштабируемости. Mongo поддерживает два вида репликации: схема типа master-slave и концепция replica pair. В MongoDB репликация асинхронная, т.е. синхронизация содержимого базы данных происходит не непосредственно в момент изменений, а через некоторое время. На мастер-сервере создается лог операций, который посылается на slave-сервера для обновления. При способе репликации Replica Sets (набор реплик) также среди нескольких серверов присутствует один мастер, но, например, при его падении автоматически мастером становиться один из бывших слейвов.

MongoDB также поддерживает шардинг (sharing) — разделение данных на несколько серверов (нод) с сохранением определенного порядка, что дает возможность горизонтально масштабировать имеющуюся систему. По какому-то определенному ключу данные разносятся на разные ноды и при запросе некоторого документа он будет взят с одной из нод. Шардинг дает возможность оптимизировать и увеличить производительность работы запросов к базе. Целесообразно этот функционал использовать вместе с балансировкой и репликацией, чтобы получить отказоустойчивый кластер. Для каждого shard-а (набора определенных данных) свой обслуживающий mongod-процесс для которого можно настроить репликацию. Для доступа ко всем shard-ам должен работать процесс mongos, который знает какая информация находиться в каждом шарде. Также еще для работы кластера должен быть config-сервер, который хранит метаданные шардов (что где находится). Для отказоустойчивости лучше запустить несколько mongos и config-серверов.

Понравилась статья?
Подписаться на RSS feed
4 комментария:
  1. Николай 5 января, 2011

    Весьма полезная информация, спасибо!

  2. Алексей 19 апреля, 2011

    Спасибо, просто и толково расписано.
    Хотелось бы несколько больше информации про реальное внедрение резервного копирования. В ближайшее время предстоит с этим работать 🙂

  3. Nemo 20 апреля, 2011

    Очень приятно, что статья послужила полезным источником информации для кого-либо!
    По бекапу данных попытался осветить вопрос в заметке Резервное копирование данных MongoDB

  4. luckyredhot 22 июля, 2012

    Отличный сборный материал, один из лучших по теме!
    Спасибо вам огромное!

Оставить комментарий