Про удаленные сообщения. Подобный уровень аргументаций тут не приветствуется. Если вы считаете что монга н подходит для чьего-то кейса, подробно объясните чем другое решение лучше.

@dd_bb я опять тут со своими чанками :) подскажи, плиз, а как их проверять можно? суть в чем: я вроде сделал так, как вы сказали: - потушил балансер - удалил все TagRange , кроме местных. - сделал splitAt() - добавил addTagRange зону (точнее сразу все) - включил балансер оно чтото делает, изменилось кол-во чанков, но в config.chunks все равно лежат странные чанки. не добралось? не распилилось? как понять, что наступило счастье? или только выборку по коллекции, чтобы проверить, что там нет ненужных стран?

Странные чанки в каком смысле странные?

В том, что там ip разбросаны mongos> db.chunks.find() { "_id" : "DBNAME.COLLNAME-country_\"ae\"ip_\"109.177.115.222\"", "ns" : "dev_0.COLLNAME", "min" : { "country" : "ae", "ip" : "109.177.115.222" }, "max" : { "country" : "ae", "ip" : "109.177.161.138" }, "shard" : "DSPRSv01", "lastmod" : Timestamp(1, 39), "lastmodEpoch" : ObjectId("5a86a96c8fb2d1890910fb94") }

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

Нееет

Чанки не «слепляются» :)

тогда пошёл читать дальше

мне непонятно, как отследить состояние то есть вот splitAt вернул мне ок - и дальше что? :) где посмотреть, над чем думает балансер?

Вы через splitAt порезали чанки по нужным вам для зонирования границам

splitAt только делит чанки

Балансировка и разделение чанков — разные механизмы

Устроить чтоли мастеркласс по шардингу

splitAt должен порезать существующие чанки на 2 части по той query, что я задал. то есть чанков должно стать больше блин, пойду дальше опыты ставить не хватает знаний, чтобы правильно вопрос задать спасибо!

Устроить чтоли мастеркласс по шардингу

я запишусь :)

splitAt должен порезать существующие чанки на 2 части по той query, что я задал. то есть чанков должно стать больше блин, пойду дальше опыты ставить не хватает знаний, чтобы правильно вопрос задать спасибо!

Да, именно

Так как у вас были ренжи для балансировки которые требуют чтоб чанки не включали в себя больше одной страны, но такие чанки существовали — балансировщик скорее всего не мог удовлетворить условие

Сейчас по идее ситуация должна выправиться

Сейчас по идее ситуация должна выправиться

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

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

как понять, завершился ли процесс разделения чанков? в db.currentOp() ничего интересного не заметил.

Он сразу завершается

Когда splitAt возвращает ответ

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

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

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

И ещё раз: чанки — виртуальная единица

Это запись в db.chunks

Удалить один чанк и добавить два других это операция требующая миллесекунды

Когда вы делите чанк с вашим документами вообще ничего не происходит

Каждый шард это просто коллекция содержащая часть документов. Эта совершенным обычная коллекция

понял, спасибо а как тогда правильно посмотреть-проверить, чтобы внутри одного чанка не было различных стран? Получается, что надо изучить config.chunks, ну или sh.status(true) ? Вот чанк, к примеру: { "country" : "ae", "ip" : "86.96.73.99" } —» { "country" : "ae", "ip" : "86.97.11.106" } on : DSPRSv01 Timestamp(1, 142) я же правильно понимаю, что в данном чанке только одна страна?

Чанк это виртуальная сущность которая необходима для того чтоб определить какая часть документов в какой коллекции находится

понял, спасибо а как тогда правильно посмотреть-проверить, чтобы внутри одного чанка не было различных стран? Получается, что надо изучить config.chunks, ну или sh.status(true) ? Вот чанк, к примеру: { "country" : "ae", "ip" : "86.96.73.99" } —» { "country" : "ae", "ip" : "86.97.11.106" } on : DSPRSv01 Timestamp(1, 142) я же правильно понимаю, что в данном чанке только одна страна?

Да

Тогда, судя по всему, у меня, с вашей помощью, все получилось время откупоривать :)

Продолжая: Единственная операция условно взаимодействующая с документам — балансировка

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

А может быть и нет { "country" : "es", "ip" : "999.999.999.999" } —» { "country" : "et", "ip" : "000.000.000.000" } on : DSPRSv01 Timestamp(1989, 173) { "country" : "et", "ip" : "000.000.000.000" } —» { "country" : "et", "ip" : "999.999.999.999" } on : DSPRSv01 Timestamp(1989, 174) { "country" : "et", "ip" : "999.999.999.999" } —» { "country" : "fi", "ip" : "000.000.000.000" } on : DSPRSv01 Timestamp(1989, 175)

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

он все документы же копирует, которые подпадают в чанк, так? то есть балансировщик оперирует чанком или все-таки документами поштучно?

он все документы же копирует, которые подпадают в чанк, так? то есть балансировщик оперирует чанком или все-таки документами поштучно?

Всеми документами которые попадают в диапазон чанка

Тогда не понимаю, откуда берутся чанки вида { "country" : "in", "ip" : "999.999.999.999" } —» { "country" : "io", "ip" : "000.000.000.000" } on : DSP-SG-shard01 Timestamp(1989, 263) попробую на тесте повторить.

Тогда не понимаю, откуда берутся чанки вида { "country" : "in", "ip" : "999.999.999.999" } —» { "country" : "io", "ip" : "000.000.000.000" } on : DSP-SG-shard01 Timestamp(1989, 263) попробую на тесте повторить.

А как вы их режете?

sh.splitAt("DBNAME.COLLNAME", {country: 1, ip: 1})

Так вам надо составить список стран и по каждой выполнить запрос, чтоб подлить по началу. Типа country: io, ip: MinKey

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

(Есть mlaunch в mtools для быстрого разворачивания тестового стола для шардинга)

Ага, спасибо пойду почитаю, потому что... гдет пазлл в голове не досложился

А замена Зоны через removeTagRange + addTagRange должно заставить чанки переезжать? я тут взял для теста одну из зон и поменял ей зону с USA на ASIA, то есть ей в другой шард надо ехать. по зонам там явно есть куски без посторонних стран: { "country" : "za", "ip" : "000.000.000.000" } —» { "country" : "za", "ip" : "41.114.147.104" } on : DSPRSv01 Timestamp(1989, 612) { "country" : "za", "ip" : "41.114.147.104" } —» { "country" : "za", "ip" : "999.999.999.999" } on : DSPRSv01 Timestamp(1989, 613) { "country" : "za", "ip" : "999.999.999.999" } —» { "country" : "zm", "ip" : "000.000.000.000" } on : DSPRSv01 Timestamp(1989, 614) однако у них DSPRSv01 остаётся (это штаты). mongos> sh.getBalancerState() true

Какая у вас версия монги?

Они не обязательно сразу поедут. Может быть у вас там другие миграции не завершились

3.4.13

других миграций нет я уже и по состоянию смотрю, и по трафику на интерфейсе...

balancer: Currently enabled: yes Currently running: no

Ошибки миграций есть?

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

они уменьшаются :)) там же last 24 hrs как-то можно обнулить полностью статистику эту?

Не надо её обнулять. Успешных миграций нет?

Failed balancer rounds in last 5 attempts: 0 Migration Results for the last 24 hours: 589 : Success 393 : Failed with error 'aborted', from DSP-SG-shard01 to DSPRSv01 266 : Failed with error 'aborted', from DSPRSv01 to DSP-SG-shard01 6071 : Failed with error 'aborted', from DSP-SG-shard01 to DSP-SG-shard01

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

А сколько всего данных там?

Shard DSP-SG-shard01 at DSP-SG-shard01/mongo-SG-shard-01:27000,mongo-SG-shard-02:27000 data : 23.18GiB docs : 23665800 chunks : 2011 estimated data per chunk : 11.8MiB estimated docs per chunk : 11768 Shard DSPRSv01 at DSPRSv01/mongo-rs-02:27000,mongo-rs-03:27000 data : 598.91GiB docs : 532651896 chunks : 20920 estimated data per chunk : 29.31MiB estimated docs per chunk : 25461 Totals data : 622.1GiB docs : 556317696 chunks : 22931 Shard DSP-SG-shard01 contains 3.72% data, 4.25% docs in cluster, avg obj size on shard : 1KiB Shard DSPRSv01 contains 96.27% data, 95.74% docs in cluster, avg obj size on shard : 1KiB

А что в логе монгосов?

По SHARDING

У вас там случайно delayed реплики нет?

нет, delayed нет. 2018-02-16T17:03:24.450-0800 I SHARDING [conn27774] Refreshing chunks for collection DBNAME.COLLNAME based on version 511|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:03:24.456-0800 I SHARDING [CatalogCacheLoader-770] Refresh for collection DBNAME.COLLNAME took 5 ms and found version 512|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:03:25.340-0800 I SHARDING [conn28873] Refreshing chunks for collection DBNAME.COLLNAME based on version 512|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:03:25.344-0800 I SHARDING [CatalogCacheLoader-770] Refresh for collection DBNAME.COLLNAME took 3 ms and found version 512|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:03:56.262-0800 I SHARDING [conn27582] Refreshing chunks for collection DBNAME.COLLNAME based on version 512|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:03:56.268-0800 I SHARDING [CatalogCacheLoader-771] Refresh for collection DBNAME.COLLNAME took 6 ms and found version 513|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:03:56.987-0800 I SHARDING [conn28873] Refreshing chunks for collection DBNAME.COLLNAME based on version 513|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:03:56.990-0800 I SHARDING [CatalogCacheLoader-771] Refresh for collection DBNAME.COLLNAME took 3 ms and found version 513|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:04:29.079-0800 I SHARDING [conn27073] Refreshing chunks for collection DBNAME.COLLNAME based on version 513|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:04:29.085-0800 I SHARDING [CatalogCacheLoader-772] Refresh for collection DBNAME.COLLNAME took 6 ms and found version 514|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:04:29.931-0800 I SHARDING [conn28873] Refreshing chunks for collection DBNAME.COLLNAME based on version 514|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:04:29.936-0800 I SHARDING [CatalogCacheLoader-772] Refresh for collection DBNAME.COLLNAME took 4 ms and found version 514|1||5a86a96c8fb2d1890910fb94 от вчера. больше ничего по sharding нет

Эм

А сколько у вас монгосов?

Если вы руками двигали, в лог moveChunk должен был попасть

монгосов сейчас три

На всех трёх в логах ничего нет? (И логи куда-нибудь на gist.github.com кидайте)

да вот куда ни гляну - везде типа 2018-02-16T17:04:29.931-0800 I SHARDING [conn28873] Refreshing chunks for collection DBNAME.COLLNAME based on version 514|1||5a86a96c8fb2d1890910fb94 2018-02-16T17:04:29.936-0800 I SHARDING [CatalogCacheLoader-772] Refresh for collection DBNAME.COLLNAME took 4 ms and found version 514|1||5a86a96c8fb2d1890910fb94 и ничего интересного больше смотрю дальше, увижу чтот - поделюсь

А если по moveChunk грепнуть?

простите, отлучался по moveChunk вообще тишина. видать чтото такое добавили в более свежих версиях mongose

смотрю в systemLog: destination: file logAppend: true path: /var/log/mongodb/mongoRSmongos.log

movechunk в лог mongod пишется, не монгоса

сейчас ASIA пытается двинуть какие-то чанки в USA я так понимаю это после splitAt по странам, однако USA не принимает их. Штаты говорят: 2018-02-18T10:28:33.013-0800 W SHARDING [conn883119] can't accept new chunks because there are still 948 deletes from previous migration вот эти 948 deletes неторопливо уменьшаются. Крайне неторопливо, но все же. ну а со стороны ASIA вот такое 2018-02-18T10:31:31.494-0800 I COMMAND [conn967] command admin.$cmd appName: "MongoDB Shell" command: moveChunk { moveChunk: "DB.COLLNAME", shardVersion: [ Timestamp 1989000|622, ObjectId('5a86a96c8fb2d1890910fb94') ], epoch: ObjectId('5a86a96c8fb2d1890910fb94'), configdb: "DSP-CSRS-01/mongo-rs-02:27050,mongo-rs-03:27050,mongo-ie-csrs:27050,mongo-SG-shard-01:27050,mongo-SG-shard-02:27050", fromShard: "DSP-SG-shard01", toShard: "DSPRSv01", min: { country: "co", ip: "000.000.000.000" }, max: { country: "co", ip: "152.200.242.41" }, chunkVersion: [ Timestamp 1989000|122, ObjectId('5a86a96c8fb2d1890910fb94') ], maxChunkSizeBytes: 67108864, waitForDelete: false, takeDistLock: false } exception: can't accept new chunks because there are still 947 deletes from previous migration code:200 numYields:388 reslen:300 locks:{ Global: { acquireCount: { r: 786, w: 2 } }, Database: { acquireCount: { r: 392, w: 2 } }, Collection: { acquireCount: { r: 392, W: 2 } } } protocol:op_command 3528ms не очень ясно, что это за delete такие, но оно сейчас внутри себя чтото пилит. ждём.

для истории - -вот это все в логах mongodb, который primary.

сейчас ASIA пытается двинуть какие-то чанки в USA я так понимаю это после splitAt по странам, однако USA не принимает их. Штаты говорят: 2018-02-18T10:28:33.013-0800 W SHARDING [conn883119] can't accept new chunks because there are still 948 deletes from previous migration вот эти 948 deletes неторопливо уменьшаются. Крайне неторопливо, но все же. ну а со стороны ASIA вот такое 2018-02-18T10:31:31.494-0800 I COMMAND [conn967] command admin.$cmd appName: "MongoDB Shell" command: moveChunk { moveChunk: "DB.COLLNAME", shardVersion: [ Timestamp 1989000|622, ObjectId('5a86a96c8fb2d1890910fb94') ], epoch: ObjectId('5a86a96c8fb2d1890910fb94'), configdb: "DSP-CSRS-01/mongo-rs-02:27050,mongo-rs-03:27050,mongo-ie-csrs:27050,mongo-SG-shard-01:27050,mongo-SG-shard-02:27050", fromShard: "DSP-SG-shard01", toShard: "DSPRSv01", min: { country: "co", ip: "000.000.000.000" }, max: { country: "co", ip: "152.200.242.41" }, chunkVersion: [ Timestamp 1989000|122, ObjectId('5a86a96c8fb2d1890910fb94') ], maxChunkSizeBytes: 67108864, waitForDelete: false, takeDistLock: false } exception: can't accept new chunks because there are still 947 deletes from previous migration code:200 numYields:388 reslen:300 locks:{ Global: { acquireCount: { r: 786, w: 2 } }, Database: { acquireCount: { r: 392, w: 2 } }, Collection: { acquireCount: { r: 392, W: 2 } } } protocol:op_command 3528ms не очень ясно, что это за delete такие, но оно сейчас внутри себя чтото пилит. ждём.

Я сталкивался с подобным. Если настраивается окно балансировки, то после операций перемещения чанков следовала пачка удалений и если схд не скмое быстрое, то удаление существенно дольше занимает времени

Но у меня версия монгоса была 3.4.1

сейчас ASIA пытается двинуть какие-то чанки в USA я так понимаю это после splitAt по странам, однако USA не принимает их. Штаты говорят: 2018-02-18T10:28:33.013-0800 W SHARDING [conn883119] can't accept new chunks because there are still 948 deletes from previous migration вот эти 948 deletes неторопливо уменьшаются. Крайне неторопливо, но все же. ну а со стороны ASIA вот такое 2018-02-18T10:31:31.494-0800 I COMMAND [conn967] command admin.$cmd appName: "MongoDB Shell" command: moveChunk { moveChunk: "DB.COLLNAME", shardVersion: [ Timestamp 1989000|622, ObjectId('5a86a96c8fb2d1890910fb94') ], epoch: ObjectId('5a86a96c8fb2d1890910fb94'), configdb: "DSP-CSRS-01/mongo-rs-02:27050,mongo-rs-03:27050,mongo-ie-csrs:27050,mongo-SG-shard-01:27050,mongo-SG-shard-02:27050", fromShard: "DSP-SG-shard01", toShard: "DSPRSv01", min: { country: "co", ip: "000.000.000.000" }, max: { country: "co", ip: "152.200.242.41" }, chunkVersion: [ Timestamp 1989000|122, ObjectId('5a86a96c8fb2d1890910fb94') ], maxChunkSizeBytes: 67108864, waitForDelete: false, takeDistLock: false } exception: can't accept new chunks because there are still 947 deletes from previous migration code:200 numYields:388 reslen:300 locks:{ Global: { acquireCount: { r: 786, w: 2 } }, Database: { acquireCount: { r: 392, w: 2 } }, Collection: { acquireCount: { r: 392, W: 2 } } } protocol:op_command 3528ms не очень ясно, что это за delete такие, но оно сейчас внутри себя чтото пилит. ждём.

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

Извиняюсь за глупый вопрос