Elasticsearch 对外提供了一个 _tasks 接口，用于获取当前各个节点正在执行的任务，这里要避免和 pending_tasks 搞混，后者是用于获取在 master leader 节点排队等待修改 cluster state 的处理任务。

当我们遇到问题或者需要深入了解 Elasticsearch 的运行机制时，调整日志等级（ logging level ）到更详细的级别，比如 DEBUG、TRACE ，会是一个有效且必须要掌握的方法。

如果你关注过 elasticsearch 的日志，可能会看到如下类似的内容： {代码...} 看到其中的[gc]关键词你也猜到了这是与 GC 相关的日志，那么你了解每一部分的含义吗？如果不了解，你可以继续往下看了。 我们先从最简单的看起： 第一部分是日志发生的时间 第二部分是日志级别，这里分别是WARN和INFO 第三部分是输出日志的类...

常见的数据库都会提供备份的机制，以解决在数据库无法使用的情况下，可以开启新的实例，然后通过备份来恢复数据减少损失。虽然 Elasticsearch 有良好的容灾性，但由于以下原因，其依然需要备份机制。

有 SQL 背景的同学在学习 Elasticsearch 时，面对一个查询需求，不由自主地会先思考如何用 SQL 来实现，然后再去想 Elasticsearch 的 Query DSL 如何实现。那么本篇就给大家讲一条常见的 SQL 语句如何用 Elasticsearch 的查询语言实现。

距离上一篇 esrally 教程过去快2个月了，这期间不停有同学来询问使用中遇到的问题，尤其由于其测试数据存储在国外 aws 上，导致下载极慢。为了让大家快速上手使用 esrally，我 build 了一个可用的 docker 镜像，然后将 13GB 的测试数据拉取到国内的存储上，通过百度网盘的方式分享给大家。大家只要按照下面简单的几步操...

执行 bulk 索引文档的时候，用 index 或者 create 类型并且自定义 doc id 的情况下，是否会像 update 一样每次都要去 get 一遍原始文档？ 比如下面的这条命令：

由于 Elasticsearch（后文简称es） 的简单易用及其在大数据处理方面的良好性能，越来越多的公司选用 es 作为自己的业务解决方案。然而在引入新的解决方案前，不免要做一番调研和测试，本文便是介绍官方的一个 es 压测工具 esrally，希望能为大家带来帮助。