У меня есть коллекция, в которой ключ сегментирования - UUID (шестнадцатеричная строка). Коллекция огромна: 812 миллионов документов, около 9600 чанков на 2 шарда. По какой-то причине я изначально хранил документы, у которых вместо UUID было целое число в поле ключа сегментирования. Позже я удалил их полностью, и теперь все мои документы сегментированы по UUID. Но теперь я столкнулся с проблемой распределения фрагментов. Хотя у меня были документы с целым числом вместо UUID, балансировщик создал около 2700 блоков для этих документов и оставил их все на одном осколке. Когда я удалил все эти документы, чанки не были удалены, они остались пустыми и всегда будут пустыми, потому что сейчас я использую только UUID. Поскольку балансировщик распределяет фрагменты, полагаясь на количество фрагментов на сегмент, а не на количество или размер документов, один из моих сегментов занимает в 3 раза больше дискового пространства, чем другой:
--- Sharding Status ---
db.click chunks:
set1 4863
set2 4784 // 2717 of them are empty
set1> db.click.count()
191488373
set2> db.click.count()
621237120
Печально то, что mongodb не предоставляет команд для удаления или объединения фрагментов вручную. Мой главный вопрос: может ли что-нибудь из этой работы избавиться от пустых кусков:
Остановите балансир. Подключитесь к каждому серверу конфигурации, удалите из
config.chunks
диапазонов пустых фрагментов, а также зафиксируйтеminKey
фрагмент, чтобы он заканчивался в начале первого непустого фрагмента. Запустите балансировщик. Кажется рискованным, но, насколько я понимаю,config.chunks
- единственное место, где хранится информация о чанках.Остановите балансир. Запустите новый экземпляр mongod и подключите его как третий осколок. Вручную переместите все пустые фрагменты в этот новый осколок, а затем закройте его навсегда. Запустите балансировщик. Не уверен, но пока я больше не использую целочисленные значения в ключе сегментирования, все запросы должны выполняться нормально.