Elasticsearch 索引管理
索引壓縮
執(zhí)行索引壓縮的步驟
創(chuàng)建索引
## create index
PUT idx_tobe_shirink_001
{
"settings": {
"number_of_shards": 10,
"number_of_replicas": 10
}
}
壓縮前準備
壓縮前準備工作
副本0; 禁止寫; 必須同一個node
從這幾點能看出其背后的一些限制
PUT idx_tobe_shirink_001/_settings
{
"number_of_replicas": 0,
"index.blocks.write": true,
"index.routing.allocation.require._name":"node158"
}
壓縮索引
# 壓縮索引(內(nèi)部原理:重建索引)
POST _reindex
{
"source": {
"index": "idx_tobe_shirink_001"
},
"dest": {
"index": "idx_shirinked_001"
}
}
查看設置
是否生效或者有沒有其他限制
GET idx_tobe_shirink_001/_settings
執(zhí)行 - 索引壓縮
POST /idx_tobe_shirink_001/_shrink/idx_shirinked_001
{
"settings": {
"index.number_of_replicas": 1,
"index.number_of_shards": 5,
"index.codec": "best_compression",
"index.routing.allocation.require._name": null
}
}
寫數(shù)據(jù)前把禁止寫開關去掉
PUT idx_shirinked_001/_settings
{
"index.blocks.write": false
}
寫入數(shù)據(jù)
POST idx_shirinked_001/_doc
{
"key1": "value1"
}
查看寫入數(shù)據(jù)
GET /idx_shirinked_001/_search
{
"query": {
"match_all": {}
}
}
索引壓縮原理
實際上是壓縮的分片，并非在原有索引上壓縮，而是生成了一個新的索引，由于使用了 hash 路由算法以及索引不可變的特性
- 創(chuàng)建一個新的目標索引，其定義與源索引相同，但分片數(shù)量較少。
- 將段從源索引硬鏈接到目標索引。如果文件系統(tǒng)不支持硬鏈接，則將所有segment file都復制到新索引中，復制過程很耗時。
- shard recovery 操作，恢復目標索引。
- 要壓縮的索引必須是只讀
- target index的所有p shard必須位于同一節(jié)點。
- 索引的健康狀態(tài)必須為 green
- target index不能已存在
- target index分片數(shù)量必須為source index的約數(shù)。比如source index p shard：12,那么target index p shard只能是6 4 3 2 1，如果比如source index p shard是質(zhì)數(shù)，那target index p shard只能是1。
- 索引的 doc 數(shù)量不能超過 2 147 483 519個，因為單個分片最大支持這么多個doc。
- 目標節(jié)點所在服務器必須有足夠大的磁盤空間。
- target index name必須滿足一下條件
- 僅小寫
- 不能包括****，/，，?，"，<，>，|，``（空格字符）， ,，#*
- 7.0之前的索引可能包含冒號（:），但已過時，并且在7.0+中不支持
- 不能為**.或…**
- 不能超過255個字節(jié)（請注意它是字節(jié)，因此多字節(jié)字符將更快地計入255個限制）
- 不建議使用以**.**開頭的名稱，但隱藏索引和由插件管理的內(nèi)部索引 除外
# 設置為使索引和元數(shù)據(jù)只讀
index.blocks.read_only：true
# 禁止索引讀操作
index.blocks.read：true
# 禁止寫索引
index.blocks.write ：true
遷移數(shù)據(jù)時，可以指定節(jié)點
"index.routing.allocation.require._name": "target_node",
關閉的索引被阻止進行讀/寫操作，并且不允許打開的索引允許的所有操作。無法索引文檔或在封閉索引中搜索文檔。這允許封閉索引不必維護用于索引或搜索文檔的內(nèi)部數(shù)據(jù)結構，從而減少集群的開銷。
在打開或關閉索引時，master 負責重新啟動索引分片以反映索引的新狀態(tài)。然后分片將經(jīng)歷正常的恢復過程。打開/關閉索引的數(shù)據(jù)由集群自動復制，以確保始終安全地保留足夠的分片副本。
常見的索引操作
判斷索引是否存在
HEAD <index>
打開索引
POST <index>/_open
關閉索引
適用不允許索引寫入的場景
POST <index>/_close
創(chuàng)建索引
覆蓋更新創(chuàng)建
_doc 沒有創(chuàng)建，有則更新
PUT test_index_create/_doc/1
{
"k1": "v1"
}
## 后邊index id是可選項，不指定系統(tǒng)生成
## _doc這種方式，如果存在會更新
POST test_index_create/_doc[/index_id]
{
"test_post_create":"test_post_create"
}
后邊的數(shù)字1，表示索引的ID，如果不指定，系統(tǒng)會生成一個
創(chuàng)建索引及插入數(shù)據(jù)
POST test_index_create/_create/your_record_id
{
"key1": 'vale1'
}
## 如果索引id存在則報錯
查詢索引
HEAD test_index_create
GET test_index_create
刪除索引
DELETE test_index_create
插入索引
_update
_update_by_query
_upseart
_script
flush索引
DELETE test_idx_delay
PUT test_idx_delay
{
"settings":{
"refresh_interval": "30s"
}
}
## 覆蓋寫入 1表示id
PUT test_idx_delay/_doc/1
{
"key1": "val1"
}
## 增加寫入，自動生成id
POST test_idx_delay/_doc
{
"key1111": "val1111"
}
##立刻刷新寫入
POST test_idx_delay/_doc?refresh
{
"key1111": "val1111"
}
## 立刻刷新，把延遲寫入立刻刷新
POST test_idx_delay/_refresh
GET test_idx_delay/_search
refresh行為會立即把緩存中的文檔寫入segment中,但是
此時新創(chuàng)建的segment是寫在文件系統(tǒng)的緩存中的。如果出現(xiàn)斷電等異常,那么這部分數(shù)據(jù)就丟失了。所以es會定期
執(zhí)行flush操作,將緩存中的segment全部寫入磁盤并確保寫入成功,同時創(chuàng)建一個commit point,整個過程就是一個完整的commit過程必須從memorybuffer->segment->os cache中才能被看到
index.translog.durability:同步還是異步,默認fsync
index.translog.sync_interval:translog的同步間隔,默認5s
index.translog.flush_threshold_size: 512mb
索引別名
別名作用
官方描述
索引別名是用于引用一個或多個現(xiàn)有索引的輔助名稱。大多數(shù) Elasticsearch API 接受索引別名來代替索引。
Elasticsearch 中的 API 在處理特定索引時接受索引名稱，并在適用時接受多個索引。索引別名 API 允許使用名稱為索引設置別名，所有 API 都會自動將別名轉(zhuǎn)換為實際的索引名稱。一個別名也可以映射到多個索引，當指定它時，別名會自動擴展為別名索引。別名也可以與搜索時自動應用的過濾器和路由值相關聯(lián)。別名不能與索引同名。
傻瓜式描述
第一點、別名可以隱藏真正索引
如果可以隱藏的話，那么后續(xù)能做的事情就很多了
隱藏真正索引安全只是一方面，另一方面是可以類比域名，索引別名也可以綁定不同的真實索引，那么問題來了綁定不同索引有什么用呢？
比如按照時間、空間、數(shù)量進行滾動創(chuàng)建的索引，比如你規(guī)定客戶只能查詢當月的數(shù)據(jù)，這時候你就可以通過綁定當月索引進行強制限制數(shù)據(jù)訪問范圍。
查看索引信息：
GET test_idx_delay/_search
GET test_idx_delay/_mapping
GET test_idx_delay/_settings
GET test_idx_delay/_alias
保護索引
索引相對于調(diào)用者是隱藏的。
語法
POST /_aliases
基本用法
## 插入數(shù)據(jù)的一種寫法
POST /_bulk
{ "index": { "_index": "test_idx_delay", "_id": "1" }} ## 表示插入哪個索引的哪個doc
{ "name": "iphone" ,"desc" : "good"} ## 表示插入的數(shù)據(jù)
cmd+問號
## 官方文檔地址： https://www.elastic.co/guide/en/elasticsearch/reference/7.17/indices-aliases.html
## add aliase
POST _aliases
{
"actions": [
{
"add": {
"index": "test_idx_delay",
"alias": "test_idx_delay_alias"
}
}
]
}
## remove aliase
POST _aliases
{
"actions": [
{
"remove": {
"index": "test_idx_delay",
"alias": "test_idx_delay_alias"
}
}
]
}
## query alias
GET test_idx_delay/_alias
POST /_aliases
{
"actions" : [
{ "remove" : { "index" : "test_idx_delay", "alias" : "test_idx_delay_aliase1" } },
{ "add" : { "index" : "test_idx_delay", "alias" : "test_idx_delay_aliase1" } }
]
}
一個索引綁定多個別名
POST /_aliases
{
"actions" : [
{ "add" : { "index" : "product", "alias" : "product_real2" } },
{ "add" : { "index" : "product2", "alias" : "product_real2" } }
]
}
別名配置過濾器，使用PUT命令
使用PUT 上面用的是POST
PUT /test
{
"aliases": {
"alias_1": {},
"alias_2": {
"filter": {
"term": { "user.id": "kimchy" }
}
}
}
}
完整流程腳本
# 創(chuàng)建索引
POST test_idx_tobe_aliased/_doc
{
"username":"tom"
}
#對已有索引創(chuàng)建別名
POST _aliases
{
"actions": [
{
"add": {
"index": "test_idx_tobe_aliased",
"alias": "test_idx_aliase"
}
}
]
}
## 創(chuàng)建索引時指定別名
PUT /test_idx_tobe_aliased01
{
"aliases": {
"test_idx_aliased_01": {
"filter": {
"term": {
"user.age": "30"
}
}
}
}
}
# 插入數(shù)據(jù)
POST test_idx_tobe_aliased/_doc/1
{
"test_post_create":"test_post_create"
}
## 插入數(shù)據(jù)2
POST test_idx_tobe_aliased/_create/3
{
"user.id": "lily",
"age":4
}
GET test_idx_tobe_aliased/_search
GET test_idx_tobe_aliased/_alias
## 根據(jù)索引別名查詢數(shù)據(jù)
GET /test_idx_aliase/_search
{
"query": {
"match_all": {}
}
}
## 根據(jù)索引查詢數(shù)據(jù)
GET /test_idx_tobe_aliased/_search
{
"query": {
"match_all": {}
}
}
注意
- 一個索引可以綁定多個別名，一個別名也可以綁定多個索引
- 別名不能和索引名相同
滾動索引：rollover index
觸發(fā)條件
- max_age：時間閾值
- max_docs：文檔數(shù)閾值
- max_size：空間閾值
誰負責執(zhí)行？
_rollover
它的原理是不斷創(chuàng)建索引，然后把新創(chuàng)建的索引和索引別名進行關聯(lián)
注意整個過程索引別名是不變的
內(nèi)部怎么執(zhí)行的？
todo 定時調(diào)度？No 手動執(zhí)行_rollover方法
語法
POST /<index_alias>/_rollover
{
"conditions": {
"max_age": "7d",
"max_docs": 2,
"max_size": "5gb"
}
}
存在什么問題
無法把mapping信息帶過去
如何解決？
需要定義索引模板
完整案例
# 滾動索引 6位數(shù)字或者date,注意數(shù)字前只能-而不允許是_
# 主要是創(chuàng)建別名, 這個字段定義不知道什么作用
PUT test_rollover_log-000001
{
"mappings": {
"properties": {
"title":{
"type": "text",
"analyzer": "english"
}
}
},
"aliases": {
"test_rollover_alias": {}
}
}
# 刪除錯誤索引別名,注意這個不會刪除索引,只刪別名,指定索引只是表示要刪除這個索引的別名
POST /_aliases
{
"actions": [
{
"remove": {
"index": "test_rollover_log_000001",
"alias": "test_rollover_alias"
}
}
]
}
# 刪除索引
DELETE test_rollover_log-000001
# 查看是否刪除
HEAD test_rollover_log-000001
## 存入數(shù)據(jù)
PUT test_rollover_alias/_bulk
{"index":{}}
{"title":"t3"}
{"index":{}}
{"title":"t4"}
GET test_rollover_alias/_search
## 插入后需要刷新,否則延遲刷新不會立刻看到
POST test_rollover_alias/_refresh
# 設置滾動條件,為什么現(xiàn)在設置而不是定義時設置?
# 執(zhí)行一次僅創(chuàng)建和綁定一個,即使存在多個需要綁定的,多執(zhí)行幾次它會依次創(chuàng)建并綁定
POST /test_rollover_alias/_rollover
{
"conditions":{
"max_age": "7d",
"max_docs": 2,
"max_size": "1gb"
}
}
#-------------------rollover index test-------------------------
注意
ES 的寫入默認有延遲，可執(zhí)行手動刷新
POST logs_write/_refresh
索引模板
概念
官方解釋：索引模板是一種告訴Elasticsearch在創(chuàng)建索引時如何配置索引的方法。對于數(shù)據(jù)流，索引模板在創(chuàng)建時配置流的 backingDice。模板已配置創(chuàng)建索引之前. 創(chuàng)建索引時（無論是手動創(chuàng)建還是通過索引文檔），模板設置都將用作創(chuàng)建索引的基礎。
官方對于索引模板的解釋已經(jīng)比較清晰了，索引模板在企業(yè)生產(chǎn)實踐中常配合滾動索引（Rollover Index）、索引的生命周期管理（ILM：Index lifecycle management）、數(shù)據(jù)流一起使用。
我的解釋：
主要場景是： 你想某寫情況下創(chuàng)建的索引按照你的個性化設置創(chuàng)建，不要每次都手動設置屬性值。
這種情況下你就可以使用索引模板了。
具體做法是
- 你首先定義好設置模板
- 定義哪些索引使用這個模板，一般通過正則表達式
創(chuàng)建模板
PUT _index_template/test_zyy_template1
{
"index_patterns": ["test-zyy-rollover-*", "test-zyy-template*"],
"template": {
"settings": {
"number_of_shards": 1
},
"mappings": {
"_source": {
"enabled": true
},
"properties": {
"host_name": {
"type": "keyword"
},
"created_at": {
"type": "date",
"format": "EEE MMM dd HH:mm:ss Z yyyy"
}
}
},
"aliases": {
"test_alias_template1": { }
}
},
"priority": 500
}
更新模板
重新put一遍即可,跟創(chuàng)建語句一樣
刪除模板
DELETE /_index_template/test_zyy_template1
如何使用模板
當執(zhí)行任何創(chuàng)建模板的操作時會自動觸發(fā),根據(jù)正則匹配判斷創(chuàng)建的索引是否匹配.
創(chuàng)建模板的方式:
- _reindex
- _rollover
- PUT index_name
- POST index_name
## 驗證命中
PUT test-zyy-template22
GET test-zyy-template22/_mapping
## 驗證未命中
PUT test_zyy_not_template1
GET test_zyy_not_template1/_mapping
## POST創(chuàng)建測試
POST test_zyy_template2/_doc
{
"key":"val"
}
GET test_zyy_template2/_mapping
## _reindex 未命中測試
POST _reindex
{
"source": {
"index": "test_zyy_template2"
},
"dest": {
"index": "test_zyy_not_template3"
}
}
GET test_zyy_template2/_mapping
GET test_zyy_not_template3/_mapping
## _reindex 命中測試
POST _reindex
{
"source": {
"index": "test_zyy_template2"
},
"dest": {
"index": "test_zyy_template_reindex1"
}
}
GET test_zyy_template2/_mapping
GET test_zyy_template_reindex1/_mapping
## _rollover測試
忽略自己實驗吧
關于node roles
一個node就是一個elasticsearch實例.
每個node處理http和傳輸層流量,http由rest客戶端使用.傳輸層用于node之間通信.
node.roles在elasticsearch.yml文件中進行配置,"node.roles":["",""]
role幾種類型
master : 允許被選舉為master 而不是實際的master-
data: 通用數(shù)據(jù)角色. 存儲數(shù)據(jù)及執(zhí)行數(shù)據(jù)相關的操作CRUD/聚合等.數(shù)據(jù)節(jié)點對機器IO/CPU/內(nèi)幕才能要求較高. data_contentdata_hotdata_warmdata_colddata_frozeningestmlremote_cluster_clienttransform
在多層部署架構中，可以使用專用的數(shù)據(jù)角色將數(shù)據(jù)節(jié)點分配給特定的層級：data_content、data_hot、data_warm、data_cold或data_frozen。一個節(jié)點可以屬于多個層級，但具有專門的數(shù)據(jù)角色之一的節(jié)點不能具有通用的數(shù)據(jù)角色。
remote_cluster_client role 主要用于跨集群搜索和跨集群復制
es中 content tier.和 hot tier有什么區(qū)別于聯(lián)系
在Elasticsearch中，Content Tier和Hot Tier是存儲和處理數(shù)據(jù)的不同層級，具有不同的特點和功能。它們之間的區(qū)別和聯(lián)系如下：
區(qū)別：
- 數(shù)據(jù)類型：Content Tier主要用于存儲靜態(tài)內(nèi)容，如產(chǎn)品目錄或文章存檔等不經(jīng)常變化的數(shù)據(jù)。而Hot Tier主要用于存儲時間序列數(shù)據(jù)，包括最新和頻繁被查詢的數(shù)據(jù)。
- 性能需求：Content Tier節(jié)點在處理查詢時注重處理能力，優(yōu)化查詢性能和復雜搜索聚合的速度，通常使用較高的處理能力。而Hot Tier節(jié)點需要在讀寫方面都具備較高的速度，通常使用更快的存儲設備（如SSDs）來處理高頻查詢和索引操作。
- 數(shù)據(jù)保留期限：Content Tier通常用于長期保留數(shù)據(jù)，即使數(shù)據(jù)變舊，也需要快速檢索。Hot Tier主要保存最新的時間序列數(shù)據(jù)，隨著時間的推移，數(shù)據(jù)可能會從Hot Tier移動到其他層級。
聯(lián)系：
- 層級關系：Hot Tier通常作為數(shù)據(jù)流的入口層級，而Content Tier作為其他層級的基礎層級。新的數(shù)據(jù)流索引會自動分配到Hot Tier，而不屬于數(shù)據(jù)流的索引會自動分配到Content Tier。
- 數(shù)據(jù)冗余：為了提高容錯性，兩個層級中的索引都可以配置使用一個或多個副本。
- 分層存儲策略：Hot Tier用于存儲最新、頻繁被查詢的數(shù)據(jù)，而Content Tier用于存儲靜態(tài)內(nèi)容。通過將數(shù)據(jù)根據(jù)查詢頻率和重要性分配到不同的層級，可以實現(xiàn)更高效的存儲和查詢。
總的來說，Content Tier和Hot Tier在存儲和處理數(shù)據(jù)的方式上有所不同，但它們都是構建多層存儲和處理架構的重要組成部分，以滿足不同類型數(shù)據(jù)的需求和性能要求。
索引的生命周期管理
官方釋義
配置索引生命周期管理 (ILM) 策略，以根據(jù)性能、可伸縮性和保留要求自動管理索引。例如，使用 ILM 來：
- 當索引達到特定大小或文檔數(shù)量時啟動新索引
- 每天、每周或每月創(chuàng)建一個新索引并歸檔以前的索引
- 刪除過時的索引以強制執(zhí)行數(shù)據(jù)保留標準
通過 Kibana Management 或 ILM API 創(chuàng)建和管理索引生命周期策略。當為 Beats 或 Logstash Elasticsearch 輸出插件啟用索引生命周期管理時，會自動配置默認策略。
我的理解就是把不同數(shù)據(jù)放到不同索引,甚至放到不同節(jié)點,這樣提升查詢性能
生命周期的階段
-
Hot: The index is actively being updated and queried.
-
可以設置滾動閾值
hot階段是必須的,其他的階段是可選的
hot phase有個坑: rollover
這里指的是如果你想讓索引在hot階段待5min,你可以在hot設置rollover時間觸發(fā)條件為5min,然后warm階段設置data into為0,正常情況下沒問題.但是問題出在哪呢?rollover的觸發(fā)條件有3個,時間/空間/doc數(shù)量,哪個先觸發(fā)就先執(zhí)行哪個,比如5min和2個doc,如果doc先觸發(fā)就會提前導致新建索引導致hot沒有待夠5min. 如果必須要求時間可以把rollover關閉. 雖然各個階段的機制和rollover有點類似但是他們是同時執(zhí)行的.
-
Warm: The index is no longer being updated but is still being queried.
配置項:
move data into phase: 指的是上個階段(hot)多久移動到這個階段
另外還可以指定哪些node可以分配warm,這個可以通過role或者自定義屬性實現(xiàn)分配.如果通過role進行node選擇,hot role的node一定要增加data_content角色,否則不生效.但是同時要注意其余的節(jié)點千萬不要配置data_content,如果配置了,它不會優(yōu)先分配給hot role的node,而是會隨機選擇
-
那么問題來了,data和data_content分別什么作用?
-
Cold: The index is no longer being updated and is queried infrequently. The information still needs to be searchable, but it’s okay if those queries are slower.
-
Frozen: The index is no longer being updated and is queried rarely. The information still needs to be searchable, but it’s okay if those queries are extremely slow.
-
Delete: The index is no longer needed and can safely be removed.
每個生命周期都可以設置不同的行為
Frozen可以設置可搜索快照
如果使用kibana可視化配置,它支持直接導出 http請求
如何一直白嫖付費功能
先點擊適用,到時間之后,刪除data目錄
ILM: Index lifecicyle Management
注意幾個問題
- ilm一般用于數(shù)據(jù)流
- 如果不是數(shù)據(jù)流使用,那么默認會優(yōu)先分配data_content角色,即它不是優(yōu)先分給data_hot的角色,然后依次流轉(zhuǎn)的.知道這個點避免后續(xù)創(chuàng)建索引時迷惑
cold流轉(zhuǎn)frozen報錯
-
打開日志
-
PUT _cluster/settings { "persistent": { "indices": { "lifecycle":{ "poll_interval": "1s" } } ,"logger.org.elasticsearch.xpack.ilm": "TRACE" } } -
GET /*/_ilm/explain?error_trace=true -
PUT /_cluster/settings { "transient": { "logger.org.elasticsearch.xpack.core.indexlifecycle": "DEBUG", "logger.org.elasticsearch.xpack.indexlifecycle": "DEBUG", "logger.org.elasticsearch.xpack.core.ilm": "DEBUG", "logger.org.elasticsearch.xpack.ilm": "DEBUG" } } ### 可以修改為INFO DEBUG等 -
可能的原因:沒有創(chuàng)建repo
創(chuàng)建repo報錯
doesn't match any of the locations specified by path.repo because this setting is empty
這個錯誤的原因所有的master和data都要配置一個path.repo路徑
索引分片沒有分配的原因
## 查看未分配原因
GET _cluster/allocation/explain
## 手動重新分配
POST /_cluster/reroute?retry_failed=true
ILM和角色之間的關系
如果根據(jù)角色流轉(zhuǎn)不要分配data_content角色
data_content : 優(yōu)先分配給這個角色,如果有多個data_content,會根據(jù)負載均衡策略進行自動負載.因為這個角色優(yōu)先級比較高,所以如果data_content和data_hot之類的同時設置的話,那么data_hot, data_warm等就會不起作用. 現(xiàn)象:就是不會優(yōu)先分配data_hot,會隨機選擇data_content角色. 解決方案就是如果根據(jù)節(jié)點角色進行數(shù)據(jù)流轉(zhuǎn)或者索引分配就不要配置data_content角色.
以上是單純使用ilm的效果,如果是數(shù)據(jù)流的話data_content的這個規(guī)則就不生效了,它會根據(jù)節(jié)點實際的data_xx角色來分配.
數(shù)據(jù)流轉(zhuǎn)策略
在ILM配置頁面可以選擇根據(jù)節(jié)點角色進行hot,warm,cold,frozen等數(shù)據(jù)流轉(zhuǎn).也可以根據(jù)自定義屬性.
后續(xù)流轉(zhuǎn)會根據(jù)你設置的條件如時間,大小,數(shù)量等等流轉(zhuǎn)到data_warm,data_cold,data_frozen等等節(jié)點.
另外可以關閉rollover,rollover只對hot’節(jié)點數(shù)據(jù)流轉(zhuǎn)起作用
data_frozen角色磁盤空間不夠
解決辦法
vim ./config/elasticsearch.yml
add
xpack.searchable.snapshot.shared_cache.size: 50%
以下幾個設置不起作用:
<!-- 當磁盤使用量低于 cluster.routing.allocation.disk.watermark.low 的閾值時，Elasticsearch 將會解除對分片分配的限制，允許新的分片分配和重新分配操作。默認情況下，cluster.routing.allocation.disk.watermark.low 的值是 85%。 -->
cluster.routing.allocation.disk.watermark.low: 75%
<!--當磁盤使用量超過cluster.routing.allocation.disk.watermark.high的閾值時，Elasticsearch 將嘗試阻止新的分片分配，但仍會繼續(xù)進行分片的重新分配操作，以平衡集群的負載。-->
cluster.routing.allocation.disk.watermark.high: 80%
<!--當磁盤使用量超過cluster.routing.allocation.disk.watermark.flood_stage的閾值時，Elasticsearch 將進入洪水階段，停止所有新的分片分配和重新分配操作。此時，集群將完全停止對磁盤的寫入操作，以防止磁盤耗盡。-->
cluster.routing.allocation.disk.watermark.flood_stage: 85%
如何使用ILM
- 首先要配置ILM策略: Kibana-> stack Mangement ->Data->Index LifeCycle Policies->右側create policies
- 配置模板,引用ILM策略
- 創(chuàng)建索引
- 插入數(shù)據(jù)
- 觀察數(shù)據(jù)在節(jié)點流轉(zhuǎn)
配置ILM策略
試用30天
試用可以試用searchable snapshot.直接點擊license management ->試用30天即可
創(chuàng)建 ILM Policy
PUT _ilm/policy/test_ilm_000001
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"set_priority": {
"priority": 100
}
}
},
"warm": {
"min_age": "10s",
"actions": {
"set_priority": {
"priority": 50
},
"allocate": {
"number_of_replicas": 0
}
}
},
"cold": {
"min_age": "20s",
"actions": {
"set_priority": {
"priority": 0
},
"allocate": {
"number_of_replicas": 0
}
}
},
"frozen": {
"min_age": "30s",
"actions": {
"searchable_snapshot": {
"snapshot_repository": "test_repo_001",
"force_merge_index": true
}
}
},
"delete": {
"min_age": "1m",
"actions": {
"delete": {
"delete_searchable_snapshot": true
}
}
}
}
}
}
創(chuàng)建索引模板 引用ILM
# 組件模板
PUT _component_template/test_component_template1
{
"template": {
"mappings": {
"properties": {
"created_at": {
"type": "date",
"format": "EEE MMM dd HH:mm:ss Z yyyy"
}
}
}
}
}
PUT _component_template/test_component_template2
{
"template": {
"mappings": {
"properties": {
"host_name": {
"type": "keyword"
}
}
}
}
}
}
DELETE _index_template/test_idx_template1
# 索引模板
PUT _index_template/test_idx_template1
{
"index_patterns": ["test_idx_ilm_*"],
"template": {
"settings": {
"index.lifecycle.name":"test_ilm_000001",
"number_of_shards": 1,
"number_of_replicas":0
},
"mappings": {
"properties": {}}
},
"composed_of": ["test_component_template1", "test_component_template2"]
}
驗證節(jié)點流轉(zhuǎn):使用直接插入數(shù)據(jù)到索引
# 新建索引
DELETE test_idx_ilm_*
# 插入數(shù)據(jù)
PUT /test_idx_ilm_000001/_bulk
{"index":{}}
{"title": "head1"}
{"index":{}}
{"title": "head2"}
刷新索引方便看結果
（非必要代碼)
POST /test_idx_ilm_000001/_refresh
節(jié)點不流轉(zhuǎn)分析
PUT _cluster/settings
{
"persistent": {
"indices": {
"lifecycle":{
"poll_interval": "1s"
}
}
}
}
把ILM中的rollover關閉.后續(xù)數(shù)據(jù)流的時候再打開.
數(shù)據(jù)流
操作步驟
官方文檔
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/data-streams.html
關于data roles的幾個疑問和說明
data和data_content
區(qū)別于聯(lián)系是什么?他們分別應用什么場景?
如果把data_content角色理解成冷熱數(shù)據(jù)的分層,那么官方文檔的描述貌似有不是這樣
Content data node Content data nodes are part of the content tier. Data stored in the content tier is generally a collection of items such as a product catalog or article archive. Unlike time series data, the value of the content remains relatively constant over time, so it doesn’t make sense to move it to a tier with different performance characteristics as it ages. Content data typically has long data retention requirements, and you want to be able to retrieve items quickly regardless of how old they are.
這段大致意思是說:內(nèi)容層主要存儲一些歸檔文章,產(chǎn)品目錄等非時間序列相關數(shù)據(jù),這些數(shù)據(jù)隨著時間移動到其他層沒有意義(so it doesn’t make sense to move it to a tier with different performance characteristics as it ages.),這些內(nèi)容數(shù)據(jù)另一個特性是具有長效存儲和檢索的要求(Content data typically has long data retention requirements, and you want to be able to retrieve items quickly regardless of how old they are)
data_content
是不是為了冷熱分冊設計的?或者說生命周期管理是不是為了實現(xiàn)冷熱封層的管理手段(這里的內(nèi)容分層我指的數(shù)據(jù)在hot,warm,cold,frozen之間流轉(zhuǎn))?
我的理解是內(nèi)容分層的目標,產(chǎn)生了ilm生命周期管理的方式,使數(shù)據(jù)進行流式流轉(zhuǎn),
但是這段官方文檔要表達的意思貌似是data_content不是應付數(shù)據(jù)流轉(zhuǎn)的
我覺得如果這么理解的話我們設置data_content and data_hot等等內(nèi)容分層還有什么意義?
這個角色在使用不同組件會產(chǎn)生很多迷惑的行為,比如當生性周期+數(shù)據(jù)流時規(guī)則是這樣的:
data_content必須和[data_hot,data_warm,data_cold,data_frozen]等搭配使用.
數(shù)據(jù)流默認優(yōu)先分配data_hot節(jié)點.
當觸發(fā)新建索引閾值時,老索引才會流轉(zhuǎn)
當直接使用索引+生性周期時:
此時它不會關注data_hot, 它會找data_content的角色的所有節(jié)點,然后根據(jù)負載策略找一個節(jié)點進行分配.
后續(xù)流轉(zhuǎn)就會根據(jù)你配置的策略進行流轉(zhuǎn)了,比如根據(jù)node 的role,它就會匹配data_warm,data_cold,data_frozen
但如果當前節(jié)點同時是下一個流轉(zhuǎn)的節(jié)點它會報個錯誤,比如data_content和data_warm是一個節(jié)點, 首先第一次分配直接分配到到當前節(jié)點了,下個流轉(zhuǎn)節(jié)點是data_warm,發(fā)現(xiàn)就是當前節(jié)點,那么就會報個錯誤
data
如果只設置data節(jié)點不設置data_content還能不能使用生命周期ilm來管理?比如使用自定義屬性實現(xiàn)生命周期的數(shù)據(jù)流轉(zhuǎn)?
集群特點與角色選擇
我的集群存儲什么類型的數(shù)據(jù)需要使用data角色,什么內(nèi)容需要使用data_content角色(hot,warm…等等),另外如果不同角色我的機器配置有什么要求?
創(chuàng)建ILM策略
這是數(shù)據(jù)流所必須的，步驟如上
PUT _ilm/policy/test_ilm_datastream_000002
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"set_priority": {
"priority": 100
},
"rollover": {
"max_size": "5gb",
"max_primary_shard_size": "5gb",
"max_age": "8s",
"max_docs": 2
}
}
},
"warm": {
"min_age": "10s",
"actions": {
"set_priority": {
"priority": 50
},
"allocate": {
"number_of_replicas": 0
}
}
},
"cold": {
"min_age": "20s",
"actions": {
"set_priority": {
"priority": 0
},
"allocate": {
"number_of_replicas": 0
}
}
},
"delete": {
"min_age": "1m",
"actions": {
"delete": {
"delete_searchable_snapshot": true
}
}
}
}
}
}
可以根據(jù)node 的role來進行分配,也可以根據(jù)自定義屬性,上邊的例子就是根據(jù)自定義屬性.
role的官方文檔
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/modules-node.html#data-node
創(chuàng)建組件模板
組件模板相當于是索引模板更小粒度的拆分，使得索引模板的使用更加靈活。你可以把組件模板理解成積木,模板可以靈活使用組件模板進行組合,提高模板的復用性
## 組件模板 - 定義mapping的模板組件
PUT _component_template/test_component_datastream_template_mappings
{
"template": {
"mappings": {
"properties": {
// 這個字段數(shù)據(jù)流必須的 名字也必須是這個,為什么?
"@timestamp": {
"type": "date",
"format": "date_optional_time||epoch_millis"
},
"message": {
"type": "wildcard"
}
}
}
}
}
# 組件模板 - 定義settings
PUT _component_template/test_component_datastream_template_settings
{
"template": {
"settings": {
"index.lifecycle.name": "test_ilm_datastream_000002",
"number_of_replicas": 0
}
}
}
}
創(chuàng)建索引模板
創(chuàng)建索引模板目的是關聯(lián)哪些索引會使用到數(shù)據(jù)流. 它會把所有組件模板進行歸并. 但是有一個問題,如果一個屬性沖突了,是怎么一個策略?是按照先后順序進行覆蓋?
# DELETE /_index_template/test_idx_*
# 索引模板
PUT _index_template/test_idx_template_datastream01
{
// 表示這個開頭的索引
"index_patterns": ["test_idx_ilm_datastream_*"],
// 上邊開頭的索引會應用到數(shù)據(jù)流
"data_stream": { },
"composed_of": ["test_component_datastream_template_mappings", "test_component_datastream_template_settings"]
}
創(chuàng)建數(shù)據(jù)流
數(shù)據(jù)流是針對于已存在的索引創(chuàng)建的，也是通過索引名稱去關聯(lián)索引模板中定義好的數(shù)據(jù)流的。
方式一 寫入數(shù)據(jù)自動創(chuàng)建
## 刪除所有索引,但是無法刪除數(shù)據(jù)流索引
DELETE *
## 刪除數(shù)據(jù)流索引
DELETE _data_stream/星號
# 寫入方式1: 寫入數(shù)據(jù)到 數(shù)據(jù)流[索引] test_idx_ilm_datastream_000001
PUT test_idx_ilm_datastream_000001/_bulk
{ "create":{ } }
{ "@timestamp": "2099-05-06T16:21:15.000Z", "message": "aaaa" }
{ "create":{ } }
{ "@timestamp": "2099-05-06T16:25:42.000Z", "message": "bbb" }
## 查詢
GET _data_stream/test_idx_ilm_datastream_000001
# 寫入方式2
POST test_idx_ilm_datastream_000002/_doc
{
"@timestamp": "2099-05-06T16:21:15.000Z",
"message": "xxx"
}
#查詢
GET _data_stream/test_idx_ilm_datastream_000002
方式二 使用 _data_stream API
PUT _data_stream/your_datastream_name
坑與避坑
Rollover中的時間配置和ILM的流轉(zhuǎn)時間關系
-
Hot phase的默認最小聲明周期（min_age，可配置）為10秒（ [min_age]=[10s]），當在Hot phase中未設置Rollover時，Warm中的最小時間流轉(zhuǎn)不能低于Hot phase的默認最小聲明周期，也就是10秒。此時Hot phase向Warm phase的時間流轉(zhuǎn)取決于Warm phase的min_age值，和Hot phase的min_age值無關 -
當在
Hot phase中配置了Rollover的時候，Hot phase向Warm phase的時間流轉(zhuǎn)會受到Rollover的影響。其最終流轉(zhuǎn)時間需同時滿足Warm phase的min_age和Rollover的最先執(zhí)行的條件。Rollover如果所有條件都一直不滿足，Warm phase的min_age會等待Rollover的條件至少滿足一個為止，換句話說，只要設置了Rollover，Rollover如果不滿足創(chuàng)建新索引的條件，那么Warm phase會一直等待下去，直到創(chuàng)建新索引那一刻，Warm phase的min_age開始計時。舉個例子：如果Rollover的三個條件為：
"rollover": {
"max_primary_shard_size": "50gb",
"max_age": "100m",
"max_docs": 5
},
而 Warm phase的 min_age設置的時間為 10 秒，此時，如果索引的文檔數(shù)一直是小于5，并且索引的體積一直小于50GB，那么索引從 Hot phase流轉(zhuǎn)到 Warm phase的時間即：100m + 10 s，因為100分鐘后Rollover產(chǎn)生了新索引。此時 Warm phase開始計時，10秒后流轉(zhuǎn)。如果在100分鐘內(nèi)，max_primary_shard_size 或者 max_docs滿足了其中任何一個條件，那么從滿足條件這一刻起開始計時，10s中后數(shù)據(jù)從 Hot phase流轉(zhuǎn)到 Warm phase。因此在做數(shù)據(jù)流或者ILM題目的時候，如果不是題目要求，不建議配置Rollover，以避免在對Rollover和ILM Phase關系不熟的情況下，把時間配置錯誤。
關于 node.roles的注意事項
node.roles配置項如果沒有顯式的配置，那么當前節(jié)點擁有所有角色（master、data、ingest、ml、remote_cluster_client、transform）。如果配置了則以配置的為準.文章來源：http://www.zghlxwxcb.cn/news/detail-508683.html
單節(jié)點集群角色
單節(jié)點集群一定要保證節(jié)點同時擁有 master和 data兩個角色，切記是 data（或 data_content）不是 data_hot/data_warm/data_cold。文章來源地址http://www.zghlxwxcb.cn/news/detail-508683.html
到了這里，關于Elasticsearch 索引管理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
