【es】Elasticsearch怎样包管数据不丢失？

藏宝库编辑 · 2024-9-24 10:06:54

我们大概已经知道了 Elasticsearch处置处罚数据的流程，此中在Elasticsearch和磁盘之间尚有一层称为FileSystem Cache的系统缓存，正是由于这层cache的存在才使得es可以或许拥有更快搜刮相应本领。
我们都知道一个index是由多少个segment构成，随着每个segment的不停增长，我们索引一条数据后大概要颠末分钟级别的延伸才气被搜刮，为什么有种这么大的延伸，这内里的瓶颈点重要在磁盘。
长期化一个segment必要fsync操纵用来确保segment可以或许物理的被写入磁盘以真正的制止数据丢失，但是fsync操纵比力耗时，以是它不能在每索引一条数据后就实验一次，如果那样索引和搜刮的延伸都会非常之大。
以是这里必要一个更轻量级的处置处罚方式，从而包管搜刮的延伸更小。
这就必要用到上面提到的FileSystem Cache，以是在es中新增的document会被网络到indexing buffer区后被重写成一个segment然后直接写入filesystem cache中，这个操纵黑白常轻量级的，相对耗时较少，之后颠末肯定的隔断或外部触发后才会被flush到磁盘上，这个操纵非常耗时。但只要sengment文件被写入cache后，这个sengment就可以打开和查询，从而确保在短时间内就可以搜到，而不消实验一个full commit也就是fsync操纵，这是一个非常轻量级的处置处罚方式而且是可以高频次的被实验，而不会破坏es的性能。
如下图：

在elasticsearch内里，这个轻量级的写入和打开一个cache中的segment的操纵叫做refresh，默认环境下，es集群中的每个shard会每隔1秒主动refresh一次，这就是我们为什么说es是近及时的搜刮引擎而不是及时的，也就是说给索引插入一条数据后，我们必要期待1秒才气被搜到这条数据，这是es对写入和查询一个均衡的设置方式，如许设置既提升了es的索引写入服从同时也使得es可以或许近及时检索数据。
refresh的用法如下：

refresh操纵相比commit操纵黑白常轻量级的但是它仍然会淹灭肯定的性能，以是不发起在每插入一条数据后就实验一次refresh下令，es默认的1秒的延伸对于大多数场景根本都可以担当。
固然并不是全部的业务场景都必要每秒都refresh一次，如果你短时间内要索引大量的数据，为了优化索引的写入速率，我们可以设置更大的refresh隔断，从而提升写入性能，下令如下：

上面的参数是可以随时动态的设置到一个存在的索引内里，如果我们正在插入超大索引时，我们完全可以先关闭掉这个refresh机制，等写入完毕之后再重新打开，如许以来就能大大提升写入速率。
下令如下：

注意refresh_interval的参数是可以带时间周期的，如果你只写了个1，那就代表每隔1毫秒革新一次索引，以是设置这个参数时务须要审慎。
我们已经知道在elasticsearch中每个shard每隔1秒都会refresh一次，每次refresh都会天生一个新的segment，按照这个速率过不了多久segment的数量就会爆炸，以是存在太多的segment是一个大标题，由于每一个segment都会占用文件句柄，内存资源，cpu资源，更加告急的是每一个搜刮哀求都必须访问每一个segment，这就意味着存在的segment越多，搜刮哀求就会变的更慢。
那么elaticsearch是怎样办理这个标题呢？
实际上elasticsearch有一个配景进程专门负责segment的归并，它会把小segments归并成更大的segments，然后反复如许。
在归并segments的时间标志删除的document不会被归并到新的更大的segment内里，全部的过程都不必要我们干涉，es会主动在索引和搜刮的过程中完成，归并的segment可以是磁盘上已经commit过的索引，也可以在内存中还未commit的segment：
（1）在索引时refresh进程每秒会创建一个新的segment而且打开它使得搜刮可见
（2）merge进程会在配景选择一些小体积的segments，然后将其归并成一个更大的segment，这个过程不会打断当前的索引和搜刮功能。

（3）一旦merge完成，旧的segments就会被删除，流程如下：

至此原来标志伪删除的document都会被整理掉，如果不加控制，归并一个大的segment会斲丧比力多的io和cpu资源，同时也会搜刮性能造成影响，以是默认环境下es已经对归并线程做了资源限额以便于它不会搜刮性能造成太大影响。
api如下：
大概不限定：

es的api也提供了我们外部发送死令来欺压归并segment，这个下令就是optimize，它可以欺压一个shard归并成指定命量的segment，这个参数是：max_num_segments ，一个索引它的segment数量越少，它的搜刮性能就越高，通常会optimize成一个segment。
必要注意的是optimize下令不要用在一个频仍更新的索引上面，针对频仍更新的索引es默认的归并进程就是最优的战略，optimize下令通常用在一个静态索引上，也就是说这份索引没有写入操纵只有查询操纵的时间黑白常恰当用optimize来优化的，比如说我们的一些日志索引，根本都是按天，周，大概月来索引的，只要过了本日，这周或这个月就根本没有写入操纵了，这个时间我们就可以通过optimize下令，来欺压归并每个shard上索引只有一个segment，如许查询性能就能大大提升。
api如下：

注意，由外部发送的optimize下令是没有限定资源的，也就是你系统有多少IO资源就会使用多少IO资源，如许大概导致某一段时间内搜刮没有任何相应，以是如果你操持要optimize一个超大的索引，你应该使用shard allocation功能将这份索引给移动到一个指定的node呆板上，以确保归并操纵不会影响其他的业务大概es本身的性能。
在elasticsearch和磁盘之间尚有一层cache也就是filesystem cache，大部门新增大概修改，删除的数据都在这层cache中，如果没有flush操纵，那么就不能100%包管系统的数据不会丢失，比如忽然断电大概呆板宕机了，但实际环境是es中默认是30分钟才flush一次磁盘，这么长的时间内，如果发生不可控的故障，那么是不是肯定会丢失数据呢？
很显然es的操持者早就思量了这个标题，在两次full commit操纵（flush）之间，如果发生故障也不能丢失数据，那么es是怎样做到的呢？
在es内里引入了transaction log（简称translog），这个log的作用就是每条数据的任何操纵都会被记录到该log中，非常像Hadoop内里的edits log和hbase内里的WAL log，如下图：
transaction log的工作流程如下：
（1）当一个文档被索引时，它会被添加到内存buffer内里同时也会在translog内里追加
（2）当每个shard每秒实验一次refresh操纵完毕后，内存buffer会被清空但translog不会。
过程如下：

上面过程如下图：

（3）随着更多的document添加，内存buffer区会不停的refresh，然后clear，但translog数量却越增越多，如下图：

（4）当到达默认的30分钟时间，translog也会变得非常大，这个时间index要实验一次flush操纵，同时会天生一个新的translog文件，而且要实验full commit操纵，流程如下：
如下图：

tanslog的作用就是给全部还没有flush到硬盘上的数据提供长期化记录。
当es重启时，它起首会根据上一次停止时的commit point文件把全部已知的segments文件给规复出来，然后再通过translog文件把上一次commit point之后的全部索引变革包罗添加，删除，更新等操纵给重放出来。
除此之外tanslog文件还用于提供一个近及时的CURD操纵，当我们通过id读取、更新大概删除document时，es在从相干的segments内里查询document之前，es会起首从translog内里获取近来的变革，如许就意味着es总是近及时的优先访问最新版本的数据。
我们知道实验flush下令之后，全部系统cache中的数据会被同步到磁盘上而且会删除旧的translog然后天生新的translog，默认环境下es的shard会每隔30分钟主动实验一次flush下令，大概当translog变大凌驾肯定的阈值后。
flush下令的api如下：

flush下令根本不必要我们手动操纵，但当我们要重启节点大概关闭索引时，最好提前实验一下flush下令作为优化，由于es规复索引大概重新打开索引时，它必须要先把translog内里的全部操纵给规复，以是也就是说translog越小，recovery规复操纵就越快。
我们知道了tangslog的目标是确保操纵记录不丢失，那么标题就来了，tangslog有多可靠？
默认环境下，translog会每隔5秒大概在一个写哀求（index，delete，update，bulk）完成之后实验一次fsync操纵，这个进程会在全部的主shard和副本shard上实验。
这个保卫进程的操纵在客户端是不会收到200 ok的哀求。
在每个哀求完成之后实验一次translog的fsync操纵还是比力耗时的，固然数据量大概比并不是很大。
默认的es的translog的设置如下：

如果在一个大数据量的集群中数据并不是很告急，那么就可以设置成每隔5秒举行异步fsync操纵translog，设置如下：

上面的设置可以在每个index中设置，而且随时都可以动态哀求生效，以是如果我们的数据相对来说并不是很告急的时间，我们开启异步革新translog这个操纵，如许性能大概会更好，但坏的环境下大概会丢失5秒之内的数据，以是在设置之前要思量清楚业务的告急性。
如果不知道怎么用，那么就用es默认的设置就行，在每次哀求之后就实验translog的fsycn操纵从而制止数据丢失。
[size=6]参考[/size]

为什么说Elasticsearch搜刮是近及时的？
https://mp.weixin.qq.com/s/Xqmty7S1heVDkRfrALoxBg
Elasticsearch怎样包管数据不丢失？
https://mp.weixin.qq.com/s/zGbuft5vYJAvHGLYv4QR7w
Elasticsearch内里的segment归并
https://mp.weixin.qq.com/s/kzLgAvq2jIZDxLXp-Hk_2A

【es】Elasticsearch怎样包管数据不丢失？

所属分类: 问答交流

新帖推荐: 30日

推荐作品