当索引中出现一个新的属性时，添加该属性的数据节点会更新它自己的mapping，然后把新的mapping发送给主节点。如果这个新的mapping还在主节点的等待任务队列中，同时主节点发布了自己的下一个集群状态，那么数据节点将接收到一个过时的旧版本mapping。通常这会让它发送一个更新mapping的请求到主节点，因为直到跟该数据节点有关，主节点一直都拥有错误的mapping信息。这是一个糟糕的默认行为————该节点应该有所行动来保证主节点上拥有正确的mapping信息，而重发新的mapping信息是一个不错的选择。
但是，当有很多的mapping更新发生，并且主节点无法持续坚持时，会有一个乱序聚集(stampeding horde)效应，数据节点发给主节点的刷新消息就可能泛滥。
参数indices.cluster.send_refresh_mapping可以禁用掉默认行为，因此消除这些从数据节点发送到主节点的refresh_mapping请求，可以让主节点保持最新。即时没有刷新请求，主节点也最终会看到最初的mapping变更，并会发布一个包含该变更的集群状态更新。
使用Elasticsearch + Logstash + Kibana搭建日志集中分析平台实践
Ubuntu 14.04搭建ELK日志分析系统(Elasticsearch+Logstash+Kibana)
ElasticSearch 的详细介绍：请点这里
ElasticSearch 的下载地址：请点这里
总结：ElasticSearch的可配置属性是其弹性的关键
对Loggly来讲ElasticSearch可深度配置的属性是一个巨大的优势，因为在我们的使用案例中已经最大限度发挥了ElasticSearch的参数威力(有时更甚)。如果在你自己应用进化的当前阶段ES默认配置工作得足够好了，请放心，随着应用的发展你还会有很大的优化空间。
译者介绍：杨振涛（Gentle Yang），搜索引擎架构师。现就职于vivo移动互联网，负责搜素引擎相关产品和系统的架构设计与开发实施，在厂商移动互联网领域有4年多的经验。热爱开源，乐于分享，目前专注于互联网系统架构特别是实时分布式系统的设计与工程实现，关注大数据的存储、检索及可视化。之前曾参与创业，先后负责开发母婴B2C、移动IM、智能手表等产品；在此之前就职于华大基因，从事基因组学领域的科研工作，专注于基因组数据的存储、检索和可视化。审阅了《Circos Data Visualization How-to》一书，参与社区协作翻译了《ElasticSearch权威指南》一书，待出版。