Czasem trzeba zrobić rolling restart w klastrze Elasticsearch - wymienić sprzęt, zaktualizować wersję lub przenieść shardy na nowy węzeł. Bez odpowiedniego przygotowania proces może trwać długo i generować dużo niepotrzebnego ruchu.
Poniżej opisuję, co robię, żeby przyspieszyć restart i ograniczyć ruch shardów.
Wyłączanie alokacji shardów podczas restartu#
Żeby uniknąć niekontrolowanego przemieszczania shardów w trakcie restartu węzła, wyłączam alokację replik. Klaster wtedy nie zaczyna od razu przesuwać danych, co pozwala na kontrolowany proces restartu.
PUT _cluster/settings
{
"persistent": { "cluster.routing.allocation.enable": "primaries" }
}
Po zakończeniu restartu przywracam domyślne ustawienie:
PUT _cluster/settings
{
"persistent": { "cluster.routing.allocation.enable": null }
}
Opóźnienie reakcji klastra (delayed timeout)#
Domyślnie Elasticsearch od razu po utracie węzła zaczyna rebalansować shardy, co generuje zbędny ruch, jeśli węzeł szybko wróci. Zwiększam timeout, żeby dać czas na ewentualny powrót węzła.
PUT _all/_settings { "index.unassigned.node_left.delayed_timeout": "5m"}
Flush przed restartem#
Wykonuję flush, żeby zapisać segmenty na dysk i przyspieszyć późniejsze odzyskiwanie shardów.
POST /_flush
Restart node po node#
Restart wykonuję pojedynczo dla każdego węzła:
- Wyłączam alokację shardów (patrz wyżej)
- Robię flush
- Restartuję węzeł
- Przywracam alokację shardów (
null) - Czekam na status klastra green
- Powtarzam dla kolejnego węzła
Tuning recovery shardów#
Jeśli infrastruktura pozwala, zwiększam liczbę równoczesnych recovery i limit przepustowości, żeby skrócić czas odtwarzania shardów.
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.node_concurrent_recoveries": 15,
"indices.recovery.max_bytes_per_sec": "2000mb"
}
}