微网站幻灯片尺寸,服务商名称是什么意思,温州鹿城区企业网站搭建,网站建设费入何科目原文地址:https://www.elastic.co/blog/elasticsearch-sequence-ids-6-0 如果
几年前#xff0c;在Elastic#xff0c;我们问自己一个如果问题#xff0c;我们知道这将带来有趣的见解#xff1a; 如果我们在Elasticsearch中对索引操作进行全面排序会怎样…原文地址:https://www.elastic.co/blog/elasticsearch-sequence-ids-6-0 如果
几年前在Elastic我们问自己一个如果问题我们知道这将带来有趣的见解 如果我们在Elasticsearch中对索引操作进行全面排序会怎样我们可以建立什么 答案涵盖范围很广
我们可以构建一种称为变更API的功能它可以接受操作ID并为您提供自那时以来数据更改的列表。很棒我们可以只查找发生变化的索引操作从而建立增量reindex我们可以使用增量reindex功能通过过滤/连续reindex建立以实体为中心的索引我们可以建立不依赖于数据按时、按顺序和全局精确时间戳到达的数据滚动/汇总索引我们可以建立类似物化视图的东西在新数据/操作到达时进行更新如果节点之间的操作因网络断开等原因而丢失我们可以建立一种重放操作的方法这将大大加快恢复速度我们可以建立一种在集群之间重放操作的方法跨数据中心复制
所有这些都需要打破一个小小的障碍为索引操作添加序列号。很简单我们只需要在主索引的每个操作中添加一个计数器太简单了我们看到社区成员和员工尝试了好几次。但当我们层层剥开洋葱头时我们发现它比最初看起来要复杂得多。在我们开始讨论变更应用程序接口的实用性近6年后我们仍然没有一个变更应用程序接口。原因何在本博客的目的是分享幕后发生的事情并就这个问题的答案提供一些见解。
在过去两年中我们几乎从头开始重写了复制逻辑。我们从已知的学术算法中汲取精华同时确保我们仍能确保并行性这正是Elasticsearch能够如此快速的原因这是许多甚至所有传统共识算法都无法做到的。我们与分布式系统专家合作为我们的复制模型建立了TLA规范。我们增加了大量测试和测试基础设施。
这篇博客必然是技术性的因为我们会深入探讨Elasticsearch如何进行复制的一些核心内容。不过我们的目的是通过解释/定义/链接一些术语即使您可能已经理解了这些术语让更多读者能够理解这些术语。首先让我们深入了解Elasticsearch所面临的一些挑战。
挑战
在继续深入之前我们必须先谈谈我们的复制模型以及它的重要性。在Elasticsearch数据索引中数据被分割成所谓的分片基本上就是索引的子分区。你可以有5个主分片基本上是索引的5个子分区每个主分片可以有任意数量的主分片副本称为副本。但重要的是每个子分区只有一个主分片。主分片首先接受索引操作索引操作包括添加文档或删除文档等操作然后将索引操作复制到副本。因此在将每个操作转发给副本之前不断递增计数器并为每个操作分配一个序列号是非常简单的。只要没有人重启服务器网络正常运行时间达到100%硬件不出现故障没有长时间的Java垃圾回收事件也没有人升级软件这种简单易行的方法就能真正奏效。
但我们生活在现实世界中当这些假设发生变化时Elasticsearch就会进入故障模式和恢复过程。如果它们影响到运行主分片的节点可能需要主分片停机由另一个副本取而代之。由于变化来得突然一些正在进行的索引操作可能尚未完全复制。如果您有2个或更多副本其中一些操作可能只到达了其中一个副本而没有到达另一个副本。更糟糕的是由于Elasticsearch会并发索引文档这也是Elasticsearch速度如此之快的原因之一每个副本都可能有不同的操作集而这些操作集在另一个副本中并不存在。即使只运行一个副本Elasticsearch的默认设置也可能会出现问题。如果旧的主副本回来并被添加为副本它可能包含从未复制到新主副本的操作。所有这些情况都有一个共同点主节点失效后分片上的操作历史可能会发生偏离我们需要一些方法来解决这个问题。
PrimaryTerms Sequence Numbers
我们采取的第一步是能够区分旧的和新的主分片。我们必须有一种方法来识别来自旧主分片的操作与来自新主分片的操作。此外整个集群需要就此达成一致以确保在出现问题时不会发生争执。这促使我们实现了主要术语。这些主要术语是增量的并在主分片被提升时更改。它们被持久化在集群状态中因此代表了集群所处的主分片的版本或生成。有了主要术语操作历史中的任何冲突都可以通过查看操作的主要术语来解决。新术语优于旧术语。我们甚至可以开始拒绝那些太旧的操作避免混乱的情况发生。
一旦我们设置了主要术语的保护机制我们添加了一个简单的计数器并开始为每个操作分配一个来自该计数器的序列号。因此这些序列号使我们能够了解在主分片上发生的索引操作的特定顺序我们可以将其用于接下来几节中将要讨论的各种目的。您可以在响应中看到分配的序列号和主要术语
$ curl -H Content-Type: application/json -XPOST http://127.0.0.1:9200/foo/doc?pretty -d { bar: baz }{_index: foo,_type: doc,_id: MlDBm10BditXXu4kjj5E,_version: 1,result: created,_shards: {total: 2,successful: 1,failed: 0},_seq_no: 19,_primary_term: 1
}注意返回的响应中现在包含了_seq_no和_primary_term。
Local and Global Checkpoints
有了主要术语和序列号我们理论上有了检测分片之间差异并在主分片失败时重新对齐它们的工具。拥有主要术语为x的旧主分片可以通过删除主要术语为x且不存在于新主分片历史记录中的操作来恢复并且具有更高主要术语的缺失操作可以索引到旧主分片中。
不幸的是当您同时每秒索引数十万甚至数百万个事件时比较数百万次操作的历史记录实际上是不切实际的。存储成本过高直接比较所需的计算工作将耗时过长。为了解决这个问题Elasticsearch维护了一个名为全局检查点的安全标记。全局检查点是一个序列号我们知道所有活动分片的历史记录都至少与之对齐。换句话说所有序列号低于全局检查点的操作都已经被所有活动分片处理并在各自的历史记录中是相等的。这意味着在主分片失败后我们只需要比较新主分片和任何剩余副本之间最后已知的全局检查点以上的操作。当旧主分片恢复时我们取其最后知道的全局检查点并将其以上的操作与新主分片进行比较。这样我们只需要比较需要比较的操作而不是整个历史记录。
推进全局检查点的责任属于主分片。主分片通过跟踪副本上已完成的操作来实现这一点。一旦检测到所有副本已经超过给定的序列号主分片将相应地更新全局检查点。分片副本不会一直跟踪所有操作而是维护一个全局检查点的本地变体称为本地检查点。本地检查点是一个序列号该副本上处理了所有更低序列号的操作。每当副本确认或ack主节点的写操作时它们也会向主节点提供更新的本地检查点。利用本地检查点主节点就能更新全局检查点然后在下一次索引操作中将全局检查点发送给所有分片副本。
下面的动画展示了在面对有损网络和突发故障等并发挑战时随着序列号和全局/本地检查点的增加而发生的情况 当索引操作从主分片发送到副本时我们会跟踪每个副本确认收到的最高序列号并将其称为全局检查点。主分片会告诉所有副本全局检查点是多少。因此如果主分片切换我们只需要比较和可能重新处理自上次全局检查点以来的操作而不是磁盘上的所有文件。 全局检查点还具有另一个很好的特性——它代表了那些被保证会留下的操作它们在所有活动分片的历史记录中以及可能会被回滚的操作所在的区域如果主分片在它们被完全复制并向用户确认之前恰好发生故障。这是一个微妙但重要的特性对于未来的变更API或跨数据中心复制功能将是至关重要的。
第一个好处更快恢复
在Elasticsearch6.0之前我们跳过了实际恢复过程的工作原理。当Elasticsearch在副本处于离线状态后恢复副本时它必须确保该副本与活动主分片完全相同。非活动分片具有同步刷新标记以便快速进行验证但具有活动索引的分片则没有任何保证。如果一个分片在仍有活动索引的情况下掉线那么新的主分片将通过网络复制Lucene段即磁盘上的文件。如果这些分片很大这可能是一个繁重且耗时的操作。这是因为在6.0之前我们没有跟踪个别写操作序列号而在幕后Lucene会将所有添加/更新/删除合并到更大的分段中这样就无法恢复构成更改的单个操作…也就是说除非你将事务日志保留一段时间。
这就是我们现在所做的我们保留事务日志直到它变的过大或过旧不再有必要继续保留它。如果副本需要更新我们会使用该副本已知的最后一个全局检查点仅从主事务日志中回放相关更改而不是昂贵的大文件复制。如果主事务日志过大或太旧而无法重放到副本那么我们将回退到旧的基于文件的恢复方式。
如果您一直在运行一个大型集群而该集群经常出现网络断开、重启、升级等情况我们希望这将大大提高您的工作效率因为您不必在分片恢复时长时间等待。
须知
正如上一节中提到的事务日志保留直到它过大或过旧而不再需要保留。我们如何确定什么是过大或过旧呢当然是可配置的在6.0中我们引入了两个新的事务日志设置
*index.translog.retention.size:默认为512MB。如果事务日志超过这个大小我们只保留这么多数据。 *index.translog.retention.age:默认为12小时。超过这个时间段我们将不再保留事务日志文件。
这些设置很重要因为它们影响新的、更快的恢复工作以及磁盘使用情况。较大的事务日志保留大小或较长的保留时间意味着您有更高的机会通过新的更快恢复来进行恢复而不是依赖于旧的基于文件的恢复。然而它们也伴随着一定的成本这会增加磁盘利用率而且请记住事务日志是按分片进行的。举个实际的例子如果您有20个索引每个索引有5个主分片并且在12小时内写入大量数据那么可能会导致额外205512mb50GB的磁盘利用率直到那12小时窗口过期为止。如果您在不同索引上有不同的恢复和大小需求您可以根据需要在每个索引上进行调整。例如如果您预计进行机器或节点维护您可能需要考虑对事务日志保留窗口进行任何调整。
注意在6.0之前事务日志的大小在索引过程中也可以增长到512MB默认值根据index.translog.flush_threshold_size设置。这意味着新的保留策略不会改变活动分片的存储需求。这一变化影响了停止索引的分片。现在我们不清理事务日志而是将其保留另外12小时。
下一个优势跨数据中心复制
正如文章开头提到的如果我们能进行有序的索引操作我们就能在Elasticsearch中做很多美妙的事情。虽然花了一些时间但现在我们做到了。更快的恢复是我们决定构建的第一个用例它允许我们测试我们添加的新功能。
但我们知道跨数据中心复制也是我们企业客户常常要求的功能所以这是我们即将添加的另一个功能。这需要构建新的API、在复制之上增加新的监控功能以及是的还需要进行更多的测试和文档编写。
还有更多工作要做
正如您在序列号GitHub问题上看到的我们在序列号功能上有了一个良好的开端但仍有许多工作要做我们认为迄今为止所做的工作代表了我们向前迈出的一大步即使它还没有涵盖我们可以建立/围绕序列号的所有功能。如果您有兴趣继续关注我们的工作请随时关注标有:Sequence IDs的ticket或PR或直接在讨论区与我们联系
