тоесть у тебя приехала операция из будущего

мммм.

нет

если повторно выполнить команду тут же тот там 0 потом опять -2 или -1

ну да

ntp настрой

и следи за дрифтом

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

если повторно выполнить команду тут же тот там 0 потом опять -2 или -1

наприер если монга не будет 10 часов менятся, у тебя там будет 10 часов лаг :)

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

ntp говорит что всё зашибись

это нормально. оно считает время относительно последенй известной операции

проверяй на обоих серверах

вообще я бы особо не парился, если у тебя CSRS

2-3 секунды — фигня

у меня не шард

или я не понял о чем ты

а, если не шард, тогда вообще забей

Хм.

{ "v" : 1, "key" : { "track_id" : 1 }, "name" : "track_id_1", "ns" : "drm.track_restrictions", "background" : true, "uniqueue" : true },что это такое ?

"uniqueue" : true

а данные неуникальны

oonequeue

unique

мне казалось они пишет unique

кажется.

а не uniqueue

А такого слова нет.

в природе

а что это за дерьмо такое

{ "v" : 1, "key" : { "track_id" : 1 }, "name" : "track_id_1", "ns" : "drm.track_restrictions", "background" : true, "uniqueue" : true },что это такое ?

не знаю

это вывод чего?

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

341

это вывод getIndexes()

o_o

https://github.com/mongodb/mongo/search?utf8=✓&q=uniqueue

аха

и в жире таже херня

я уже даже подумал что это локально, но нет.

*локаль

"errmsg" : "The field 'uniqueueue' is not valid for an index specification. Specification: { ns: \"test.foo\", key: { foo: 1.0 }, name: \"foo_1\", uniqueueue: 2.0 }",

ну короче левый аргументы не прокатывают

{ "v" : 1, "unique" : true, 3.2.11

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

да

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

клиент тут ваще нипричём

он показывает прст ответ из монги

mongo --version MongoDB shell version v3.4.1 git version: 5e103c4f5583e2566a45d740225dc250baacfbd7 OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013 allocator: tcmalloc modules: none build environment: distmod: rhel70 distarch: x86_64 target_arch: x86_64

он показывает прст ответ из монги

ну он вполен может что-то подменять

ну он вполен может что-то подменять

неа

не положено

не положено

не положено - не значит не может

плюс смысла в этом нет. весь протокол это просто обмен bson документами между клиентом и сервером

{ "v" : 1, "unique" : true, 3.2.11

в 3.4.1 тоже unique)

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

очень интересно откуда это

это вывод getIndexes()

ты сам его сделал?

https://hastebin.com/warekiraqe.php

@ptchol а если сделать mongodump, то в метаданных что будет?

ну а кто

ммм. а куда посмотреть

дамп есть под рукой

dump/database/collection.metadata.json

может кто-то прикольнулся и подменяет вывод одной строки на другоу? модуль ядра там левый? =)

https://hastebin.com/oxodoborah.json

https://hastebin.com/warekiraqe.php

stats({indexDetails: 1})

эм

https://hastebin.com/oxodoborah.json

чёт его там вообще нет

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

и там другой вообще

"name": "track_id_1_match_id_1_territory_1_model_1", "name": "track_id_1_match_id_1_model_1_territory_1", vs "name" : "track_id_1", "name" : "track_id_1_meta_dt_1_computed_dt_1",

ты нас обманываешь!

а сорян

https://hastebin.com/zujadovowu.json

ну эт мы уже видели

сделай db.track_restrictions.stats({indexDetails: 1})

там в indexDetails.track_id_1.metadata.infoObj будет сырая мета

https://hastebin.com/noqaredoba.tex

uniqueue

лол

круто

нихера не круто.

много записей?

ладно бы он реально уником был, а нет.

ну да

дропни индекс и создай ещё раз

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

12м

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

ну 12м — хуйня

минут 10 пошуршит

так там получилось что записи дублирующие

и теперь уник индекс не создается

а

бида

ручками чистить.

Ладно, спасибо за помощь.

Логи хранятся?