"bytes currently in the cache" : 710342011, "bytes read into cache" : 496185602, "bytes written from cache" : 161808640,

я наверно не совсем понимаю, это что некий тест такой для монги, после которого она выводит статистику?

нет, это внутренние метрики хранилища

они относительно безобидные в сборке

по крайней мере на порядки более безобидные чем setProfile с 10мс

wt и так собирает кучу информации, так что это просто чтение из памяти без особых изысков

короче

currently in cache покажет тебе сколько данные занимают в памяти (можно сравнить с size и понять сколько вмещается в память)

изменение currently in cache покажет что происходит с кешем конкретной коллекции: кеш вытесняется или вытесняет других

read into покажет как кеш пополняется / wrritten from показывает сколько из кеша выгружается на диск

это позволит определить что коллекция/индекс дрочат диск

дальше берём cursors и смотрим что именно дрочит

ага...теперь вроде более менее понятно

и третий момент

расскажи про курсор, что это?

"block-manager" : { "checkpoint size" : 194146304, "file size in bytes" : 185212928, "file bytes available for reuse" : 28672, }

изменение file size in bytes покажет тебе когда монга аллоцирует ещё места на диске

file bytes available for reuse покажет тебе что у тебя в коллекции много «дырок»: страниц которые помечены как свободные

checkpoint size я чот не помню зачем я сюда ввернул

про курсор можно поподробнее, что он показывает?

ну курсор он и есть курсор

как он дрочит диск и тп, давай подробости)

курсор это штука которая читает данные в wiredtiger

если про wt метрики

в монге любой запрос (в sql терминологии select) на чтение открывает курсор

считай как «постраничная навигация»

ок. так

курсор тебе выдаёт окно в X записей и ты можешь туда-сюда двигать это окно

то есть, это размер пачки на запись/чтение?

нуууу не совсем

это скорее количество запросов на чтение в базу и что с ними происходит

инструмент для "навигации" по записям считанным)

не только

т. е. только для чтения используется?

"insert calls" : 1257539,

а search calls - это как раз find и другие проходы по индексам?

"search calls" : 616617, "search calls" : 618801,

да, судя по всему так

ясно. А курсор ходит и по кешу и по диску или только по диску?

курсор ходит по данным. в кеше или на диске они это не его дело

ага. так и думал...ясно спасибо

но тут нужн понимать что wt.cursors это не прямой эквивалент mongodb курсору

ок, а какая между ними разница?

монга поддерживает различные хранилища и wt только одно из (другое MMAPv1 и теперь ещё memory storage)

так совпало что в wt тоже есть курсоры, потому что wt это такой хитрый key-value сторадж

но они именно о деталях реализации конкретного хранилища, а не о деталях реализации на уровне монги

тоесть если ты сделал в монге find({a: 1}) это не значит что cursors изменятся на 1

оин могут изменится на любое произвольное число, в зависимости от стратегии которую выберет планировщик в хранилище

то есть, изменения курсора - это некая логическая операция, которая происходит при достижении N байт при чтиении/записи?

N зависит от некого планировщика?

нет, это логическая опреация связанная с детялями реализации того как хранилище данные возвращает в монгу

монга, с 2.8 кажется, это просто набор универсальных API для разных хранилищ, которые позволяют хранить произвольные документы

в bson

ну сейчас wt же везде используется

это не отменяет того факта что у монги есть свои курсоры, а у хранилища _могут быть_ свои

в MMAPv1 нет курсоров

там вообще ничего нет, тлен и mmap(1)

монговские курсоры тебе покажет serverStatus.metrics.cursor и частично opcounters

хорошо, спасибо. А вот еще несколько вопросов философско-концептуальных: 1. В бест практисах используют в репликасете 4 сервера. мастер, 2реплика и хайден реплика. Зачем она нужна? чтобы просто не учавствовать в голосовании и для бекапа?

hidden реплика по тому и hidden что в неё порядочные клиенты ходить не будут, потому что они делают вид что её нет

а значит её можно воткнуть на медленные диски (главное чтоб на репликацию хватало) и дать памяти по минимуму (главное чтоб на репликацию хватало) и дёргать её как хочешь

про три ноды (в монге любая нода в любой момент времени может стать primary и потом slave и потом опять primary)

на самом деле об этом более-менее в доке написано, но это такое количество нод, которые уже обеспечивают более-менее нормальную отказоустойчивость вне зависимости от хотелок пользователей

тоесть если кто-то там делает запросы с readPref: secondary, если у нас одна нода подохла или мы её вывели из эксплуатации на облуживание, у нас всё ещё остаётся один secondary

на двух нодах будет уже сложнее. плюс нужен будет арбитр

потому что если нода осталась одна, она не станет мастером

она будет плакать и считать себя slave

потому что выборы из одного человека, где он-же и кандидат и голосующий — шизофрения и в субд :)

ок. А как обычно принято бекапить хайден реплику? монгодампом или остановкой демона и рсинком файлов?

и что тогда с оплогом происходит? сколько можно демона выключенным держать?

оплог это capped коллекция, что с ним может происходить? :)

правильно: у него с конца выпадают самые старые данные (FIFO)

тоесть демона можно держать выключеным ровно столько, сколько времени покрывает сейчас оплог

бекапить лучше всего через снепшоты фс

ежечасно. прореживая суточно

и еженедельно делать дамп

нужно не забывать что если у тебя sharded cluster то там особая процедура

пока у меня репликасет, но скоро будет шаред кластер

главное что нужно сделать с бекапами: постоянно их проверять

идеально заливая ежедневно на стейджинг