清理缓存/刷新/同步刷新

Clear Cache 清理缓存

清除缓存API允许清除与一个或多个索引相关联的所有缓存和特定缓存。

POST /twitter/_cache/clear

默认情况下，API会清除所有缓存。可以通过设置query、fielddata或者request来显式清除特定高速缓存。

与特定字段相关的所有高速缓存也可以通过使用逗号分隔符的相关字段列表指定fields参数来清除。

多个索引

清除缓存API可以通过单个调用应用于多个索引，甚至可以应用于_all索引。

POST /kimchy,elasticsearch/_cache/clear

POST /_cache/clear

Refresh 刷新

刷新API允许通过API刷新一个或多个索引。索引的刷新过程基本上通过将数据刷新到索引存储、清除内部事务日志来释放索引的内存。默认情况下，Elasticsearch使用内存启发式方式，以便根据需要自动触发刷新操作，以清理内存。

POST twitter/_flush

请求参数

刷新API接受以下请求参数：

字段	描述
wait_if_ongoing	设置为true，如果另一个刷新操作正在执行，则当前刷新操作将阻塞，只到刷新可以被执行。默认值为false，如果另一个flush操作正在执行。将会导致抛出分片级别的异常。
force	是否强制刷新，无论是否必要。如没有更改将要提交到索引。如果事务日志ID应该增加，即使没有未提交的更改，这是有用的。（此设置可视为内部设置）

多个索引

刷新API可以通过一次调用应用于一个或多个索引，甚至应用于_all索引。

POST kimchy,elasticsearch/_flush

POST _flush

Synced Flush 同步刷新

Elasticsearch跟踪每个分片的索引活动。在5分钟内未收到任何索引操作的分片将会自动标记为非活动状态。这为Elasticsearch减少分片资源提供了机会，并且还会执行成为syncedflush的特殊类型刷新。一次同步刷新会执行一次正常刷新，然后将生成的唯一标记（sync_id）添加到所有分片。

因为在没有正在进行的索引操作时添加了sync_id标记，所以它可以用作检查两个分片的Lucene索引是否相同的快速方式。这个快速同步ID比较（如果存在）在恢复或重启阶段使用，以跳过最昂贵的阶段。在这种情况下，不需要复制分段文件，并且可以立即开始事务日志的恢复重放阶段。请注意，由于同步id与刷新一起应用，因此事务日志很可能为空，从而加快恢复速度。

这对于具有许多从未更新或非常少更新的索引（例如基于时间生成的数据）的用例来说非常有用。此用例通常生成大量的索引，它在没用同步刷新标记时将花费很长的时间。

要检查分片是否有标记，需要查找由统计信息 API返回的分片统计中的commit部分：

GET twitter/_stats/commit?level=shards

返回的东西类似于：

{
   ...
   "indices": {
      "twitter": {
         "primaries": {},
         "total": {},
         "shards": {
            "0": [
               {
                  "routing": {
                     ...
                  },
                  "commit": {
                     "id": "te7zF7C4UsirqvL6jp/vUg==",
                     "generation": 2,
                     "user_data": {
                        "sync_id": "AU2VU0meX-VX2aNbEUsD" ,①
                        ...
                     },
                     "num_docs": 0
                  }
               }
               ...
            ],
            ...
         }
      }
   }
}

① sync_id标记

同步刷新API

同步刷新API运行管理员手动启动同步刷新。这对于计划（滚动）集群重启尤其有用，你可以停止索引，不去等待自动同步刷新空闲索引的默认5分钟。

虽然方便，但是对于这个API有一些注意事项：

1.同步刷新是尽力而为的操作。任何正在进行的索引操作将导致同步刷新在该分片上面失败。这意味着一些分片可能被同步刷新，而其他的分片不被刷新。更多请参见下文。

2.一旦分片再次刷新，sync_id标记将被删除。这是因为刷新替换了储存标记的低级的Lucene提交点。事务日志中尚未提交的操作不会除去标记。在实践中，应该考虑索引上的任何索引操作，因为Elasticsearch在任何时候都可能触发删除标记的刷新操作。

当正在进行索引时，请求同步刷新是无害的。处于空闲状态的分片会成功并且分片也不会失败。任何已经成功的分片将有更快的恢复时间。

响应信息包含有关已经成功同步刷新了多少碎片的详细信息以及任何跟故障相关的信息。

下面是当两个分片和一个副本索引成功同步刷新的样子：

{
   "_shards": {
      "total": 2,
      "successful": 2,
      "failed": 0
   },
   "twitter": {
      "total": 2,
      "successful": 2,
      "failed": 0
   }
}

以下是当一个分片组由于PENDING操作而失败时的情况：

{
   "_shards": {
      "total": 4,
      "successful": 2,
      "failed": 2
   },
   "twitter": {
      "total": 4,
      "successful": 2,
      "failed": 2,
      "failures": [
         {
            "shard": 1,
            "reason": "[2] ongoing operations on primary"
         }
      ]
   }
}

当同步刷新由于并行索引操作失败时，将会出现上述错误。在这种情况下，HTTP状态代码为409 CONFLICT。

有时，故障由于特定的分片副本导致。失败的副本将不能进行快速恢复，成功的副本可以。这种情况下的报告如下：

{
   "_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

同步刷新API可以通过单个调用应用于多个索引，甚至可以应用于_all索引。

POST kimchy,elasticsearch/_flush/synced

POST _flush/synced