relocating对Elasticsearch集群的影响是什么

本文主要讲解“搬迁对Elasticsearch集群有什么影响”，感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你了解“搬迁对弹性搜索集群有什么影响？”！

00-1010碎片移动后，目标节点会向主节点发起分片启动的PRC，优先级次高：exclusive，主节点处理RPC的速度较慢，尤其是当集群中碎片数量达到数万个时，可能会导致一些优先级较低的RPC来不及长时间执行，如put-mapping，对业务造成明显影响。

由任何原因(如重新平衡、分配过滤、强制感知等)产生的分片启动的RPC。会有这个问题。例如，在扩展集群时，如果再平衡是在更大的规模上开发的，那么显然会影响master的处理能力。因此，对于碎片较多的集群，在想要增加再平衡和恢复的并发时，要考虑对master的影响。

00-1010当主片被重新平衡或手动移动时，可以想象一定有一段时间不能写入主片。

Elasticsearch直接重新定位主切片，在移动之前不会将主切片的限定移动到其他子切片。即便如此，也会有切换的时间点，写不出回应。

如果从RPC的定时来看这个时间段，如下图所示，用红色标记的区域就是阻止写入过程的时间段。在此期间，客户端的写请求将被阻止而不返回，直到这部分处理完成。

以手动移动为例，当主切片从node-idea移动node1时，主要有以下几个阶段：

首先，通过发布一个新的集群状态，切片将被标记为REFINING，routing_table和routing_nodes将被更新。

收到群集状态后，数据节点开始执行恢复过程，该过程在目标节点发送start_recovery时开始，在源阶段返回start_recovery响应时结束。

恢复完成后，目标向主节点发送碎片启动的RPC，主节点再次发出集群状态，将碎片标记为已启动。

当源节点执行完成阶段并准备发送切换RPC时，阻止客户端大容量写入的阶段开始，直到接收到主节点的新集群状态，并且片段被标记为已启动。每个节点应用群集状态的时间点略有不同，因此每个节点停止阻止写入的时间点也会略有不同。

切换RPC的功能是通知目标节点该片可以切换主片状态。换手RPC的处理都是一些计算操作，涉及几个锁，通常很快就会完成。

整个母片的重新定位过程对写入的影响是一个非常复杂的过程。我把它们分成几个阶段。下面是详细的流程。

00-1010在片段的整个重定位过程中，对目标节点的请求将被转发到源节点，直到目标节点应用主节点发出的片段并成为STARTED集群状态。

在00-1010开始时，写请求到达源节点，通常会像往常一样写入主片，直到复制阶段。

shard-started RPC 会抢占较多的 master 处理时间

在此阶段，接收到的写请求被复制到目标节点。他在收到prepare_translog的响应后开始，直到切换阶段开始。

1.将 target 分片加入到 replication group

收到prepare_translog响应后，恢复的phase1阶段已经结束，段文件已经发送，并且目标节点的引擎已经启动。通过shard.initiateTracking将目标片段添加到复制组，后续的写操作将被复制到目标节点。

prepare engine step . when complete(prepare engine time-{ 0

运行价格

imaryPermit(() -> shard.initiateTracking(request.targetAllocationId()),
               shardId + " initiating tracking of " + request.targetAllocationId(), shard, cancellableThreads, logger);
   final Translog.Snapshot phase2Snapshot = shard.getHistoryOperations("peer-recovery", historySource, startingSeqNo);
});

复制组信息在 ReplicationTracker 的 replicationGroup成员中维护。

2.在写入过程中，将写请求复制给 target

在写入流程的 performOnPrimary#doRun() 函数的 finishRequest方法中，最终调用 ReplicationOperation#handlePrimaryResult函数的 performOnReplicas方法将 index 发送给 target 节点。

handoff阻塞阶段

handoff阶段是为了完成主分片状态的转移，该阶段对收到的写入请求放到队列中，待主分片状态转移完成后继续执行，最多阻塞30分钟。期间对 target 节点的写入也会被转发的 source 节点执行。此阶段从 source 节点收到 finalize 的 response之后开始，直到下一阶段。

1.recovery 过程设置阻塞标记

在 source 节点收到 finalize 的 response之后，通过 handoff RPC 交接主分片状态，这个交接过程通过 indexShardOperationPermits.blockOperations 对此时收到的写入请求进行阻塞，最多30分钟。

 public void relocated(final String targetAllocationId, final Consumer<ReplicationTracker.PrimaryContext> consumer){
        try  {
            indexShardOperationPermits.blockOperations(30, TimeUnit.MINUTES, () -> {//block 的范围就是这段括号里的代码
                final ReplicationTracker.PrimaryContext primaryContext = replicationTracker.startRelocationHandoff(targetAllocationId);
                try {//下面调用 RemoteRecoveryTargetHandler.handoffPrimaryContext
                    consumer.accept(primaryContext);//执行这里之后发送和响应了 handoff_primary_context RPC
                } 
            });
        }
    }

indexShardOperationPermits.blockOperations 中的阻塞操作只是 queuedBlockOperations 加1，后面写入流程会检查 queuedBlockOperations 的值是否为0

2.写入流程的处理
产生在写入链路的 acquire函数：

acquire:255, IndexShardOperationPermits (org.elasticsearch.index.shard)
acquirePrimaryOperationPermit:2764, IndexShard (org.elasticsearch.index.shard)
handlePrimaryRequest:256, TransportReplicationAction 

该函数判断 queuedBlockOperations 大于0，于是将他添加到 delayedOperations，写入流程到此结束。delayedOperations中的操作会在本阶段的阻塞过程结束后处理。

失败重试阶段

失败重试阶段自source 节点处理完 handoff response之后开始，直到 master 下发了将分片标记为 STARTED 的集群状态，数据节点应用了集群状态之后结束，在应用这个集群状态之前，分片处于 relocating 状态，期间的写入操作由 source 节点执行，并且会写入失败，抛出 ShardNotInPrimaryModeException 异常，并捕获该异常，等待1分钟后重试写入，再次失败则退出；如果1分钟内收到了新的集群状态，也会重试写入，然后写入成功。

写入流程中，执行 acquire 函数时，发现 queuedBlockOperations为0，执行onAcquired.onResponse(releasable)，调用到 wrapPrimaryOperationPermitListener函数时，发现分片已经不是主分片状态，抛出 ShardNotInPrimaryModeException 异常。

if (replicationTracker.isPrimaryMode()) {
    l.onResponse(r);
} else {
    r.close();
    l.onFailure(new ShardNotInPrimaryModeException(shardId, state));
}

对于上者返回的异常，写入流程 acquirePrimaryOperationPermit 设置的 Listener会区分异常类型，如果是 ShardNotInPrimaryModeException 异常，则等待1分钟后进行重试。

move 一个副分片，对写入流程的影响

副分片的 move 过程与主分片的 move 过程相似，也是下发两次集群状态，通过 recovery 复制到 target 节点。

需要注意的是，recovery 复制分片到 target 节点，并非从副分片当前所在节点复制到 target，而是从主分片复制到 target。例如，主分片在节点 node-idea 上，副分片在 node-1，当我们从 node-1 move 到 node-2时，recovery 是从 node-idea 复制到 node-2。当 node-1应用主节点发布的分片状态变为 STARTED 的集群状态时，发现分片已经属于自己，于是删除本节点的分片。

与主分片的 relocating 类似的是，在复制阶段，会将正在 recovery 的分片添加到 replication group，这样 replication group 中就有了三个分片，主分片，原副分片，以及 move 到 target 节点的新的副分片。在复制阶段，写入操作会写入到这三个分片。

以手工 move 一个副分片为例，从 node-1 move 到 node-2时，当收到第一个第一个集群状态，分片被标记为 relocating，于是数据从 node-idea recovery 到 node-2。在此期间，新的 index 操作会由主分片节点复制到另外两个节点。如下图所示。

这个过程相当于先增加了一个副分片，执行副分片的 recovery 流程复制到新的 target。

当 recovery 执行完毕，master 下发第二个集群状态，分片被标记为 STARTED，node-1原来持有的分片被删除，如下图所示。

副分片的 relocating 过程不会有 handoff 阶段，整个 relocating 过程如同副分片的 recovery 过程一样，没有对写入进行阻塞的阶段。

到此，相信大家对“relocating对Elasticsearch集群的影响是什么”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！