3.4.4 пробовали? Когда началось? Что в конфигах?

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

На всех репликах такое или только на одной?

Где такое говорится?

https://docs.mongodb.com/v3.4/faq/storage/#how-frequently-does-wiredtiger-write-to-disk

К смерти в каком виде?

https://docs.mongodb.com/v3.4/faq/storage/#how-frequently-does-wiredtiger-write-to-disk

Прочитай внимательно ещё раз

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

В serverStatus.wiredTiger.log что?

У пользователя монги точно есть право на удаление файлов? И всё-таки расскажи как именно оно умерло

https://jira.mongodb.org/browse/WT-2264

Закрыто в 3.4

И даже бекпорт в 3.2.5

/me ставит на проблему с диском или правами

/me

наследие чятиков?

Ирц же

В serverStatus.wiredTiger.log что?

https://pastebin.com/6xREEu0j

/me ставит на проблему с диском или правами

ну т.к. оно долгое время работало нормально, все же не думаю

Сейчас сколько файлов в папке с журналом?

ну т.к. оно долгое время работало нормально, все же не думаю

Расскажи что именно произошло когда попробовали перезапустить?

1114 файлов

Что за дисковое хранилище используется?

1114 файлов

Исходя из того что монга вроде как всего 28к файлов создавала, с виду все нормально.

Расскажи что именно произошло когда попробовали перезапустить?

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

Эм.

Журнал на диск сливается не реже чем раз в минуту.

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

А вот при старте она весь журнал проигрывает.

В serverStatus.wiredTiger.transaction что?

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

Такая ситуация на всех нодах в репликах?

Как себя репликация чувствует?

И вообще как реплика выглядит? Сколько серверов? Какой прирост оплога?

не, ситуация только на primary репликация вообще в порядке в реплике 3 сервера

Если выбрать другую ноду как праймари, проблема на ней воспроизводится?

/me

о, я тогда сюда вопросы свои зафорваржу про диски и нагрузку

Монго-гуру, подскажите, пожалуйста - как можно разнести IO нагрузку на базу между различными дисками? монга 3.4.4 , WiredTiger. база одна. Может можно журнал на отдельное устройство вытащить?

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

объединение дисков на уровне OS пока отложено на последний момент. Было больше интересно, можно ли какую-то логическую единицу в монге вытащить отдельно. К примеру - каждая база в своей директории, и эту директорию можно втулить на конкретный диск. но база одна :) думалось, может можно отщепить какие-то логические модули в отдельную директорию и вынести отдельно. Пока внутри директории монги есть 2 директории - journal, размером в неполный гиг, и diagnostic.data, неполных 200 метров. Вот и думаю можно ли их (и есть ли смысл) вытаскивать отдельно

в журнал должен активно write идти, но файлы преалокейчены. если смотреть чексамы - меняется только 1 файл потому и вопрос - стоит ли овчинка выделки

`storage.directoryPerDB`

`storage.directoryPerDB`

База одна

или admin / local есть смысл выносить?

Local да, туда пишется оплог

Увеличить можно просто сделав симлмнки на нужные коллекции

Или индексы

Посмотреть какие коллекции/индексы наиболее нагруженные и поделить их между дисками.

чтото про симлинки я не подумал. да, есть коллекции, в которые льётся 90% запросов

бекапить то потом всё это дело как ?

бекапить то потом всё это дело как ?

А какая разница?

раскидали по дискам потеряли снапшоты

Нет.

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

на данный момент так бекап и работает - тушится нода в репликасете и делается ее снапшот. корявенько, но быстро и не критично

Local да, туда пишется оплог

а на живой системе так можно делать? или придется ресинкаться?

Нет.

пояснения будут :) ?

пояснения будут :) ?

Доку про снепшоты почитай внимательно, там про это написано.

а на живой системе так можно делать? или придется ресинкаться?

Можно попробовать руками переложить

Делаешь stats на всех коллекциях и индексах во всех базах, записываешься имена файлов. Выключаешь, делаешь резервную копию dbPath, меняешь опцию и раскладываешь файлы по директориям. Запускаешь монгу и смотришь что произошло.

Можно просто снепшот на другой тачке развернуть и там попробовать

Можно вообще на тестовом столе собрать и проверить поведение

пояснения будут :) ?

Tl;dr: fsync

именно.

именно fsync.

Ну. В чём проблема?

Спасибо!

буду пробовать

Он и так нужен если журналы вынесены.

Учитывая что бекапы надо делать с hidden нод, то можно даже монгу потушить. :)

Что даст 100% гарантию консистености хранилища.

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

Changed in version 3.0: To change the —directoryperdb option for existing deployments, you must restart the mongod instances with the new —directoryperdb value and a new data directory (--dbpath <new path>), and then repopulate the data. Какая печаль.

Поделитесь еще своими бест практисами по выбору размера оплога, плиз? кто какой срок ставит? и как его высчитывает?

Его должно хватать на время initial sync как минимум

(как следствие должен быть запас на «всё пошло не так»)

да, именно с этой проблемой я и столкнулся. там дефолтные 50 гиг стоят, буду раздвигать дня на 4 надо будет минимум ставить - с одной стороны с другой - бекапы суточные, и initial sync с нуля делать смысла нет. но если переезжать на directoryPerDB - как раз нужен этот initial sync. В сомнениях, в общем.

раздвигать надо аккуратно

плюс надо понимать что его мгновенно больше не станет :)

на что обратить особенное внимание? в доке процесс описан, буду делать на тестовом стенде, но на стенде данных в разы меньше

плюс надо понимать что его мгновенно больше не станет :)

я так понимаю, что если прикинуть размер до 4-5 дней, то и ждать надо будет эти 4-5 дней, пока этот лог надуется? :)

ну да :)

oplog это тупо capped коллекция

oplog size это capped maxsize, который расчитывается при инициализации local базы

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

заведите delayed member на этот случай

Хорошая идея, всуну в беклог,спасибо!

на что обратить особенное внимание? в доке процесс описан, буду делать на тестовом стенде, но на стенде данных в разы меньше

на то, что oplog где-то остался :)

потому что иначе может быть очень больно

потому что иначе может быть очень больно

столько вазелина у меня нет

да ладно, это просто время

если оплога остаётся на полчаса, то любой даунтайм больше получаса и тебе надо переливать всё сначала

по этому лучше сначала поднять оплог по очереди на каждом secondary, дождаться пока его не накопиться нужное количество и потом уже когда на всех seconday нужное количество оплога, менять на primary

я не помню, есть ли там процедура без потери оплога

да тут получилось все как обычно. - сначала я с этим не шарил - потом проверил - вроде норм, 50 гигов хватало на 2 дня и initial sync проходил нормально - потом все "внезапно выросло и мы тут чуть-чуть убили реплику, потом просто поживем на мастере" - sync зафейлился и вообще стало DSPRSv01:SECONDARY> rs.printReplicationInfo() configured oplog size: 51200MB log length start to end: 26882secs (7.47hrs)

но наверное можно просто дампнуть коллекцию и заресторить

кек

7 гигов в час