yopp
если что в 3.6 была бага которая у пары компонентов не выключала потом log level обратно, не знаю, поправили ли её в 4.0
yopp
так что может быть немного больно если это бой
Alexey
спасибо большое, буду мониторить логи, разбираться, как только я возвращаю один сервер обратно, то они сразу же выбирают primary, хотя, казалось бы, конфиг SSH, где два сервера с одним и тем же приоритетом и голосами, и один hidden, который вообще голосовать не должен
yopp
Попробуйте воспроизвести проблему локально, например подняв кластер через mlaunch
yopp
Чтоб исключить ошибки в конфигурации. У вас точно конфиг применён и разъехался по всему кластеру?
Nick
Добрый день! Репликасет в конфигурации primary, secondary, secondary, hidden, если отваливаются два сервера, например, primary и secondary, оставшиеся два (secondary и hidden) не могут выбрать primary, у secondary priority: 1, votes: 1, у hidden - hidden: true, priority: 0, votes: 0, почему secondary не становится в таком случае primary? Заранее благодарю!
может даст больше понимания, чтобы кластер выбрал праймари надо (N+1)/2 живых нод с голосами, в вашем случае PSSH - три ноды с голосом, значит чтобы все работало нужно (3+1)/2 = 2 живых ноды. Соотвевенно когда вы оставляете SH, то имеете лишь одну ноды с голосом, а ее недостатчоно
Alexey
а, если это так, тогда все очевидно, а если я ввожу арбитра, то там уже без разницы? он сам принимает решение?
yopp
yopp
Nick
может реально проще арбитра
yopp
Если добавить арбитра без возвращения голоса скрытой реплике, то будет 4 голосующие ноды :)
Alexey
а почему, когда остаются SSH, т е две голосующие, они норм выбирают, если приоритеты одинаковые и голоса, или тут как повезет, могут и не выбрать?
Bandikoot
Nick
все связано со split brain, тут самое главное, что обе ноды знают что большая часть кластера доступна и дальше они могут выбрать лидера, хоть рендомно не столь важно.
Alexey
может быть подскажите хорошую конфигурацию серверов, а то я вычитал про PSSH, типа лучший вариант, удобные бекапы с H, и вообще все круто, может на деле есть лучшие варианты?
Alexey
хотя я понимаю, что вопрос, наверное, некорректный, так как все ситуационно
Alexey
просто может есть более менее сбалансированная проверенная схема
Nick
а вам реально нужно два секондари?
Nick
ну там вы читаете с них или как
Alexey
да, читаю, чтобы разгрузить primary
Alexey
а то у меня, в момент наплыва данных, а такое, из-за специфики проекта, происходит в 00 каждого часа, проседают все операции на чтение и на клиент заметно дольше отдает, поэтому решил разгрузить путем реплик
yopp
yopp
ваша проблема решается PSSHA и всем по votes: 1
yopp
но масштабирование через репликацию — опасная штука
yopp
по-умолчанию монга не надёт никаких гарантий консиснентности и в зависимости от того что у вас там с данными, вы можете читать устаревшие данные
yopp
если вы ещё и с нескольких секондарей читаете у вас вообще может быть дискач
yopp
вам нужно выбирать подходящий read concern
Alexey
где важные данные, я читаю с primary, от того, что клиент на пару минут позже увидит запись, ничего страшного
yopp
это работает если у вас append only данные
yopp
или если вы оперируете одним документом
yopp
если у вас данные мутабельные и вы читаете пачку документов, где в этой пачке какие-то документы могут мутироваться в процессе чтения, то в результате у вас может быть много неожиданностей
yopp
репликация не предназаначена для масштабирования, это HA/FT
yopp
если вы упираетесь в ресурсы, то более эффективно шардировать ваши данные
yopp
но это дорогое удовольствие, так как операционная сложность существенно возрастает
Alexey
так для шарда все равно реплика нужна, я и собирался раскидать в итоге по шардам с конфигом PSSHA или PSA
Alexey
а то, что будут проблемы с консистентностью, и надо будет расставлять нужные read concern, это да
Alexey
я понимаю, что чудес не бывает
Александр
Тут можно задавать вопросы касательно Mongoose? Есть Например 2 колекции пользователи и группы, в каждой группе есть array[user.id], а как мне знать в каких группах находится пользователь? мне нужно у пользователя хранить тоже id в каких группах он находится?
yopp
yopp
но бэкапы становятся большой болью
Alexey
сейчас будет тупой вопрос, но N это что за сервер?)
yopp
просто Node
Alexey
gjyzk
Alexey
понял
yopp
PSS это некорректный взгляд на топологию
Alexey
спасибо большое за уделенное время, в который раз уже помогаете!
Roman
массив в документе может быть индексом?
Roman
это что-то ускорит?
Roman
https://docs.mongodb.com/manual/core/index-multikey/index.html
Roman
да?
yopp
Roman
yopp
индексы можно строить по вложенным документам
yopp
но число ключей в индексе в этом случае будет равно числу элементов в массиве
Roman
все заработало в 3 раза быстрее
но не знаю надолго ли :D
yopp
Roman
yopp
это может быть как хорошо, так и очень плохо
Roman
посмотрим как будет вести себя на 3 миллионах документов
массивы маленькие вложенные, 2 - 4 элемента
Roman
спасибо
Roman
ближе к миллиону заметно долго стали исполняться запросы
rdcm
всем привет
у кого-нибудь была ситуация, что скажем maxPoolSize=300 переданный через коннекшн стринг, открывал сразу все 300 коннекшенов разом? для меня ожидаемое поведение, что драйвер будет инициализировать новые соединения, по мере возрастания его частоты использования
yopp
драйвер для какого языка?
rdcm
C# 2.7.0
Vova
C# 2.7.0
2.7.2 поставь, может если это баг то уже пофиксили
rdcm
перепроверил 2.7.2)
минорные обновы сложно запоминать
Viktor
если что - заводи тикет в их джиру
Viktor
https://jira.mongodb.org/projects/CSHARP/issues
yopp
первое что надо проверить, это на пустом проекте
yopp
потому что может так оказаться что все 300 соединений сразу и используются :)
rdcm
ох, придётся все варианты проверять, тут много точек отказа
rdcm
сходу на простом реплика сете не получилось воспроизвести
Vadim
Подскажите пожалуйста, как найти документ с объектом у которого больше двух ключей?
yopp
по значению ключей или именно по количеству?
Vadim
yopp
db.foobar.aggregate([
{
"$project": {
"count": {
"$size": {
"$objectToArray": "$$ROOT"
}
}
}
},
{ $match: { count: { $gte: 2 } } }
])
yopp
но это очень неэффективный способ
Vadim
Операция не частая, так что не страшно, большое спасибо
yopp
это _очень_ плохо