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

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, для синхронного удаления

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

Но почему выдаёт AuthenticationError, я правильно указал пароль и юзер и все равно выдает Error

это не папка

это URI

Спасибо за наводку

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

Я изучаю pymongo всего три дня

Хотя, пойду дальше листать гугл

это общий термин

URL то знаю

URI, URL

про Auth не могу подсказать, не использовал никогда.

Ок

а вы там какую-то игрулю пилите чтоли

Да так, всегда что то пилю

Для телеграма

class_ не очень префикс для модуля

без него лучше

Мне так удобнее

почему?

Обычно использую pickle, но там херня с сохранением класса

from .armor import Armor выглядит лучше.

а причём тут пикл?

Ой, это оффтоп. Можно в личку.

Тут не стоит.

можно ещё в @piterpy_meetup :)

Я избегаю чатов с питонистами по личным причинам.

Я конечно могу ошибаться, но судя по этому документу в WT можно включить LSM? https://github.com/wiredtiger/wiredtiger/wiki/Btree-vs-LSM пробовал ли кто такое?) у меня чисто академический интерес

Я конечно могу ошибаться, но судя по этому документу в WT можно включить LSM? https://github.com/wiredtiger/wiredtiger/wiki/Btree-vs-LSM пробовал ли кто такое?) у меня чисто академический интерес

мы со товарищи пробовали монгу с rocksdb ) где тот самый LSM по дефолту используется... Знатоно мы с этим вот повоевали, через 3 месяца нас отпустило и мы вернулись в родимый WT - субъективно оно лучше

Я конечно могу ошибаться, но судя по этому документу в WT можно включить LSM? https://github.com/wiredtiger/wiredtiger/wiki/Btree-vs-LSM пробовал ли кто такое?) у меня чисто академический интерес

Там прямо в документе написано что это имеет смысл только при экстремальных объёмах записи, ценой меньшей производительности при чтении :)

Зачем?

Ок

есть комикс с твоим именем. Про наркозависимую ведьму, с чорным котом и другом, антропоморфной совой.

просто ради интереса, так-то +/- ясны ? https://jira.mongodb.org/browse/SERVER-18396 вот issue на этот счет даже есть)

просто ради интереса, так-то +/- ясны ? https://jira.mongodb.org/browse/SERVER-18396 вот issue на этот счет даже есть)

Ну так воткни свой тестовый сет да проверь. Оно же строкой настройки включается

хм, в issue говорят что сама монга не поддерживает

Эм. Легко поверить: при создании коллекции передай конфиг wt с type=lsm

Я сейчас не смогу проверить

есть комикс с твоим именем. Про наркозависимую ведьму, с чорным котом и другом, антропоморфной совой.

Megg Mogg And Owl

И комикс в их вселенной "megahex"

Но я не вижу причин почему оно не должно работать, там api одно на всех setkey setvalue

есть комикс с твоим именем. Про наркозависимую ведьму, с чорным котом и другом, антропоморфной совой.

Это, давайте с комиксами в другом месте.

Эм. Легко поверить: при создании коллекции передай конфиг wt с type=lsm

Чёт затупил, да, попробую

Чёт затупил, да, попробую

Расскажи что получилось потом

Всем привет. Подскажите мне пожалуйста одну вещь. Есть такая запись в таблице: { "_id" : ObjectId("5a8bec4d9a89204293378e22"), "id" : 356, "name" : "Видеодомофон J2000-DF-ЕКАТЕРР�РќРђ", "sections" : [ 29 ], "with_install" : 0, "novelty" : 0, "hit" : 0, "stock" : 0, "discontinued" : 0, "brand_id" : 20, "properties" : [ { "id" : 3, "value" : "120 С… 170 С… 17 РјРј" }, { "id" : 4, "value" : "36" }, { "id" : 5, "value" : "56" }, { "id" : 14, "value" : "44" }, { "id" : 14, "value" : "84" }, { "id" : 33, "value" : "24" }, { "id" : 66, "value" : "155" }, { "id" : 74, "value" : "49" }, { "id" : 75, "value" : "34" }, { "id" : 76, "value" : "1" }, { "id" : 77, "value" : "21" }, { "id" : 79, "value" : "1" }, { "id" : 81, "value" : "57" }, { "id" : 82, "value" : "60" }, { "id" : 83, "value" : "66" }, { "id" : 88, "value" : "107" }, { "id" : 92, "value" : "0" }, { "id" : 93, "value" : "0" }, { "id" : 94, "value" : "6" }, { "id" : 95, "value" : "70" }, { "id" : 96, "value" : "0" }, { "id" : 97, "value" : "48" }, { "id" : 98, "value" : "2" }, { "id" : 100, "value" : "0" }, { "id" : 101, "value" : "0" }, { "id" : 102, "value" : "0" }, { "id" : 103, "value" : "0" }, { "id" : 104, "value" : "0" }, { "id" : 105, "value" : "0" }, { "id" : 107, "value" : "42" }, { "id" : 109, "value" : "46" }, { "id" : 110, "value" : "52" }, { "id" : 112, "value" : "0" }, { "id" : 113, "value" : "DF-ЕКАТЕРР�РќРђ" }, { "id" : 120, "value" : "186" }, { "id" : 121, "value" : "0" } ] } Пишу такой запрос: db.getCollection('catalog_products').find({id: 356, "properties.id": 96, "properties.value": "1"}); Но эта запись попадает в выборку. Как я понял, это происходит из-за того, что у других элементов properties есть значение value которое равно "1". Подскажите пожалуйста, как можно написать запрос так, чтобы при выборке фильтр действовал в пределах одного объекта из properties?

find_one

Либо указывай больше арументов

тут нужен примерно такой запрос: id: 365, properties:{ "$elemMatch": { "id": 96, "value": 1 } }

тут нужен примерно такой запрос: id: 365, properties:{ "$elemMatch": { "id": 96, "value": 1 } }

спасибо большое

В следующий раз за попытку разжечь — бан

Без возможности амнистии

Ребята а что за новый прикол MongoError: Authentication failed.

а не тот, вот этот MongoError: not master

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