对应7.2官方文档路径：Indices APIs » Flush & Indices APIs » Refresh
官方地址如下：
https://www.elastic.co/guide/en/elasticsearch/reference/7.2/indices-flush.html
https://www.elastic.co/guide/en/elasticsearch/reference/7.2/indices-refresh.html
1.Flush
- Flush
flush api允许flush一个或多个索引。一个索引的flush操作可以确保在translog中存在的数据也永久存在于lucene中。这样打开lucene索引后就无需再从translog中reindex数据，减少了索引恢复时间。默认es会按需自动进行flush操作，用户很少需要自行调用此api。
POST twitter/_flush
- Request Parameters
flush api接受以下参数：
wait_if_ongoing：如果设置为true（默认），当一个flush操作在执行过程中，新的flush操作将会阻塞直到可以执行。
force： 是否强制flush，即使不需要(即如果没有更改被提交到索引)。如果没有未提交的更改，但是需要增加translog的id，这将非常有用。（此设置可视为内部设置） - Multi Index
flush请求可以应用于一个或多个索引，甚至全部索引_all
POST kimchy,elasticsearch/_flush
POST _flush
2.Synced Flush
es追踪每个分片的索引活跃度，如果分片5分钟内没有接收到任何索引请求就会被标记为不活跃。这为es减少分片资源提供了一次机会，es将进行一次特别的flush也就是synced flush。synced flush会执行普通的flush，并且添加一个唯一的标记(sync_id)到所有分片。
在没有索引操作进行的分片上添加了sync id进行标记，可以用其快速检查两个shard的lucene索引是否相同。快速的sync id比较（如果存在）在恢复或重新启动期间使用，可以跳过该过程的第一个也是最昂贵的阶段。在这种情况下，无需复制任何segment文件，并且恢复的translog日志重播阶段可以立即开始。请注意，由于sync id标记是与flush一起应用的，因此translog日志很可能为空，从而进一步加快了恢复速度。
这对于从未更新或很少更新的索引（例如基于时间的数据）特别有用。这种情况下通常会生成许多索引，如果没有synced flush，它们的恢复将花费很长时间。
要检查分片是否具有sync id，请查看indices stats API返回的分片统计信息commit部分：
GET twitter/_stats?filter_path=**.commit&level=shards
注：filter_path 参数用于减少响应的详细程度，但完全是可选的。
返回内容如下类似：具有sync_id
{
"indices": {
"twitter": {
"shards": {
"0": [
{
"commit" : {
"id" : "3M3zkw2GHMo2Y4h4/KFKCg==",
"generation" : 3,
"user_data" : {
"translog_uuid" : "hnOG3xFcTDeoI_kvvvOdNA",
"history_uuid" : "XP7KDJGiS1a2fHYiFL5TXQ",
"local_checkpoint" : "-1",
"translog_generation" : "2",
"max_seq_no" : "-1",
"sync_id" : "AVvFY-071siAOuFGEO9P",
"max_unsafe_auto_id_timestamp" : "-1",
"min_retained_seq_no" : "0"
},
"num_docs" : 0
}
}
]
}
}
}
}
Synced Flush API
synced flush API允许管理员手动启动同步刷新。这对于计划中的（滚动）群集重启特别有用，你需要停止索引行为并且不想等待默认的5分钟空闲索引自动同步。
虽然方便，但此API有一些警告：
1.synced flush是一种尽力操作。任何正在进行的索引操作将导致该分片的synced flush失败。这意味着某些分片可能会synced flush成功，而其他分片则会失败。
2.只要shard再次flush就会移除sync_id标记。那是因为flush替换了存储标记的低级Lucene提交点。translog日志中未提交的操作不会删除标记。在实践中，我们应该将索引上的任何索引操作视为删除标记，因为Elasticsearch随时都可能触发flush操作。
注：在正在进行索引操作的同时进行synced flush是无害的。空闲的分片将成功，非空闲的分片将失败。成功的所有分片将具有更快的恢复时间。
POST twitter/_flush/synced
请求回复中包含多少个分片成功进行了sync-flushed和任何失败信息。
这是两分片和一副本索引中的所有分片都成功sync-flushed后的样子：
{
"_shards": {
"total": 2,
"successful": 2,
"failed": 0
},
"twitter": {
"total": 2,
"successful": 2,
"failed": 0
}
}
这是一个分片组由于挂起操作而失败时的情况：
{
"_shards": {
"total": 4,
"successful": 2,
"failed": 2
},
"twitter": {
"total": 4,
"successful": 2,
"failed": 2,
"failures": [
{
"shard": 1,
"reason": "[2] ongoing operations on primary"
}
]
}
}
注：当synced flush由于索引操作而失败时，将显示以上错误。在这种情况下，HTTP状态代码为409 CONFLICT。
有时，故障是针对某个shard副本的。失败的副本将不具备快速恢复的资格，但成功的副本仍将具有资格。情况如下：
{
"_shards": {
"total": 4,
"successful": 1,
"failed": 1
},
"twitter": {
"total": 4,
"successful": 3,
"failed": 1,
"failures": [
{
"shard": 1,
"reason": "unexpected error",
"routing": {
"state": "STARTED",
"primary": false,
"node": "SZNr2J_ORxKTLUCydGX4zA",
"relocating_node": null,
"shard": 1,
"index": "twitter"
}
}
]
}
}
注：当分片副本无法同步刷新时，返回的HTTP状态代码将为409 CONFLICT。
synced flush API可以通过一次调用应用于多个索引，甚至可以应用于_all索引。
POST kimchy,elasticsearch/_flush/synced
POST _flush/synced
3.Refresh
refresh api允许refresh一个或多个索引，使自上次refresh以来执行的所有操作都可用于搜索,近实时搜索依赖于此。例如，内部需要refresh才能调用，但默认情况下会定期执行一次refresh。
POST /twitter/_refresh
Multi Index
refresh API可以通过一次调用应用于多个索引，甚至可以应用于_all索引。
POST /kimchy,elasticsearch/_refresh
POST /_refresh
