Документ по каждому пользователю, где startTime имеет последнее время
Это можно сделать ?
Александр
Aleksey
привет, как бы понять сколько записей продолбалось после аварийного отключения примари? хочу сделать метрику sli по дюрабилити данных. думаю что для этого подойдет мониторинг расхождения колва записей между примари и секондари.
yopp
Документ по каждому пользователю, где startTime имеет последнее время
после $sort сделать $group по идентификатору пользователя и использовать $first аккомулятор
yopp
привет, как бы понять сколько записей продолбалось после аварийного отключения примари? хочу сделать метрику sli по дюрабилити данных. думаю что для этого подойдет мониторинг расхождения колва записей между примари и секондари.
зависит от определения что такое «продолбалось»
yopp
если ты про rollback, то открыть роллбэк и прочитать сколько документов туда свалилось
Александр
после $sort сделать $group по идентификатору пользователя и использовать $first аккомулятор
Aleksey
наиболее простой вариант как мне кажется. но буду рад другим варианам определний
Александр
yopp
вобщем-то вы так и сделали
Aleksey
если ты про rollback, то открыть роллбэк и прочитать сколько документов туда свалилось
я про ролбек, но как то в автоматическом режиме.
Aleksey
я думал какую то дельту между транзакшен ид мониторить между мастером и слейвом
yopp
можно вместо перечисления то можно использовать $$ROOT и сложить в поле doc
Aleksey
но такого я не знаю
yopp
роллбэк это совсем выпавшие данные
yopp
т.е. non durable
Александр
можно вместо перечисления то можно использовать $$ROOT и сложить в поле doc
Есть пример с Root ?
yopp
для них нет никаких метрик
yopp
Есть пример с Root ?
https://docs.mongodb.com/manual/reference/operator/aggregation/group/#group-documents-by-author
yopp
ну тоесть единственное что с роллбэком можно сделать, это открыть bson файлы и посчитать сколько там документов
yopp
больше никаких вариантов нет :)
Aleksey
а лаг между примари и секондари в чем измеряется в секундах или транзакциях ?
Aleksey
нет под руками монги
yopp
В секундах. Но лаг это не потерянные данные
yopp
Как только секондари вернётся в кластер он дотянет данные
Aleksey
однако если посчитать что мастер упал в этот момент то вот сколько событий продолбали.
Aleksey
ладно видимо нужен другой вариант
yopp
однако если посчитать что мастер упал в этот момент то вот сколько событий продолбали.
если праймари вернулся, но кластер ухеал за пределы его последнего таймстампа, он сделает роллбэк до последнего общего состояния
yopp
а роллбэк запишет в dbpath
yopp
и дальше дотянет данные
Aleksey
да. именно это я называю продолбали
yopp
Ну вот, а я тебе объясняю что для этого нет метрики :)
Aleksey
их можно подтянуть но вероятно не всегда полезно
yopp
С появлением majority write concern, это проблема приложения, что оно потеряло данные
yopp
значит они были не так нужны
yopp
Т.е. там где терять данные можно, там w: 1 например. А там где нельзя majority. И пока оно по большинству в кластере не раскатается, клиент не получит ack
Aleksey
медленно это
Aleksey
ладно это другой вопрос
yopp
Гарантии всегда дорого и медленно
Aleksey
хорошо, есть ли варианты как измерить по другому что
Once a transaction has been committed, it will remain so.
Alexander
yopp
Если ты хочешь мерять сколько документов роллбечнулось, я ещё раз подчеркну, только читать файл :)
yopp
Ну тоесть других вариантов нет совсем
Александр
https://docs.mongodb.com/manual/reference/operator/aggregation/group/#group-documents-by-author
так у меня все хорошо с группировкой
yopp
Я к тому что вам не обязательно перечислять все поля. Вы можете просто сделать $last/$first: $$ROOT (зависит от порядка сортировки)
Александр
https://docs.mongodb.com/manual/reference/operator/aggregation/group/#group-documents-by-author
а это чтобы поля не дублировать
yopp
хорошо, есть ли варианты как измерить по другому что
Once a transaction has been committed, it will remain so.
Т.е. ты мониторишь https://docs.mongodb.com/manual/reference/command/serverStatus/#mongodb-serverstatus-serverstatus.repl.rbid
если там что-то появилось: упс, тревога. Запускаем агента на ноде с базой и читаем содержимое rollback (и бэкапим его куда-то)
Александр
Я к тому что вам не обязательно перечислять все поля. Вы можете просто сделать $last/$first: $$ROOT (зависит от порядка сортировки)
а как сделать, чтобы они не к новому полю присваивались, а просто в корень
yopp
а как сделать, чтобы они не к новому полю присваивались, а просто в корень
$replaceRoot в следующем после $group шаге https://docs.mongodb.com/manual/reference/operator/aggregation/replaceRoot/
Aleksey
Т.е. ты мониторишь https://docs.mongodb.com/manual/reference/command/serverStatus/#mongodb-serverstatus-serverstatus.repl.rbid
если там что-то появилось: упс, тревога. Запускаем агента на ноде с базой и читаем содержимое rollback (и бэкапим его куда-то)
ладно видимо синтентика мой вариант. закидывать в коллекцию раз в n секунд таймстамп и сравнивать с ожиданием. очень примерно, довольно грубо, но покроет и востановление из бекапа на сингле и сбой мастера.
yopp
а в чём сложность читать корректный источник информации, а не синтетическую некорректную метрику?
Aleksey
да нет сложности. ты просто про анализ а не про мониторинг. ну и ролбек это одна из ситуаций.
yopp
роллбэк это в принципе единственная ситуация при которой монга поднимется после отказа
yopp
я про мониторинг и говорю: у тебя есть rbid, на который надо повесить сингал
yopp
если тебе нужно мониторить сколько откатилось, то разбирать файл и считать, потому что роллбэки не отображаются в метриках
yopp
возможно в логе где-то будет, можно попробовать оттуда вытащить
Александр
$replaceRoot в следующем после $group шаге https://docs.mongodb.com/manual/reference/operator/aggregation/replaceRoot/
Подскажите, что вмеcnj newRoot написать ?
const lastSessions = await Sessions.aggregate(
[
{ $sort: { startTime: 1, } },
{ $group:
{
_id: "$userAdName",
$last: { $replaceRoot: { newRoot: "$name" } }
}
}
]
);
yopp
yopp
это pipeline stage
yopp
yopp
а last где ?
[
{ $sort: { startTime: 1, } },
{ $group:
{
_id: "$userAdName",
doc: {$last: "$$ROOT"}
}
},
{
$replaceRoot: {newRoot: "$doc" }
}
]
Александр
[
{ $sort: { startTime: 1, } },
{ $group:
{
_id: "$userAdName",
doc: {$last: "$$ROOT"}
}
},
{
$replaceRoot: {newRoot: "$doc" }
}
]
Спасибо большое, я doc еще не использовал )
yopp
это произвольное имя аттрибута
yopp
вы вместо doc можете любое удобное имя использовать, главное его потом в newRoot поменять
Aleksey
роллбэк это в принципе единственная ситуация при которой монга поднимется после отказа
ack но fsync не fsync при w:1 невозможен ?
yopp
если j: true не стоит, а монга упала в момент когда движок не успел записать данные на диск, то да, конечно. но я тебе почему и говорю что твой таймштамп тебе тоже ничего не скажет, потому что с вероятнюсть (n-1)/n монга упадёт после него :)
yopp
где n количесто документов в интервале между таймштампами
yopp
ну тоесть в принципе, если операция in-flight, узнать что она недолетела до диска можно только повысив уровень гарантий
Александр
[
{ $sort: { startTime: 1, } },
{ $group:
{
_id: "$userAdName",
doc: {$last: "$$ROOT"}
}
},
{
$replaceRoot: {newRoot: "$doc" }
}
]
yopp
ни со стороны клиента, так как при низком уровне гарантий он получит ack, ни со стороны монги, так как узнать что что-то потерялось без persistency in-flight состояний невозможно чисто физически
Aleksey
если j: true не стоит, а монга упала в момент когда движок не успел записать данные на диск, то да, конечно. но я тебе почему и говорю что твой таймштамп тебе тоже ничего не скажет, потому что с вероятнюсть (n-1)/n монга упадёт после него :)
пойду узнаю больше про данные. вероятно они append only. тогда можно считать чексумму данных.
тогда для ситуации ролбека можно считать документы, а для бекапа считать чексуму, например почасовую или 15минутную
yopp
а в оплог операции попадают после коммита в хранилище