Зато не будет случаев, как отсутствие слева и отвал чтения

А если кластер не справляется - добавьте серверов

Зато не будет случаев, как отсутствие слева и отвал чтения

отвал чтения в ряде случаев лучше чем отвал записи

отвал чтения в ряде случаев лучше чем отвал записи

А в ряде случаев наоборот

отвал чтения в ряде случаев лучше чем отвал записи

Большинство приложений не будет работать корректно без чтения

большинство приложений не должно читать с secondary

Если только что-то вроде логов, которые только пишут и не читают

http://www.askasya.com https://docs.mongodb.com

я конкретно про то где не рекомендуют читать с secondary

И лучше поднапрячь немного соседа, чем просто умереть

большинство приложений не должно читать с secondary

Пффф

Тогда большинству приложений не нужна mongodb

большинство приложений не должно читать с secondary

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

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

Короче, это всё от требований зависит

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

если у тебя окно репликации 300 часов, а реплика остала на 250?

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

Ты не понял. Они говорят лучше secondary Preferred

Ты не понял. Они говорят лучше secondary Preferred

они говорят что лучше вообще не читать с secondary, если ты не понимаешь почему тебе это понадобилось

тоесть ты должен чётко понимать какую именно проблему ты решаешь

они говорят что лучше вообще не читать с secondary, если ты не понимаешь почему тебе это понадобилось

Коллега, написал не это

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

тоесть ты должен чётко понимать какую именно проблему ты решаешь

Опять. Это относится ко всему

точне даже так, в 90% случаев тебе надо шардить, а не реплики скейлить

точне даже так, в 90% случаев тебе надо шардить, а не реплики скейлить

Как померял?;)

запатентованный метод PVN™

если у тебя окно репликации 300 часов, а реплика остала на 250?

Соболезную

точне даже так, в 90% случаев тебе надо шардить, а не реплики скейлить

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

Соболезную

а зря, такое случается очень часто

Железо не справляется?

миллион и одна причина

начиная с того что сеть перегружена например

Это не нормально

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

понятно что если лаг больше минуты, нужно бить тревогу, но в целом

когда ты начинаешь читать с secondary, у тебя меняются требования к инфраструктуре

корочи, вакууму — вакуумные решения

или сферические

или тороидальные

как повезёт!

но в остальном, монга на дефлоте при чтении доки — отлично летает

Ну держать лаг реплики 250 часов... а потом будет 1250?

Ну держать лаг реплики 250 часов... а потом будет 1250?

не будет, если лаг больше oplog window реплика уйдёт в STARTUP2

не будет, если лаг больше oplog window реплика уйдёт в STARTUP2

Ну он тюнится

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

Ну он тюнится

ты вот допускаешь ошибку, которую многие допускают

Оказалось мы могли себе позволить полторы минуты

Оказалось мы могли себе позволить полторы минуты

^^^

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

После этого, мы бы через сутки не успели бы убрать лаг

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

а тут ты можешь столкнутся с адовыми сайдэффектами

например чувак пароль поменял

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

И не факт, что потом можно выгрести, да

да

по этому гены и говорят: читайте с primary

скейлите primary

secondary для HA, а не для увеличения ёмкости

да, есть ряд исключений, когда на secondary можно пустить нагрузку, но таких случаев по пальцам

и за это надо будет заплатить

да, есть ряд исключений, когда на secondary можно пустить нагрузку, но таких случаев по пальцам

Ну да, только они есть почти всегда:)

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

Моё приложение не сломается, потому что критичные данные, которые должны быть консистентны, читает с primary.

Моё приложение не сломается, потому что критичные данные, которые должны быть консистентны, читает с primary.

ха-ха :)

Моё приложение не сломается, потому что критичные данные, которые должны быть консистентны, читает с primary.

Ты не про то

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

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

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

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

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

это хорошо

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

Коллега имел в виду из-за базы

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

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

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

А, я недавно одну из двух AZ отключил на проде для проверки

Всё было хорошо, потом сделал тоже с другой, но не ввел полностью первую сначала, а просто переключил

Крику было

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

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

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

а монга позволяет заменить 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 зависит, от лага зависит и от кучи других параметров