II. Hratky s Elasticem – Ruzna Sprava

Par dni zpatky jsem narazil bohuzel na diskove limity a ES me prestal indexovat novy data, protoze jsem se dostal na prilis nizkou hladinu volne kapacity. Do tohodle clanku si pridam ruzny admin prikazy, kteryma nejen tyto veci resim, abych to mel nekde pohromade 🙂

Zmena nastaveni replikace

Nejrychlejsi usporou mista je vypnuti replikace u indexu ktere nepotrebujeme, nebo docasne, nez se vyresi pripadne rozsireni clusteru

POST /comhost*/
{
  "settings": {
    "number_of_replicas": 0
  }
}

Zmena nastaveni limitu disku

Dalsi moznosti je upravit nastaveni limitu pri kterem ES uz nedovoli zakladat novy index, resp. data do nej:

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.disk.watermark.low": "15gb",
    "cluster.routing.allocation.disk.watermark.high": "10gb",
    "cluster.routing.allocation.disk.watermark.flood_stage": "10gb",
    "cluster.info.update.interval": "1m"
  }
}

Odblokovani zamceneho indexu

Kdyz uz dojde k zablokovani/zamceni indexu do Read-Only stavu kvuli mistu na disku, po naslednem uvolneni mista je potreba index odemknout:

PUT /indexname/_settings
{
     "index.blocks.read_only_allow_delete": null
}

Kdyz nam pocet vysledku v agregaci nestaci

Kdyz jsem potreboval zpracovat agregaci obrovskeho mnozstvi dat o velikosti nekolika milionu vysledku, zjistil jsem, ze aggs nemaji neco jako listovani. Pokud mame dostatecne vykonu, lze tedy upravit nastaveni kterym zvysime defaultni limit 10.000 buckets:

PUT _cluster/settings
{
  "persistent": {
    "search.max_buckets": 10000000
  }
}

Pokud mame hodne indexu, ale malo nodu clusteru

Pokud udrzujem napriklad denni logovani mnoha aplikaci po dobu nekolika mesicu, ci let, a ty mame rozlozeny po vice nodech vcetne vlastni replikace, muze nastat situace, ze dalsi index uz nevytvorime, nebot vycerpeme maximalni pocet shards (bloku) na jeden node. Zmenu nastaveni pak muzeme provest napriklad takto:

PUT /_cluster/settings
{
  "persistent": {
    "cluster": {
      "max_shards_per_node" : "128000"
    }
  }
}

Hodnota zde zadana by mela tak nejak odpovidat kapacitnim a vykonovym moznostem poctu nodu 🙂

Urychleni obnovy po padu

Kdyz uz nam to spadne, tak po nahozeni probiha automaticky recovery indexu. Bohuzel pokud je indexu mnoho, probiha obnova celkem pomalu. Muzeme ji tedy (v pripade dostatecnyho vykonu) uspisit naslednovne:

PUT /_cluster/settings
{
  "persistent": {
    "cluster": {
      "routing": {
        "allocation.node_concurrent_recoveries": 500,
        "allocation.node_concurrent_outgoing_recoveries" :500,
        "allocation.node_concurrent_incoming_recoveries" :500,
        "allocation.node_initial_primaries_recoveries": 500
      }
    }
  }
}

Kdyz mame velky dokumenty

Pokud mame velky dokumenty, a nevejdeme se do limitu HTTP POST requestu, muzeme jej navysit:

GET /_cluster/settings
{
  "http": {
    "max_content_length" : "1GB"
  }
}

Prilis mnoho hledani

Pokud mame nejaky aplikace ktery delaji velky objemy vyhledavani, narazime mozna i na limit poctu aktualne bezicich hledani. Ten lze upravit pak takto:

PUT /_cluster/settings
{
  "persistent": {
    "threadpool.search.queue_size": 1000
  }
}

Presunuti bloku mezi nody clusteru

presunuti se hodi pokud clovek potrebuje urychlene neco provest z nejakym nodem clusteru, nebo se mu nelibi jak ES rozhodil nody

POST /_cluster/reroute
{
  "commands": [
    {"move": {
      "index": "index",
      "shard": 19,
      "from_node": "es_data_9",
      "to_node": "es_data_20"
    }}
  ]
}

Pokus o obnovu dat ze zniceneho node clusteru

Bohuzel si uz nepamatuju presne situaci pri ktere se to da a neda pouzit, ale zachranilo me to tehdy pro me cenny data

POST /_cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "indexname",
        "shard": 1,
        "node": "es_data_1",
        "accept_data_loss": true
      }
    }
  ]
}