ElasticSearch 運維

時間 2019-12-07

原文原文鏈接

ES 集羣升級或維護

當把 elasticsearch 版本從 2.0.0 升級到 2.1.1 的時候，客戶端徹底不可用，接口變化了，所以在升級的時候，須要客戶端也升級html
重啓整個 elasticsearch 集羣以前，須要把副本關閉掉，而後在集羣其中成功以後，再開啓副本功能node
重啓單個 data 節點須要作如下操做，可是這個只針對冷索引git
- 暫停數據寫入程序github
- 關閉集羣shard allocation算法
- 手動執行POST /_flush/syncedbootstrap
- 重啓節點api
- 從新開啓集羣shard allocation服務器
- 等待recovery完成，集羣health status變成greenapp
- 從新開啓數據寫入程序curl

刪除磁盤上的數據的話，會引發 shard 數據變成默認值，由於只有在初始化的時候纔會設置，因此刪除後，手工進行初始化便可

中止全部的 ES 節點
中止客戶端的數據寫入
啓動全部的 ES 節點
初始化 shard 數

啓動客戶端的數據寫入

// 手動初始化 template

http://ip/_plugin/kopf/#!/indexTemplates

"template": "trace*",
  "settings": {
    "index": {
      "number_of_shards": "3",
      "number_of_replicas": "1"
    }
  },
  "mappings": {
    "test": {
      "_source": {
        "includes": [
          "traceId"
        ]
      },
      "properties": {
        "traceId": {
          "type": "string"
        },
        "binaryAnnotations": {
          "search_analyzer": "linieAnalzyer",
          "analyzer": "linieAnalzyer",
          "index": "analyzed",
          "type": "string"
        },
        "app": {
          "index": "not_analyzed",
          "type": "string"
        },
        "duration": {
          "type": "long"
        },
        "suc": {
          "type": "string"
        },
        "bizAnnotations": {
          "index": "not_analyzed",
          "type": "string"
        },
        "host": {
          "index": "not_analyzed",
          "type": "string"
        },
        "id": {
          "type": "string"
        },
        "serviceId": {
          "index": "not_analyzed",
          "type": "string"
        },
        "spanName": {
          "type": "string"
        },
        "timestamp": {
          "type": "long"
        }
      }
    }
  },
  "aliases": {
 
  }

中止 data 節點，shard 分配時間恢復，集羣數據量大概是 1.26TB
- 中止1個節點，恢復時間大概是20分鐘
- 中止2個節點，恢復時間大概是55分鐘
- 中止3個節點，恢復時間大概是100分鐘
- 中止5個節點，恢復時間大概是120分鐘

ElasticSearch 使用經驗

ES_HEAP_SIZE 使用不要超過物理內存的一半，最好不要超過 30.5 G
設置 vm.swappiness = 1
在 elasticsearch.yml 中設置 bootstrap.mlockall: true
官方推薦垃圾回收算法針對 ES 應該設置 CMS
search 的 theadpool 推薦設置爲 cores * 3，其餘線程池推薦和 cores 數量相等
disk I/O 的線程是有 Lucene 處理的，而不是 ES
設置 vm.max_map_count=262144 用於 mmapped files 的虛擬內存
修改配置請使用 API，API，API，而不是修改配置，修改 API 有兩種方式，一種臨時的，一種持久的，臨時的修改當節點下次重啓的時候會失效，永久的當下次重啓的時候會覆蓋靜態配置
```
curl -XPUT ip:9200/_cluster/settings -d
'{
    "transient": {
        "logger.discover": "DEBUG" 
    }
    "persistent": {
        "discovery.zen.minimum_master_nodes": 2
    }
}'
```
設置 slowlog 的閥值有利於定位問題，能夠設置 queries, fetches, indexing 的 slowlog
若是你的集羣是偏重於 indexing，而對 search 的性能要求不是毫秒級別的返回，能夠作些設置作平衡。
Bulk size 比 documents 數量重要，好比 5-15 MB 每一個 bulk
磁盤，首選 SSD，沒有 SSD 的話，可使用RAID0
path.data 配置多個路徑
避免 segment merging ，當發生的時候， ES 會自動 throttle index 請求到單個線程，當你使用 SSD 的時候，默認的限制 20MB/s 過小了，能夠設置成 100-200MB/s
若是在作一個大的 bulk import，能夠設置 index.number_of_replicas：0，等到插入完成的時候，再進行 replicas
在升級或者作其餘維護須要重啓服務器的時候，請保持 ES master 節點是可用的，而後一臺臺重啓 data 節點，最好是能夠經過 api 先禁止 shard 分配，若是能夠中止 indexing 新數據最好（可是這是不可能的）
- 執行命令禁止 allocation
```
PUT /_cluster/settings
{
    "transient": {
        "cluster.routing.allocation.enable": "none" 
    }
}
```
- 使用 shutdown api 中止一個節點
```
POST /_cluster/nodes/_local/_shutdown
```
- 執行升級或者維護
- 重啓節點，確認加入了集羣
- 啓動 shard allocation
```
PUT /_cluster/settings
{
    "transient": {
        "cluster.routing.allocation.enable": "all" 
    }
}
```
- 其餘節點重複1到5步驟
使用 snapshot API 備份，建議備份到 HDFS 中，而後使用 _restore API 來恢復備份。
經過設置 action.disable_delete_all_indices: true. 來禁止經過 API 刪除全部索引
indices.fielddata.cache.size: 25% ，在 datanode 設置 indices.cluster.send_refresh_mapping: false

cluster.routing.allocation.cluster_concurrent_rebalance:2 最好設置低一些，這樣不會影響索引

cluster.routing.allocation.disk.threshold_enabled:true
cluster.routing.allocation.disk.watermark.low:.97
cluster.routing.allocation.disk.watermark.high:.99

恢復：

cluster.routing.allocation.node_concurrent_recoveries:4
cluster.routing.allocation.node_initial_primaries_recoveries:18
indices.recovery.concurrent_streams: 4
indices.recovery.max_bytes_per_sec: 40mb