твоё приложение — сломается

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

когда у тебя математически доказано отсуствие багов

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

Ну у нас достаточно регулярно отваливается одна из реплик на "учения"

это хорошо

молодцы, я такие учения уважаю и всяески поддерживаю

Потом догоняется

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

и когда её начинают скейлить, это почти всегда делают в формате «щас как серверов хуйнём» и ничо не работает

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

а монга позволяет заменить DBA железом, на очень ощутимое время

ДБА все равно на 100% не заменить.

Price: USD 150.00

ммм

пойти чтоли лычку получить

нахуй правда она нужна

Вот кстати, заметил, что на репликах данные немного различаются. Ну или может это просто статистика. Документы не сравнивал, но на одной из реплик может внезапно отличаться average object size, Ну и суммарный объем. При том же количестве документов.

эм

ну так конечно

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

ничего в этом плохого нет, беспокоиться не надо

Меня смущает, что это только на одной из реплик и только в одной коллекции

апдейтов в коллекции много и документы скорее всего существенно в размере меняются

Он же считает чистые данные, а не те что хранятся на диске, разве нет?

aos считается как storage size / document count

тьфу

Для диска там отдельное поле, не помню сейчас как называется

"count" : 866, "size" : 862581, "avgObjSize" : 996, "storageSize" : 294912,

862581/866 = 996.0519630485

size / count

Для диска там отдельное поле, не помню сейчас как называется

но ваще от storage engine зависит, от лага зависит и от кучи других параметров

если только одна реплика и существенные различия, можно попробовать поставить ещё одну реплику и посмотреть

если стуация повторится, можно хуйнуть им ишшуй в жиру

лаг 0, реплик 3 штуки + primary + hidden

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

воспроизводится спустя время

только на одной

всегда одной и той-же, или на разных может быть?

WT? или MMAP?

сейчас посмотрю стату, может воспроизведётся

wt, 3.2

у WT куча метаданных, там можно посмотреть

сейчас не воспроизводится

ну кроме storage size, но это именно объем на диске

avgObjSize/dataSize совпадают с точностью до байта (или последней цифры после запятой)

avgObjSize = size / count

это вычисляемая метрика

ну да

надо уже для прометея написать нормальный коллектор данных

просто в прошлый раз у меня везде dataSize оканчивался на 6 и я не сразу глазом зацепился, а в average была видна разница

щас с WT столько вкусных метрик есть

dataSize?

а, dataSize()

так это и есть size из stats

db.stats().dataSize

ом

а

db.stats

ну и db.collection.stats(), соответствевнно)

на уровне данных о базе я бы не стал вообще париться если там что-то между репликами отличается

потому что там system учитывается

если например включен профайлер, там всё может отличатся

там коллекция различалась конкретная рабочая

если сейчас не воспроизводится, то и отлично

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

ну... уже два раза с начала года воспроизводилось

рано или поздно выстрелит

настрой мониторинг

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

ок, спасибо, запомню

настрой мониторинг

слишком высока вероятность false positive из-за лага репликации

ну так настрой с джитером

0.1%

или сколько там

надо бы

хотя, скорее в этот 0.1% различия и уложатся

потмоу что разница там в единицах КБ на десятках ГБ

такое впечатление, что какой-то один апдейт поля не доехал

что в принципе странно, потому что оплог должен на это рано или поздно наткнуться и поломать репликацию (должен же?)

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