Зупинка служби та вбивство демона - справді правильні способи вимкнення вузла. Однак не рекомендується робити це безпосередньо, якщо ви хочете зняти вузол для обслуговування. Насправді, якщо у вас немає реплік, ви втратите дані.
Коли ви безпосередньо вимикаєте вузол, Elasticsearch зачекає 1 хв (час за замовчуванням), щоб він повернувся до мережі. Якщо цього не сталося, він почне розподіляти осколки з цього вузла на інші вузли, що витрачають багато IO.
Типовим підходом було б тимчасово відключити розподіл осколків, видавши:
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "none"
}
}
Тепер, коли ви знімаєте вузол, ES не намагатиметься розподіляти осколок з цього вузла в інші вузли, і ви зможете виконувати операції технічного обслуговування, а після того, як вузол буде запущений, ви зможете знову ввімкнути розподіл осколка:
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.enable": "all"
}
}
Джерело: https://www.elastic.co/guide/en/elasticsearch/reference/5.5/restart-upgrade.html
Якщо у вас немає реплік для всіх ваших індексів, тоді виконання цього виду діяльності матиме простої в деяких індексах. Більш чистим способом у цьому випадку було б перенести всі осколки на інші вузли перед тим, як зняти вузол:
PUT _cluster/settings
{
"transient" : {
"cluster.routing.allocation.exclude._ip" : "10.0.0.1"
}
}
Це призведе до переміщення всіх осколків 10.0.0.1
до інших вузлів (це займе час залежно від даних). Як тільки все буде зроблено, ви можете вбити вузол, виконати технічне обслуговування та повернути його в Інтернет. Це більш повільна операція і не потрібна, якщо у вас є репліки.
(Замість _ip, _id, _name з узагальнюючими символами буде працювати чудово.)
Більше інформації: https://www.elastic.co/guide/en/elasticsearch/reference/5.5/allocation-filtering.html
Інші відповіді пояснюють, як вбити процес.