# 同步刷新

原文链接 : [https://www.elastic.co/guide/en/elasticsearch/reference/5.0/indices-synced-flush.html](https://www.elastic.co/guide/en/elasticsearch/reference/5.0/indices-synced-flush.html)

译文链接 : [同步刷新](/pages/viewpage.action?pageId=4260956)

贡献者 : [飞师傅](/display/~zhangyifei)

**Elasticsearch** 跟踪每个分片的索引活动。在5分钟内未收到任何索引操作的分片将会自动标记为非活动状态。这为**Elasticsearch**减少分片资源提供了机会，并且还会执行成为`synced` `flush`的特殊类型刷新。一次同步刷新会执行一次正常刷新，然后将生成的唯一标记（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
```