Привет всем! Нужна помощь с шардированной mongodb. Ситуация такая: Имеются 4

рабочие шарды c размером одной из баз около 2TB, т.е. по 500 Гигов на шарду.
Потребовалось добавить 5ю шарду и тут возникла проблема с долгой балансировкой. За 1 месяц перенеслось около 15% . Вопрос в след. нормальная ли данная ситуация? либо есть проблема которую я не вижу?
mongos> sh.status()
--- Sharding Status ---
sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("5fb65dda1d6aedfdh23832")
}
shards:
{ "_id" : "1_shard", "host" : "1_shard/m1.shard.ru:28100,m2.shard.ru:28100", "state" : 1 }
{ "_id" : "2_shard", "host" : "2_shard/m2.shard.ru:28200,m3.shard.ru:28200", "state" : 1 }
{ "_id" : "3_shard", "host" : "3_shard/m3.shard.ru:28300,m4.shard.ru:28300", "state" : 1 }
{ "_id" : "4_shard", "host" : "4_shard/m4.shard.ru:28400,m5.shard.ru:28400", "state" : 1 }
{ "_id" : "5_shard", "host" : "5_shard/m1.shard.ru:28500,m5.shard.ru:28500", "state" : 1 }
active mongoses:
"4.4.1" : 5
"4.4.2" : 1
autosplit:
Currently enabled: yes
balancer:
Currently enabled: yes
Currently running: yes
Collections with active migrations:
ebase.Message started at Tue Oct 25 2022 11:08:30 GMT+0300 (MSK)
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
21 : Success
17 : Failed with error 'aborted', from 2_shard to 5_shard
677 : Failed with error 'aborted', from 1_shard to 5_shard
databases:
{ "_id" : "config", "primary" : "config", "partitioned" : true }
config.system.sessions
shard key: { "_id" : 1 }
unique: false
balancing: true
chunks:
1_shard 205
2_shard 205
3_shard 205
4_shard 205
5_shard 204
too many chunks to print, use verbose if you want to force print
{ "_id" : "ebase", "primary" : "4_shard", "partitioned" : true, "version" : { "uuid" : UUID("den6c870-a8b7-446d-9894-66b80ddd1d07"), "lastMod" : 1 } }
ebase.Message
shard key: { "_id" : "hashed" }
unique: false
balancing: true
chunks:
1_shard 32725
2_shard 32725
3_shard 32723
4_shard 32723
5_shard 4695
too many chunks to print, use verbose if you want to force print
{ "_id" : "test", "primary" : "3_shard", "partitioned" : false, "version" : { "uuid" : UUID("94d782h0-a8c2-4129-ad27-a60e9fsd1fe6"), "lastMod" : 1 } }

Увы, это нормальная ситуация

хм. спасибо, получается по моим расчетам данные сбалансируются через 6 месяцев. Это очень больно.

А можно поинтересоваться железом существующего кластера, и сетью и железом до нового сервера. А то прям совсем грустные показатели.

Я правильно понимаю, что за месяц «кластер» вычитал 300 гигабайт(помножить еще на сколько ну 5-6, данные сжатые) и «перераспределил» эти несколько террабайт сырых данных. Но это вообще прям печаль.

Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz 8 X 32 GB DDR4 ECC RAM 2 × 960 GB SATA SSD LAN 1GBit

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

и самой важной инфы про диск нет, какой диск, какая скорость записи/чтения ))) хостинги как обычно хитрят

два в аппаратном рэйде 0 === START OF INFORMATION SECTION === Model Family: Toshiba HK4R Series SSD Device Model: TOSHIBA THNSN8960PCSE Serial Number: 17ES101MTB1V LU WWN Device Id: 5 00080d 9105934ca Firmware Version: 8EET6101 User Capacity: 960 197 124 096 bytes [960 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Form Factor: 2.5 inches TRIM Command: Available, deterministic, zeroed Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-3 (minor revision not indicated) SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Tue Oct 25 15:19:46 2022 MSK SMART support is: Available - device has SMART capability. SMART support is: Enabled

Пожалуйста, воздержитесь от высказываний формата «дело в руках». Это неконструктивно Ребалансировка достаточно сложная операция, с почти десятком стадий. Одна из сложностей это момент синхронизации между донором и реципиентом, которая требует координации между тремя компонентами. Если переносимыый чанк меняется, монге может потребовать достаточно много времени на его перенос. Скорость балансировки от «рук» не зависит, так как настроек которыми можно что-то в балансировке изменить — нет. В протоколе постепенно что-то меняют в лучшую сторону, но для того чтоб ситуация улучшилась нужно обновлятся до последней стабильной версии. Недели на ребалансировку больших объёмов, к сожалению, ожидаемое поведение. В некоторой степени скорость может зависеть от того, упирается ли монга в ресурсы (диск/сеть/цпу) и насколько большой лаг репликации. Если мне память не изменяет, то при миграции чанков используется writeConcern > 1 (или majority?). Где-то была ручка которой можно его понизить, но это не самый безопасный способ

пардон, я не увидел что один и тот же человек отвечает согласен

Anton
Метрики по железу в разрезе недели. Еще забыл упом...

То есть минимум свободной памяти 50%?

Да. это плохо? там закэшировано 140 гб top одного из серверов MiB Mem : 257672,8 total, 1601,5 free, 115275,3 used, 140796,0 buff/cach

Anton
Метрики по железу в разрезе недели. Еще забыл упом...

я сейчас заметил что me5 (новая шарда) упирается в диск. Либо это нормальная ситуации при балансировки.

ну логически, как она упирается в диск, если у вас по сети загрузка - очень маленькая, от чего и каких данных она может "упираться". Я про cache wiredtiger справшивал, https://www.mongodb.com/docs/manual/core/wiredtiger/

можно глянуть, например, iotop — посмотреть кто диск дёргает

в топе 90% [kworker/u72:2+flush-8:0] и mongodb 90%

а сервер свой, в клауде, реальное железо? Я сейчас посмотрел на свои, 1 в яндексе тоже 2 tb sdd, и на свой из реального железа микро сервер, 2 tb nvme - и на тот и на другой клиенты из клауда пишут одни и те же данные(просто дублируется информация). так вот на сервере от яндекса, существенно видно нагрузка по iotop от mongo до 90%, а реальный ее не замечает просто...

хм, интересно... Да, у нас дэдики в хетснери.

это только предположение

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

я думаю, что такую разницу дает реальный nvme и какой-то “ssd” от яндекса.

Нет, не плохо, даже наоборот :) История тут простая: Лимит в 50% системной памяти ограничивает только размер кэша для документов. Монга может запросить больше памяти под другие нужды, например буферы для сортировок, агрегации и тд В кэше документы находятся as is и не сжимаются. Т.е условные 16гб документов занимают 16гб в кэше. На диске данные хранятся уже в сжатом виде. Условные 16гб, будут занимать например 8гб. Когда монга пишет/читает с диска, то ОС использует «свободную» память для кеширования io операций. А значит что в дисковом кэше документы будут храниться уже в сжатом виде. Те самые 8гб. Т.е если увеличить размер памяти который доступен монге под кэш, то уменьшается размер дискового кэша и уменьшается количество закешированных в памяти данных. Плюс дисковый кэш управляется ОС и она может эту память выделять другим процессам.

Anton
Метрики по железу в разрезе недели. Еще забыл упом...

У вас не хватает пропускной способности дисковой системы. iostat-x даст чуть больше информации. Самый простой вариант это заменить SATA на приличный NVME. Плюс перейти на zstd или zlib сжатие. У вас много свободного процессорного времени, затраты на компрессию не будут играть роли