Elasticsearch provides failover capabilities by keeping multiple copies of your data in the cluster. In presence of network disruptions or failing nodes, changes might not make it to all the copies. This blog post showcases one of the internal mechanics of Elasticsearch to identify shard copies that are missing changes, providing an in-depth view on how two central components, the consensus module and the data replication layer, integrate to keep your data safe.
Elasticsearch는 cluster에 data 복사본을 여러 개 보관하여 장애에 대비한다. network 장애나 node에 장애가 발생한 경우, 변경 사항이 모든 node에 반영되지 않을 수 있다. 이 게시물은 Elasticsearch가 변경 사항이 누락된 shard의 복사본을 식별하는 내부 메커니즘을 보여주는데, 2개의 핵심 구성 요소 즉 consensus module과 data 복제 단계가 data를 안전하게 보관하기 위하여 통합되는 방법을 자세하게 제공한다.
Data replication in Elasticsearch is based on the primary-backup model. This model assumes a single authoritative copy of the data, called the primary. All indexing operations first go to the primary, which is then in charge of replicating changes to active backup copies, called replica shards. Elasticsearch uses replica shards to provide failover capabilities as well as to scale out reads. In cases where the current primary copy becomes either temporarily or permanently unavailable, for example due to a server maintenance window or due to a damaged disk drive, another shard copy is selected as primary. Because the primary is the authoritative copy, it is critical in this model that only shard copies which contain the most recent data are selected as primary. If, for example, an older shard copy was selected as primary after it was on a node that was isolated from the cluster, that old copy would become the definitive copy of the shard, leading to the loss of all changes that were missed by this copy. The following presents how Elasticsearch v5+ keeps track of the shard copies that can safely be selected as primary, also called the in-sync shard copies.
Elasticsearch의 data 복제는 primary-backup 모델을 기반으로 한다. 이 모델은 primary 라 불리는 신뢰할 수 있는 data의 복사본 하나를 가정합니다. 모든 index 작업은 먼저 primary로 간 다음 replica shard라 불리는 활성화된 backup 복사본으로 변경 사항을 복제하는 역활을 한다. Elasticsearch는 replica shard를 사용하여, 장애 대비와 읽기 확장 기능을 제공한다. server 유지보수 기간이나 disk drive 손상으로 현재의 primary 복사본이 일시적으로 또는 영구적으로 사용할 수 없는 경우, 다른 shard 복사본이 primary가 된다. primary는 신뢰할 수 있는 복사본이기 때문에, 가장 최근의 data를 포함하고 있는 shard 복사본만이 primary가 될 수 있다는 사실이 이 모델에서 중요하다. 예를 들어, cluster에서 분리되었던 node의 이전 shard 복사본이 primary가 되면, 이 오래된 복사본이 shard의 최종 복사본이 되어, 이 복사본에서 누락된 모든 변경 사항을 잃어버리게 된다. 다음은 v5 이상에서 Elasticsearch가 primary로 안전하게 선택될 수 있는 shard 복사본(in-sync shard 복사본)을 추적하는 방법을 보여준다.
Safely allocating primary shards
Shard allocation is the process of deciding which node should host an active copy of the shard. Allocation decisions are made by the master node and recorded in the cluster state, a data structure that also contains other metadata such as index settings and mappings. Allocation decisions contain information about which shards should be allocated to which nodes, and whether they should play the role of primary or replica shard. The master broadcasts cluster state changes to all nodes that are part of the cluster. Having the cluster state available on each node enables smart routing of requests as each node is aware of where primary and replica shards are allocated.
shard allocation은 shard의 활성 복사본을 가질 node를 결정하는 process이다. allocation 결정은 master node에서 이루어지고, index 설정이나 mapping 같은 다른 metadata도 포함하는 data 구조인 cluster state 에 기록된다. allocation 결정에는 어떤 shard를 어느 nodex에 배치할 것이가, 그리고, 이들이 primary 또는 replica shard의 역활을 수행해야 하는지 여부에 대한 정보가 있다. master는 cluster의 일부인 모든 node에 대해 cluster state의 변경사항을 전달한다. 각 node가 cluster state를 이용할 수 있어야 각 node가 primary와 replica shard가 할당된 위치를 알 수 있으므로, request를 스마트하게 routing할 수 있다.
Each node inspects the cluster state to determine the shards that it should make available. If the shard is assigned as a primary to a node that already holds a copy of the shard data, the node just needs to load up the local shard copy and make it available for search. If a shard is allocated as replica, the node first copies over missing data from the node that has the primary. When there are not enough replica copies of the shard available in the cluster (as determined by the index setting index.number_of_replicas), the master can also allocate replica shards to nodes that don’t have any data for this shard, thereby instructing these nodes to create full copies of the primary shard.
각 node는 이용할 수 있는 shard를 결정하기 위하여 cluster state를 확인한다. shard가 shard data 복사본을 이미 가지고 있는 node에 primary로 할당된 경우, node는 local shard 복사본을 load하여 search에 이용하면 된다. shard가 replica로 할당되었다면, node는 primary를 가진 node에서 누락된 data를 먼저 복사한다. cluster에서 사용할 수 있는 shard의 복사본이 충분하지 않은 경우(index 설정 index.number_of_replicas 에 의해 결정), master는 이 shard에 대한 data를 가지지 않은 node에 replica shard를 할당할 수도 있다. 이렇게 함으로써, 이들 node는 primary shard의 전체 복사본을 생성하게 된다.
When a new index is created the master has a lot of flexibility to select nodes in the cluster to allocate the primary shards to, taking cluster balancing and other constraints such as allocation awareness and filtering into account. Allocating existing shard copies as primaries happens on more rare occasions. Examples are full cluster restarts, where none of the shards are initially allocated when the cluster is first formed, or multiple failures over a short time span that cause all active copies to become unavailable. In these situations the master first reaches out to all nodes to find out what on-disk shard copies exist in the cluster. Based on the copies that are found, it decides whether to allocate one of them as primary. In order to guarantee safety, the master has to make sure to only select shard copies as primary that contain the most recent data. To this effect, Elasticsearch uses the concept of allocation IDs, which are unique identifiers (UUIDs) to distinguish between shard copies.
새로운 index가 생성되는 경우, master는 primary shard를 할당하기 위해 cluster에서 node를 선택하고, cluster balancing 과 allocation awareness, filtering 같은 기타 제약 조건을 고려한다. 기존 shard 복사본을 primary로 할당하는 경우는 거의 발생하지 않는다. 예를 들어, cluster가 처음 형성되는 경우 초기에 shard가 할당되지 않는 전체 cluster 재시작이나, 모든 활성 복사본을 활용할 수 없는 짧은 시간 간격에 걸친 여러 번의 장에가 있다. 이런 상황에서, master는 먼저 모든 node에 접근하여 cluster에 있는 disk상의 shard 복사본을 확인한다. 발견된 복사본을 근거로, 복사본 중 하나를 primary로 할당할지를 결정한다. 안정성을 보장하기 위하여, master는 가장 최신의 data를 포함하는 shard 복사본을 primary로 선택해야 한다. 이런 효과를 위해, shard 복사본을 구분하기 위해 교유한 ID(UUID)인 allocation ID 라는 개념을 사용한다.
Allocation IDs are assigned by the master during shard allocation and are stored on disk by the data nodes, right next to the actual shard data. The master is responsible for tracking the subset of copies that contain the most recent data. This set of copies, known as in-sync allocation IDs, is stored in the cluster state, which is persisted on all master and data nodes. Changes to the cluster state are backed by Elasticsearch’s consensus implementation, called zen discovery. This ensures that there is a shared understanding in the cluster as to which shard copies are considered as in-sync, implicitly marking those shard copies that are not in the in-sync set as stale.
allocation ID는 shard allocation 중에 master에 의해 할당되며, 실제 shard data가 있는 data node에 의해 disk에 저장된다. master는 가장 최신 data를 포함하고 있는 복사본 집합을 추적해야 한다. in-sync allocation ID 라 불리는 이 복사본 집합은 모든 master와 data node에서 유지되는 cluster state에 저장된다. cluster state의 변경 사항은 zen discovery Elasticsearch의 consensus 구현에 의해 뒷받침된다. 이렇게 하면, cluster에서 어떤 shard 복사본이 in-sync 로 간주되는 것에 대한 이해가 공유되며, in-sync 가 stale(오래된 버전) 로 설정되지 않은 해당 shard 복사본을 암묵적으로 표시한다.
When allocating a primary shard, the master checks if the allocation ID of the on-disk copy that it has found on a node in the cluster matches one of the IDs in the set of in-sync allocations that is present in the cluster state. The shard is then only allocated as primary to the node if its ID matches one of the IDs in the in-sync set. If a primary fails while there are existing active replicas, one of the active replicas, which is also in the in-sync set, is simply promoted to primary, ensuring continued write availability in the cluster.
primary shard를 할당할 때, master는 cluster의 node에서 찾은 disk 상의 복사본의 allocation ID가 culster state에 존재하는 in-sync allocation의 집합에 있는 ID 중 하나와 일치하는지를 확인한다. 그 다음에 shard ID가 in-sync 집합의 ID 중 하나와 일치하는 경우에만 그 shard가 node에 primary로 할당된다. 기존의 활성 replica가 있을 경우, primary에 장애가 발생하면, in-sync 집합에 있는 활성 replica 중 하나가 primary가 되어, cluster에서 지속적인 쓰기 가용성을 보장하게 된다.
Marking shards as stale
Elasticsearch uses a different mechanism to replicate data than it uses for replicating cluster state changes. Whereas metadata changes require consensus on the cluster level, data replication uses the simpler primary-backup approach. This two-layered system allows data replication to be simple and fast, only requiring interaction with the cluster consensus layer in exceptional situations. The basic flow for handling document write requests is as follows:
Elasticsearch는 data 복제에 cluster state 변경 사항 복제에 사용하는 것과 다른 방법을 사용한다. metadata 변경은 cluster level의 consensus가 필요하지만, data 복제는 보다 단순한 primary-backup 방식을 사용한다. 이 2 단계의 시스템을 사용하면, data 복제는 단순하고 빠르며, 예외적인 상황에서만 cluster consensus layer의 상호작용이 필요하다. document 쓰기 request를 위한 기본 흐름은 다음과 같다.
- Based on the current cluster state, the request gets routed to the node that has the primary shard.
cluster state를 기초로, request는 primary shard를 가진 node로 route된다. - The operation is performed locally on the primary shard, for example by indexing, updating or deleting a document.
작업은 primary shard 내부에서 수행된다. 예를 들자면, document의 index/update/delete - After successful execution of the operation, it is forwarded to the replica shards. If there are multiple replication targets, forwarding the operation to the replica shards is done concurrently.
작업이 성공하면, replica shard로 전달된다. replica가 여러 개 있다면, replica로의 작업 전달은 동시에 일어난다. - When all replicas have successfully performed the operation and responded to the primary, the primary acknowledges the successful completion of the request to the client.
모든 replica가 작업의 성공적인 수행을 primary로 알리면, primary는 client에 request의 성공적인 완료를 알린다.
In the case of network partitions, node failures or just general shard unavailability when the node hosting the shard copy is not up, the forwarded operation might not have been successfully performed on one or more of the replica shard copies. This means that the primary will contain changes that have not been propagated to all shard copies. If these copies were to continue to be considered as in-sync, they could become primary at a later point in time even though they are missing some of the changes, resulting in data loss.
network partitions, node 장애, shard 복사본을 가지고 있는 node가 동작하지 않는 경우의 일반적인 shard 를 이용할 수 없는 경우, 전달된 작업이 하나 이상의 shard 복사본에서 성공적으로 수행되지 않을 수 있다. 즉, primary는 모든 shard 복사본에 전달되지 않은 변경사항을 포함하고 있다. 이들 복사본을 계속 in-sync로 간주할 경우, 변경 사항 중 일부가 누락되어도 나중에 primary가 될 수 있어, data 손실이 발생할 수 있다.
There are two solutions to this: a) Fail the write request and undo the changes on the available copies or b) ensure that the divergent shard copies are not considered as in-sync anymore. Elasticsearch chooses write availability in this case: The primary instructs the active master to remove the IDs of the divergent shard copies from the in-sync set. The primary then only acknowledges the write request to the client after it has received confirmation from the master that the in-sync set has been successfully updated by the consensus layer. This ensures that only shard copies that contain all acknowledged writes can be selected as primary by the master.
이에 대한 2가지 해결책이 있다. a) 쓰기 request 실패와 이용가능한 복사본에서 변경 사항의 취소 또는 b) 달라진(divergent) shard 복사본을 더 이상 in-sync 로 간주하지 않도록 한다. Elasticsearch는 다음과 같은 경우 쓰기 가용성을 선택한다. primary는 active master가 달라진(divergent) shard 복사본의 ID를 in-sync 집합에서 제거하도록 지시한다. 그 다음에, in-sync 집합이 consensus layer에 의해 성공적으로 update되었다는 확인을 master로 부터 받은 후에, primary는 client에게 쓰기 request를 응답한다. 이렇게 하면, 모든 응답을 받은 write를 포함한 shard 복사본만이 master에 의해 primary로 선택될 수 있다.
Examples
To see this in action, let’s consider a small cluster with one master and two data nodes. To keep the example simple, we’ll use an index with 1 primary and 1 replica shard. Initially, one of the data nodes has the primary and the other the replica shard. We use the cluster state API to inspect the in-sync shard information that is tracked by the cluster state, filtering the resulting output down to the relevant bits using the “filter_path” query parameter:
이를 실제로 보기 위해, 1개의 master 와 2개의 data node를 가진 조그마한 cluster를 생각해 보자. 예를 단순하게 하기 위해, 1개씩의 primary와 replica shard를 가진 index를 사용할 것이다. 처음에는 data node 중 하나가 primary를 가지고, 나머지가 replica shard를 가진다. cluster state API 를 사용하여, cluster state에 의해 추적되는 in-sync shard 정보를 확인하고, "filter_path" query 매개변수를 사용하여 결과를 관련 bit로 filtering한다.
GET /_cluster/state?filter_path=metadata.indices.my_index.in_sync_allocations.*,routing_table.indices.my_index.*
This yields the following excerpt of the cluster state:
그러면, 다음과 같은 cluster state가 출력된다.
{
"metadata": {
"indices": {
"my_index": {
"in_sync_allocations": {
"0": [
"HNeGpt5aS3W9it3a7tJusg",
"wP-Z5fuGSM-HbADjMNpSIQ"
]
}
}
}
},
"routing_table": {
"indices": {
"my_index": {
"shards": {
"0": [
{
"primary": true,
"state": "STARTED",
"allocation_id": { "id": "HNeGpt5aS3W9it3a7tJusg" },
"node": "CX-rFmoPQF21tgt3MYGSQA",
...
},
{
"primary": false,
"state": "STARTED",
"allocation_id": { "id": "wP-Z5fuGSM-HbADjMNpSIQ" },
"node": "AzYoyzzSSwG6v_ypdRXYkw",
...
}
]
}
}
}
}
}
The cluster state shows that both the primary and replica shard are started. The primary is allocated to the data node “CX-rFmo” and the replica is allocated to the data node “AzYoyz”. Both have a unique allocation id which is also present in the in_sync_allocations set.
cluster state는 primary와 replica 모두가 시작되었음을 나타낸다. primary는 data node "CX-rFmp" 에, replica는 "AzYoyz" 에 할당되었다. 둘 모두 in_sync_allocations 집합에도 존재하는 유일한 allocation id를 가지고 있다.
Let’s see what happens when we shut down the node that currently has the primary shard. As this does not actually change any of the shard data, both shard copies should stay in sync. In absence of the primary shard, the replica shard should also be promoted to primary, which is properly reflected in the resulting cluster state:
현재 primary shard를 가지고 있는 node가 종료될 경우 어떤 일이 일어나는지 살펴보자. 실제로 shard data를 변경하지 않았기 대문에, 2 shard 복사본은 in-sync 상태여야 한다. primary shard가 없으면, replica shard는 primary shard가 되어야 하는데, 이것은 cluster state에 적절하게 반영된다.
{
"metadata": {
"indices": {
"my_index": {
"in_sync_allocations": {
"0": [
"HNeGpt5aS3W9it3a7tJusg",
"wP-Z5fuGSM-HbADjMNpSIQ"
]
}
}
}
},
"routing_table": {
"indices": {
"my_index": {
"shards": {
"0": [
{
"primary": true,
"state": "STARTED",
"allocation_id": { "id": "wP-Z5fuGSM-HbADjMNpSIQ" },
"node": "AzYoyzzSSwG6v_ypdRXYkw",
...
},
{
"primary": false,
"state": "UNASSIGNED",
"node": null,
"unassigned_info": {
"details": "node_left[CX-rFmoPQF21tgt3MYGSQA]",
...
}
}
]
}
}
}
}
}
The replica shard stays unassigned as we only have one data node up. If we start the second node again, the replica shard will automatically be allocated to that node again. To make this scenario more interesting, we won’t start up the second node. Instead we are going to index a document into the newly promoted primary shard. As the shard copies are now diverging, the unavailable shard copy becomes stale, and it’s ID is thus removed by the master from the in-sync set:
하나의 data node만 동작하고 있으므로 replica shard는 할당되어 있지 않다. 2번째 node를 다시 시작하면, replica shard는 자동으로 해당 node에 할당될 것이다. 이 시나리오를 더욱 흥미롭게 만들기 위해, 2번째 node를 시작하지 않는다. 대신 새로운 primary shard에 document를 index한다. 이제 shard 복사본은 달라지(diverge)면서, 활용할 수 없는 shard 복사본은 오래된 버전(stale)이 되었고, 그 ID는 master에 의해 in-sync 집합에서 제거된다.
{
"metadata": {
"indices": {
"my_index": {
"in_sync_allocations": {
"0": [
"wP-Z5fuGSM-HbADjMNpSIQ"
]
}
}
}
},
"routing_table": {
... // same as in previous step
}
}
With only one in-sync shard copy left, let’s see how the system reacts if that copy becomes unavailable. To that effect, let’s shut down the only data node that’s currently up and then bring up the previous data node with the stale shard copy. After doing so, the cluster health API shows the cluster health as red. The cluster state also shows that the primary shard is not getting allocated:
하나의 in-sync shard 복사본만이 남겨져 있을 경우, 해당 복사본을 활용할 수 없게 되면, 시스템이 어떻게 반응하는지 알아보자. 이를 위해, 현재 동작하고 있는 유일한 data node을 중단시키고, 오래된 버전(stale)의 shard 복사본을 가진 이전 data node를 불러 오자. 그렇게 하면, cluster health API 는 cluster health를 red로 표시한다. 또한, cluster state는 primary shard가 할당되지 않았음을 보여준다.
{
"metadata": {
"indices": {
"my_index": {
"in_sync_allocations": {
"0": [
"wP-Z5fuGSM-HbADjMNpSIQ"
]
}
}
}
},
"routing_table": {
"indices": {
"my_index": {
"shards": {
"0": [
{
"primary": true,
"state": "UNASSIGNED",
"recovery_source": { "type": "EXISTING_STORE" },
"unassigned_info": {
"allocation_status": "no_valid_shard_copy",
"at": "2017-01-26T09:20:24.054Z",
"details": "node_left[AzYoyzzSSwG6v_ypdRXYkw]"
},
...
},
{
"primary": false,
"state": "UNASSIGNED",
"recovery_source": { "type": "PEER" },
"unassigned_info": {
"allocation_status": "no_attempt",
"at": "2017-01-26T09:14:47.689Z",
"details": "node_left[CX-rFmoPQF21tgt3MYGSQA]"
},
...
}
]
}
}
}
}
}
Read LessLet’s also have a look at the cluster allocation explain API which is a great tool for debugging allocation issues. Running the explain command with no parameters will provide an explanation for the first unassigned shard that the system finds:
allocation 문제를 debug하는 훌륭한 tool인 cluster allocation explain API 를 살펴보자. 매개변수 없이 explain command를 실행하면, 먼저 시스템이 발견한 할당되지 않은 shard에 대한 설명을 제공한다.
GET /_cluster/allocation/explain
The explain API tells us why the primary shard is unassigned and also provides more detailed allocation information on a per-node basis. In this case the master cannot find any in-sync shard copies on the nodes that are currently available in the cluster:
explain API는 primary shard가 할당되지 않은 이유를 설명하고, node별로 더 자세한 allocation 정보를 제공한다. 이 경우, master는 cluster에서 현재 활용할 수 있는 node에서 in-sync shard 복사본을 찾을 수 없다.
{
"index" : "my_index",
"shard" : 0,
"primary" : true,
"current_state" : "unassigned",
"unassigned_info" : {
"reason" : "NODE_LEFT",
"at" : "2017-01-26T09:20:24.054Z",
"last_allocation_status" : "no_valid_shard_copy"
},
"can_allocate" : "no_valid_shard_copy",
"allocate_explanation" : "cannot allocate because all found copies of the shard are either stale or corrupt",
"node_allocation_decisions" : [
{
"node_id" : "CX-rFmoPQF21tgt3MYGSQA",
"node_name" : "CX-rFmo",
"transport_address" : "127.0.0.1:9301",
"node_decision" : "no",
"store" : {
"in_sync" : false,
"allocation_id" : "HNeGpt5aS3W9it3a7tJusg"
}
}
]
}
Read LessThe API also shows that the shard copy that’s available on node “CY-rFmo” is stale (store.in_sync = false). Starting up the other node that has the in-sync shard copy brings the cluster back to green again. What would happen though if that node had gone up in flames?
또한, 이 API는 node "CY-rFmo" 에서 이용할 수 있는 sahrd 복사본이 오래된 버전(stale, store.in_sync = false)임을 나타낸다. in-sync shard 복사본을 가지고 있는 다른 node를 시작하면, cluster는 다시 green으로 돌아온다. 만약 그 node가 없어져 버리렸다면 어떻게 될까?
Not all is lost - APIs for the not-so faint-hearted
When a major disaster strikes there may be situations where only stale shard copies are available in the cluster. Elasticsearch will not automatically allocate such shard copies as primary shards, and the cluster will stay red. In the case where all in-sync shard copies are gone for good, however, there is still a possibility for the cluster to revert to using stale copies, but this requires manual intervention from the cluster administrator.
심각한 상황이 발생하면, cluster에 오래된 버전(stale)의 shard 복사본만 있는 상황이 발생할 수 있다. Elasticsearch는 자동으로 그런 shard를 primary shard로 할당하지 않으며, cluster는 red로 유지된다. 그러나, 모든 in-sync shard 복사본이 완전히 사라지는 경우에도, cluster가 오래된 버전(stale)의 복사본으로 되돌릴 수 있지만, cluster 관리자가 수동으로 관여해야 한다.
As we’ve seen in the previous example, the first step in understanding allocation issues is to use the cluster allocation explain API. It shows whether nodes have a copy of the shard and whether the respective copy is in the in-sync set or not. In the case of file-system corruptions, it also shows the exception that was thrown when accessing the on-disk information. In the previous example the allocation explain output showed that an existing shard copy was found on node “CX-rFmo” in the cluster but that that copy did not contain the most recent data (in-sync : false).
이전 예에서도 보았듯이, allocation 문제를 이해하는 첫번째 단계는 cluster allocation explain API 를 사용하는 것이다. 이것은 node가 shard 복사본을 가지고 있는지, 해당 복사본이 in-sync 집합에 있는지 여부를 표시한다. file-system 손상의 경우, disk상의 정보를 access할 때 발생하는 예외도 표시한다. 이전의 예에서, allocation explain 출력은 cluster의 node "CX-rFmo"에서 기존의 shard 복사본이 발견되었으나 가장 최근의 data를 포함하지 않았다는 사실(in-sync : false)을 보여주었다.
The reroute API provides a sub-command allocate_stale_primary which is used to allocate a stale shard copy as primary. Using this command means losing the data that is missing in the given shard copy. Using the command in a situation where an in-sync shard copy is just temporarily unavailable effectively means destroying the more recent data that’s available on the in-sync copy. It should be seen as a measure of last resort to get the cluster running with at least some of the data. In the case where all shard copies are gone, there is also the possibility to force Elasticsearch to allocate a primary using an empty shard copy, which effectively means losing all previous data associated with that shard. It goes without saying that the command allocate_empty_primary should only be used in the direst of situations and that its implications should be well-understood.
reroute API 는 오래된 버전(stale)의 shard 복사본을 primary로 할당하는데 사용되는 하위 command allocate_stale_primary 를 제공한다. 이 command를 사용하는 것은 지정된 shard 복사본에 없는 data를 잃어버린다는 것을 의미한다. in-sync shard 복사본이 있는 환경에서 이 command를 사용하면, in-sync 복사본에서 이용할 수 있는 더 최근의 data가 삭제된다. 이는 최소의 일부 data로 cluster를 실행하는 최후의 수단이어야 한다. 모든 shard 복사본이 사라진 경우, Elasticsearch가 비어있는 shard 복사본을 primary로 강제 할당할 수도 있는데, 이는 사실상 해당 shard와 관련된 모든 이전 data의 손실이다. allocate_empty_primary command는 최악의 상황에서만 사용되어야 하며, 그 의미를 잘 이해해야 한다.
원문 : Elasticsearch Internals - Tracking in-sync shard copies