Прежде всего, давайте посмотрим, почему это произошло. При индексации в elasticsearch используется репликация на уровне документов - то есть каждый документ индексируется сначала на праймари, а потом на всех репликах. И хотя праймари и реплики содержат одинаковый набор документов, из-за независимой индексации, эти документы хранятся в разных файлах. При перезагрузке, репликация между шардами переходит на файловый режим и из-за того, что файлы отличаются, elasticsearch вынужден скопировать все файлы из каждой шарды в ее реплику. Если ноды не перегружались долго - то возможно пришлось скопировать весь Тб, так как все файлы были разные.
Судя по allocation/explain для первой шарды она уперлась в лимит на количество одновременных восстановлений:
"deciders": [
{
"decider": "throttling",
"decision": "THROTTLE",
"explanation": "reached the limit of incoming shard recoveries [505], cluster setting [cluster.routing.allocation.node_concurrent_incoming_recoveries=500] (can also be set via [cluster.routing.allocation.node_concurrent_recoveries])"
}
Вы пытались улучшить этот процесс, увеличением числа одновременных восстановлений до 500, но вместо этого вы все затормозили создав толпу из 500 одновременных восстановлений, которые ломанулись через вашу сеть и столкнулись с ограниченными возможностями одного диска на чтение и запись и внутренних систем. 500 - это слишком много. Надо было оставить около 20 или даже 10 и посмотреть что там происходить, что вы и сделали в ручную. Того же результата можно было добиться уменьшив concurrent_recoveries до 10.
Копировать 500 файлов одновременно с одного диска на другой не имеет никакого смысла. Оно только замедляет копирование каждой индивидуальной шарды и производит впечатление, что все застряло. Если у вас диска на второй ноде HDD то все эти файлы - просто борются за управление головкой диска и все замедляется для всех.
Отсюда вопрос, почему так? я уперся в потолок?
Все перечисленное выше должно было все затормозить. Однако, если все совсем встало, то скорее всего вы столкнулись с этим багом. Если количество одновременных восстановлений превышает размер пула потоков GENERIC то это может вызвать взаимною блокировку потоков восстановления. В вашем случае, размер этого пула - 4*8СPUs = 32. То есть, в вашей системе установка одновременных восстановление больше 32 может привести к проблемам.
В будущем, перед тем, как перегружать ВМ, если будет возможность, запустите synced_flush. Это операция пометить все праймри и шарды как синхронизированы и предотвратит задержки при перезагрузке.