Статьи

Введение в репликацию в MongoDB: часть 1

Это первая из трех статей о том, как работает репликация.

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

Репликация MongoDB на самом деле очень проста: ведущий хранит коллекцию, которая описывает записи, а ведомые запрашивают эту коллекцию. Эта коллекция называется oplog (сокращение от «журнал операций»).

Оплог

Каждая запись (вставка, обновление или удаление) создает документ в коллекции оплогов, если репликация включена (MongoDB не будет беспокоиться о сохранении оплога, если репликация не включена). Итак, чтобы увидеть оплог в действии, начните с запуска базы данных с опцией –replSet :

$ ./mongod --replSet funWithOplogs

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

> rs.initiate()

Теперь, если мы запросим оплог, вы увидите эту операцию:

> use local
switched to db local
> db.oplog.rs.find()
{ 
    "ts" : { "t" : 1286821527000, "i" : 1 }, 
    "h" : NumberLong(0), 
    "op" : "n", 
    "ns" : "", 
    "o" : { "msg" : "initiating set" } 
}

Это просто информационное сообщение для ведомого, это не «настоящая» операция. Разбивая это, он содержит следующие поля:

  • ts : время, когда произошла эта операция.
  • h : уникальный идентификатор для этой операции. Каждая операция будет иметь другое значение в этом поле.
  • op : операция записи, которая должна применяться к ведомому. n указывает на отсутствие операции, это просто информационное сообщение.
  • ns : база данных и коллекция, затронутые этой операцией. Так как это неоперативное, это поле оставлено пустым.
  • о : фактический документ, представляющий оп . Так как это не опционально, это поле довольно бесполезно.

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

> use test
switched to db test
> db.foo.insert({x:1})
> db.foo.update({x:1}, {$set : {y:1}})
> db.foo.update({x:2}, {$set : {y:1}}, true)
> db.foo.remove({x:1})

 Теперь посмотрим на оплог:

> use local
switched to db local
> db.oplog.rs.find()
{ "ts" : { "t" : 1286821527000, "i" : 1 }, "h" : NumberLong(0), "op" : "n", "ns" : "", "o" : { "msg" : "initiating set" } }
{ "ts" : { "t" : 1286821977000, "i" : 1 }, "h" : NumberLong("1722870850266333201"), "op" : "i", "ns" : "test.foo", "o" : { "_id" : ObjectId("4cb35859007cc1f4f9f7f85d"), "x" : 1 } }
{ "ts" : { "t" : 1286821984000, "i" : 1 }, "h" : NumberLong("1633487572904743924"), "op" : "u", "ns" : "test.foo", "o2" : { "_id" : ObjectId("4cb35859007cc1f4f9f7f85d") }, "o" : { "$set" : { "y" : 1 } } }
{ "ts" : { "t" : 1286821993000, "i" : 1 }, "h" : NumberLong("5491114356580488109"), "op" : "i", "ns" : "test.foo", "o" : { "_id" : ObjectId("4cb3586928ce78a2245fbd57"), "x" : 2, "y" : 1 } }
{ "ts" : { "t" : 1286821996000, "i" : 1 }, "h" : NumberLong("243223472855067144"), "op" : "d", "ns" : "test.foo", "b" : true, "o" : { "_id" : ObjectId("4cb35859007cc1f4f9f7f85d") } }

Вы можете видеть, что у каждой операции теперь есть ns : «test.foo». Также представлены три операции ( поле op ), соответствующие трем типам записей, упомянутым ранее: i для вставок, u для обновлений и d для удалений.

Поле o теперь содержит документ для вставки или критерии для обновления и удаления. Обратите внимание , что для обновления, есть два о полях ( O и o2 ). o2 дает критерии обновления, а o дает модификации (эквивалентно второму аргументу update () ).

Используя эту информацию

MongoDB еще не имеет триггеров, но приложения могут подключиться к этой коллекции, если они заинтересованы в том, чтобы что-то делать каждый раз, когда документ удаляется (или обновляется, или вставляется и т. Д.). В третьей части этой серии будет подробно изложена эта идея.

Далее: что такое оплог и как работает синхронизация.