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"
}
}