А покажите правила зоны?

(use config; db.shards.find())

{ "_id" : "DSP-SG-shard01", "host" : "DSP-SG-shard01/mongo-SG-shard-01:27000,mongo-SG-shard-02:27000", "state" : 1, "tags" : [ "ASIA" ] } { "_id" : "DSPRSv01", "host" : "DSPRSv01/mongo-rs-02:27000,mongo-rs-03:27000", "state" : 1, "tags" : [ "USA" ] }

А вы range добавляли?

https://docs.mongodb.com/manual/reference/method/sh.updateZoneKeyRange/#sh.updateZoneKeyRange

да, там этих range сейчас как у дурака фантиков.

В конфиге db.tags.find()

Скорее всего проблема где-то в них

mongos> db.tags.find().count() 247

{ "_id" : { "ns" : "_DB_._XXX_", "min" : { "country" : "ad", "ip" : "000.000.000.000" } }, "ns" : "dev_0.stop_clicks", "min" : { "country" : "ad", "ip" : "000.000.000.000" }, "max" : { "country" : "ad", "ip" : "999.999.999.999" }, "tag" : "USA" }

это вот один из.

А сейчас данные на каком шарде застряли?

они все на оригинальном, который USA если говорить тегами.

А есть ренжи которые на тег ASIA назначены?

в азию сейчас указано двигаться некоторым странам, range в ip — 00 — 99, то есть полный список я вручную двинул один из шардов, который явно был виден в sh.status(true), и заглянул руками в шард - там есть страны, которые _не_ в списке. то есть получается, что внутри шарда есть чтото, что шарду не принадлежит. отсюда и было предположение, что неправильно сформировались.

да, есть

sh.status() tag: ASIA { "country" : "tw", "ip" : "000.000.000.000" } —» { "country" : "tw", "ip" : "999.999.999.999" }

к примеру

Попробуйте у ip вместо строки указать MinKey и MaxKey

Если вы хотите просто по префиксу балансировать

ip делали с прицелом на будущее - если внутри одного региона будет много данных и надо будет их еще на 1 шард добавить. сейчас по сути - не используются чанки получились такие (кусок, для примера) { "country" : "tr", "ip" : "95.7.42.144" } -->> { "country" : "tw", "ip" : "1.160.105.3" } on : DSP-SG-shard01 Timestamp(2, 0) { "country" : "tw", "ip" : "1.160.105.3" } -->> { "country" : "tw", "ip" : "1.161.252.238" } on : DSPRSv01 Timestamp(1, 15067) { "country" : "tw", "ip" : "1.161.252.238" } -->> { "country" : "tw", "ip" : "1.163.194.238" } on : DSPRSv01 Timestamp(1, 15068) { "country" : "tw", "ip" : "1.163.194.238" } -->> { "country" : "tw", "ip" : "1.165.126.220" } on : DSPRSv01 Timestamp(1, 15069) { "country" : "tw", "ip" : "1.165.126.220" } -->> { "country" : "tw", "ip" : "1.168.37.33" } on : DSPRSv01 Timestamp(1, 15070) { "country" : "tw", "ip" : "1.168.37.33" } -->> { "country" : "tw", "ip" : "1.170.181.216" } on : DSPRSv01 Timestamp(1, 15071)

это в sh.status(true) видно непонятно, почему балансер их не двигает. пока решил руками, потому что отдельные тесты - типа записи в Азиатском дц в монгос - сохраняет данные где надо.

Ааааа.

Так, стало видно откуда возникла история «неверно порезались» :)

Зоны никак не влияют на то, как данные разбиваются на чанки

Чанк разбивается при превышении сконфигурированного размера

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

какие слова для гугления? Подскажите,пожалуйста :)

https://docs.mongodb.com/manual/reference/method/sh.splitAt/#sh.splitAt

и оно перетрясёт существующие чанки? Прекрасно, спасибо!

а при миграции чанка в азию - там не происходит момент, что оно ненужную страну вернет обратно?

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

хотя там же не монгос, там репликасет затупил

а при миграции чанка в азию - там не происходит момент, что оно ненужную страну вернет обратно?

Балансировщик не знает ничего про страны. Он очень тупой и перетаскивает чанки, если видит что они нарушают правила зоны. Условно, вы порежете чанк с Турцией и Тайванью. Если для Турции есть правило что её надо в USA, то он нарушает правила и поедет обратно в штаты.

Если на Турцию ренджа нет, она будет кататься балансировщиком по базовым правилам (держать равное количество чанков)

Я бы начал с простого: убрал бы все ренджи

Кроме одного: что всё в штатах

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

(это будут все страны кроме 4х на данный момент :)) ), но не суть. внимательно слушаю.

И включал балансировщик

то есть останавливаем балансер и пилим. понял.

Балансировщик лучше всегда выключать, когда вы какие-то изменения вносите в правила или настройки шарда

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

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

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

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

Всем привет, был rs с тремя нодами, primary прилег, осталось два secondary и ни один не хочет становится primary, как то можно принудительно сказать одной из нод: ты теперь primary?

Заведите арбитра

2018-02-17T22:05:40.374+0000 I COMMAND [ftdc] serverStatus was very slow: { after basic: 0, after asserts: 0, after backgroundFlushing: 0, after connections: 0, after dur: 0, after extra_info: 1600, after globalLock: 1600, after locks: 1600, after network: 1600, after opLatencies: 1600, after opcounters: 1600, after opcountersRepl: 1600, after repl: 1600, after security: 1600, after storageEngine: 1600, after tcmalloc: 1600, after wiredTiger: 1600, at end: 1600 }

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

меняются только цифры, похоже на репликацию или восстановление из оплога

Тормозит команда serverStatus, судя по всему

Праймари то выбрался?

Я на живой ноде из клатсера выбросил две дрвух ноды и он стал primary, потом поднял их и они тупили в логах в командой выше, ждать надело, утром эти ноды стали доступны и я их добавил обратно в кластер (ну и они подянлись со статусом OTHER до добавления) похоже на то что нужно все таки арбиторов добавить

Хмм, кластер из трех нод? Я бы не стал больше одной ноды выбрасывать за раз. И это безотносительно MongoDB. Просто кворум должен быть всегда живым.

Привет, нубский вопрос: как монга ведет себя в продакшине в качестве основного хранилища, на что стоит обратить особое внимание? Заранее спасибо

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

Привет, нубский вопрос: как монга ведет себя в продакшине в качестве основного хранилища, на что стоит обратить особое внимание? Заранее спасибо

Хорошо ведёт. На метрики важные для вашего приложения. Менее технические — это какие?

Хмм, кластер из трех нод? Я бы не стал больше одной ноды выбрасывать за раз. И это безотносительно MongoDB. Просто кворум должен быть всегда живым.

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

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

Ага, только одна сама отпала в моем случае

Хорошо ведёт. На метрики важные для вашего приложения. Менее технические — это какие?

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

У нас тут всё принято

Есть какие либо best practice при проектировании структур данных в монго?

От кейса зависит. Но общий смысл: пишите так, ка будете читать.

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

Это просто формат хранения ссылок

Их скорость будет равна скорости поиска по указанному в ссылке ключу в указанной в ссылке коллекции.

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

Она ничего не будет делать

Это будет делать драйвер, если он умеет автоматически разрешать ссылки

Может и не уметь, причём намеренно.

То бишь чем больше нормализации тем медленней оно будет?

Ну можно с натяжкой и так сказать

Как и с полной денормализацией

Но абстрактные проблемы имеют абстрактное решение. Какую задачу вы решить хотите?

Пока я пытаюсь понять: подходит ли мне монга. Небольшой проект, можно сказать стартап. Предполагаю чтение из бд запросом по юзерам, и если мыслить в рамках реляционки, + нескольких зависимых таблиц. Плюс попутно раз в минуту/пол - 100+ записей в таблицу юзеров (апдейт).

Точнее апдейт 100 записей

И с потенциалом на увеличение количества апдейтов и их интенсивность

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

Да