A Healthy Cluster

In Xpand, user tables are vertically partitioned in representations, which are horizontally partitioned into slices. When a new representation is created, the system tries to determine distribution and placement of the data such that:

• The representation has an appropriate number of slices.
• The representation has an appropriate distribution key, to fairly balance rows across its replicas, but still allow fast queries to specific replicas.
• Replicas are well distributed around the cluster on storage devices that are not overfull.
• Replicas are distributed across zones (if configured).
• Replicas are not placed on decommissioned nodes.
• Reads from each representation are balanced across the representation's nodes.

Over time, representations can lose these properties as their data changes or cluster membership changes. This section describes the various situations that the Rebalancer is able to remedy.

Under-protection

By default, Xpand keeps two copies (replicas) of every slice. If an unexpected node failure makes one of the replicas unavailable, the slice will still be accessible through the remaining replica. When only one replica of a slice exists, the data on that slice is vulnerable to being lost in the event of an additional failure. The number of replicas per slice can be specified via the global variable MAX_FAILURES.

When a slice has fewer replicas than desired, the Rebalancer will create a new copy an existing replica on a different node. The most common reason for this is if a node fails or otherwise becomes unavailable. Initially, the cluster will create Recovery Queues for that node's replicas so that they can be made up-to-date when that node returns to quorum. However, if the node is unavailable for an extended period of time, the Rebalancer will begin making copies of replicas from elsewhere in the cluster and will retire the Recovery Queues.

If a node becomes permanently unavailable, the cluster has reduced storage capacity. If there is not enough remaining storage capacity to make new replicas, the Rebalancer will not be able to do so and the slices will remain under-protected. The cluster does not automatically reserve capacity for re-protecting slices.

Load Imbalance

If the slices of a representation are not well-distributed across the cluster, the Rebalancer will try to move them to more optimal locations.

The Rebalancer evaluates the placement of each representation independently, in the following manner:

• Each slice of a representation is assumed to exert load proportional to its share of the representation's key-space. For example, if the index size of a slice constitutes 10% of the overall representation's index space, then it will also be assumed that slice will comprise 10% of the representation's load, as well. The Rebalancer considers that anticipated activity level when placing a given replica of a slice.
• The representation is well-distributed when the difference between the "most loaded" and "least loaded" nodes is minimal.

Consider the following examples of a representation with three equal-size slices, S1, S2, and S3. Each slice has two replicas distributed across a five-node cluster.

When a Node is Too Full

If a node in the cluster is holding more than its share of table data, the Rebalancer will try to move replicas from that node to a less utilized node.

Before moving any replicas, the Rebalancer computes the load imbalance of the cluster's storage devices. If this imbalance is below a configurable threshold, the Rebalancer will leave things alone. This is to prevent the Rebalancer from making small, unnecessary replica moves.

Balancing storage utilization is a second priority to maintaining representation distribution. In some situations, this may result in less optimal storage device utilization, in exchange for better representation distribution.

When a Slice is Too Big

Representations are partitioned into slices, each of which is assigned a portion of the representation's rows. If a slice becomes large, the Rebalancer will split the slice into several new slices and distribute the original slice's rows among them.The larger a slice becomes, the more expensive it is to move or copy it across the system. The maximum desired slice size is configurable, but by default, the Rebalancer will split slices utilizing greater than 1 GiB. (Utilized space will be slightly larger than the size of user data because of storage overhead).

Too many slices can also be a problem: more slices means more metadata for the cluster to manage, which can make queries and group changes take longer. The Rebalancer will not reverse a split, so the usual recommendation is to err on the side of fewer slices and allow the Rebalancer to split if there is a question about how many slices a representation needs. Splits can be manually reversed with an ALTER statement to change the slicing of a representation.

Because rows are hash-distributed among slices, if a slice approaching the split threshold, it is likely that the other slices of the representation will also need to be split.

The global rebalancer_split_threshold_mb determines when a slice needs splitting. That global may be overridden for a per table or per index basis via DDL. See Slices.

Read Imbalance

Xpand reads exclusively from only one replica of each slice, and that slice is designated as the ranking replica. This allows the Rebalancer to better manage data distribution and load for both write operations, which are applied simultaneously to all replicas, and read operations, which consistently use only the ranking replica.

Since all replicas of a slice are identical, directing reads to a non-ranking replica would produce the same results. However, to better utilize each node's memory, Xpand consistently reads from the designated ranking replica. If a ranking replica becomes unavailable, another replica takes its place.

Decommissioned Nodes

When a node is to be removed from the cluster, the administrator can designate it as soft-failed. This directs the Rebalancer to not place new replicas on that node, nor will it be considered when assessing storage imbalance. The Rebalancer will begin making additional copies of replicas on the softfailed node and place them on other nodes. Once there are sufficient replicas, the softfailed node can be removed from the cluster with loss of data protection. 

Rebalancer Components

The Rebalancer is a system of several components:

1. Information is gathered to build a Model of the cluster's state

2. Tasks examine the Model and decide if action is necessary
3. Tasks post operations to the Queue that will schedule them
4. When an operation graduates from the Queue, it is applied to the cluster
5. When an operation completes, the Model is updated to reflect the new state

Distribution Model

Metadata about the existence and location of every replica is duplicated on each node, but the size of each replica is only known locally on the node where it lives.

The Rebalancer periodically polls all of the nodes in the cluster to create a model of the current cluster state. Between polls, representations may be created or destroyed by users and may grow or shrink in size. The Rebalancer's model of the cluster is always somewhat out of date. This means that it can sometimes make suboptimal decisions.

Tasks

A periodic task monitors each Rebalancer task and corrective action is scheduled independently, as needed. Each task shares the Rebalancer's model of the cluster's state and is aware of other Rebalancer tasks that are queued. Some parameters of these tasks, including their rate, can be adjusted by the administrator.

Summary of Rebalancer Tasks

Although each task is independent, they are tuned so that the decisions of one task will not conflict with the decisions of another. For example, when a slice is split, the new slices are placed with consideration to the rest of the representation's slices and the capacity of the cluster's storage. The new replicas for these slices will be ranked correctly so that the rerank process need not make adjustments later.

Rebalancer Queue

All changes effected by the Rebalancer are scheduled using a priority queue. This queue is designed to rate-limit the Rebalancer so that it does not oversubscribe the cluster with changes, including that:

• One change can be applied to a slice at a time.
• Some operations, like redistributing representations, limit the number of simultaneous executions.
• A limited number of operations can affect an individual node at one time.

Operations are assigned priorities and a queued operation can be surpassed by a higher priority one. Once an operation begins, it is not interrupted, even if there is a higher-priority operation waiting in the queue.

Rebalancer operations can fail for many reasons. If an operation fails, any change made to the cluster is reverted and the Rebalancer may subsequently choose to retry the operation. Because the state of the cluster can change at any time (while the Rebalancer is making decisions or while operations are being performed) some failures are expected even in normal operations.

The Rebalancer keeps no memory of operations after they have completed, so operations that repeatedly fail may be repeatedly retried. The Rebalancer assumes that any condition that causes an operation to fail is transient.

Recovery Queues and Versioned Metadata

Changes to representation metadata, including replica location, are versioned through a Multi-Version Concurrency-Control (MVCC) scheme similar to that used for table data. When a representation is changed, transactions that started before the change will never observe it. Older transactions are not canceled, and newer transactions do not wait for them. Each set simply sees a different view of the metadata. This allows metadata changes to be made without coordination with currently running transactions.

Metadata changes are transactional, so if an error is encountered while effecting the change, the entire change rolls back to the state in which it began.

When the Rebalancer moves a replica between two nodes, it does so through a specific series of DDL changes. Between each change is an epoch during which user transactions may start. The Rebalancer is able to perform the replica move online, with limited disruption to new or running transactions as the operation proceeds. The key to online operations is the Recovery Queue, a log of changes missed by a replica while it was being built. (Recovery Queues are different from the Rebalancer's priority queue of operations.) The following is an example of an online replica move using a Recovery Queue. Other Rebalancer operations are more complex but proceed similarly.

Replica Move Example

Reading from left to right, this image shows the various steps needed to affect a replica move.  

Initial State - Epoch A

Initially, the slice's replicas reside on node 3 and on node 4. We are moving the slice from node 4 to node 1, where no replica for this slice previously existed.

Create A New Replica - Epoch B

The first step is to create a new, empty replica on node 1. This replica is marked as building in the system so that queries won't access it. A Recovery Queue is simultaneously created on node 2 for this replica. That Queue looks like another replica for queries that write to the slice, but it functions differently: it logs any writes so they can be replayed later against the new replica. This allows the copy from node 4 to node 1 to proceed without blocking updates to the slice. The changes for the new replica will be stored in the Recovery Queue.

Data Copy

A serializable read from the original replica returns all of the rows from the point when the Queue was made. These rows are sent to the new, building replica. Meanwhile, any updates to the original replica will be logged to the Queue.

There may be transactions started in epoch A before the Queue was created that try to modify the slice once they are committed. These transactions won't know about the Queue and therefore won't log their updates to it. If these transactions' updates are missed by the serializable copy, their updates would be lost when the original replica is dropped and the new replica is brought online. Therefore, the system will fail any such transaction. To minimize occurrences of this situation, the serializable copy is delayed for a period (about 1 second) to allow in-process transactions to complete.

Queue Replay

When the copy is complete the new replica mirrors the original at the time the copy began. Then the contents of the Queue are read and applied to the new replica.

While queue-replay is progressing updates to the slice continue being logged to the Recovery Queue. Queue-replay is tuned to be faster than the rate at which new entries can be added to the Queue to ensure that Queue-replay finishes.

End of Queue

When the last record in the Queue is read, the Queue changes from asynchronous to synchronous operation. Updates continue to be stored in the Queue and are also applied to the new replica before the transaction is allowed to commit.

Queue Flipped - Epoch C

When the end of the Recovery Queue is reached, the original replica is retired and the new replica is made online.

The Queue is no longer updated by new transactions. Older transactions from epoch B continue to write to it, and the Queue remains in synchronous mode, forwarding updates to the new replica, now online. 

The retired replica continues to receive updates but is never read by new transactions. Transactions in epoch B (from before the flip) still see it and must see the most recent updates to the slice. After the flip, the Queue no longer stores update records since queue-replay is finished.

Retired

Once all old transactions from epoch B have finished, the Recovery Queue will not receive any more writes. The Queue and retiring replica are removed and only the new replica remains.

Final State - Epoch D

Upon completion, the replica's slices now reside on node 1 and 3.

정상 클러스터

ClustrixDB 시스템에서 사용자 테이블은 한 개 또는 여러 개의 representation으로 나눠지고 (분할되고) 각각의 representation은 슬라이스로 수평 분할됩니다. 새로운 representation이 생성되면 ClustrixDB는 다음과 같이 데이터의 분산과 배치를 결정하려고 시도합니다.

• Representation에 적절한 수의 슬라이스가 있습니다.
• Representation은 슬라이스 전체에서 행의 균형을 유지하기 위한 적절한 분산 키를 가지고 있어 특정 슬라이스에 대한 빠른 쿼리가 가능합니다.
• 슬라이스는 꽉 차지 않은 스토리지 장치의 클러스터 전체에 고루 분산되어 있습니다.
• 슬라이스는 클러스터에서 제외된 하드웨어에는 배치되지 않습니다.
• 각 representation에서 읽기는 representation의 노드 전체에 균형되게 분배됩니다.

그러나 시간이 지남에 따라 representation은 데이터 변경 또는 클러스터 멤버십 변경으로 이러한 속성을 잃을 수 있습니다. 이 섹션에서는 Rebalancer가 해결할 수 있는 다양한 상황에 대해 설명합니다.

보호 부족

일반적으로 클러스터는 모든 슬라이스에 대해 최소 두 개의 복제본(replica)을 유지합니다. 이렇게 하면 하드웨어 장애로 복제본 중 하나를 사용할 수 없게 된 경우에도 나머지 복제본을 통해 슬라이스에 액세스할 수 있습니다. 슬라이스의 복제본이 하나만 존재하는 경우, 슬라이스는 장애 발생 시 손실될 위험이 있습니다.

슬라이스의 복제본(replica) 수가 필요한 수보다 적으면 Rebalancer는 다른 노드에서 슬라이스의 새 복제본을 만듭니다. 이런 상황이 발생할 수 있는 두 가지 시나리오는 다음과 같습니다.

• 스토리지 오류로 인해 드라이브의 일부 또는 모든 복제본을 사용할 수 없게 됩니다. 이 경우 스토리지 시스템은 해당 복제본이 클러스터에서 제거되었음을 클러스터에 알립니다.
• 로컬 장애 또는 네트워크 파티션 장애로 인해 노드가 클러스터 쿼럼에서 제외됩니다. 처음에는 클러스터가 해당 노드의 복제본에 대한 복구 큐(Recovery Queue)를 만들어 해당 노드가 쿼럼으로 돌아갈 때 최신 상태로 만들 수 있습니다. 그러나 노드가 장시간 사용할 수 없는 경우 Rebalancer는 해당 슬라이스의 복사본을 만들기 시작하고 복구 큐를 폐기합니다.

이러한 경우 클러스터는 스토리지 용량을 일부 잃게 되었음에 주의하십시오. 만약에 Rebalancer가 새 복제본을 만들기에 충분한 스토리지 공간이 없는 경우에는 슬라이스는 충분히 보호되지 않은 상태로 계속 유지됩니다. 클러스터는 슬라이스를 다시 보호하기 위해 스토리지 용량을 자동으로 예약하지 않기 때문에 사용자는 예상되는 장애 유형에 비례하여 스토리지 용량을 준비해야 합니다.

부하 불균형

Representation의 슬라이스가 클러스터 전체에 잘 분산되어 있지 않은 경우 Rebalancer는 슬라이스를 최적의 위치로 이동하려고 시도합니다.

Rebalancer는 각 representation의 배치를 다음과 같은 방식으로 독립적으로 평가합니다. Representation의 각 슬라이스는 representation의 키 공간(key-space)에 비례하여 부하를 가하는 것으로 가정합니다. Representation은 "가장 부하가 높은" 노드와 "가장 부하가 낮은" 노드 사이의 차이가 최소일 때 잘 분산됩니다.

3개의 동일한 크기의 슬라이스 S1, S2, S3를 가지고 있는 다음 representation의 예를 생각해 보겠습니다. 각 슬라이스는 5개 노드 클러스터에 걸쳐 분산된 두 개의 복제본을 가지고 있고 각 노드에는 몇 개의 스토리지 장치가 있습니다.

디스크가 꽉 찬 경우

클러스터의 어떤 스토리지 장치가 테이블 데이터의 할당량보다 더 많이 보유하고 있으면 Rebalancer는 해당 장치의 복제본을 활용도가 낮은 장치로 이동하려고 시도합니다.

Rebalancer는 복제본을 이동하기 전에 클러스터 스토리지 장비의 부하 불균형을 계산합니다. 부하 불균형이 구성 가능한 임계값 이하인 경우 Rebalancer는 아무 작업도 하지 않습니다. 이것은 Rebalancer가 작고 불필요한 복제본의 이동을 방지하기 위한 것입니다.

이전에 설명한 것처럼 representation 분산을 유지하는 것이 스토리지 사용률 균형을 맞추는 것보다 우선순위입니다. 어떤 상황에서 이것은 더 나은 representation 분산을 위해 덜 최적화된 스토리지 활용률을 야기할 수 있습니다.

슬라이스가 너무 큰 경우

Representation은 슬라이스로 분할되고 각 슬라이스는 representation의 행 일부가 할당된 것입니다. 슬라이스가 커지면 Rebalancer는 슬라이스를 다시 여러 개의 새 슬라이스로 분할하고 원래 슬라이스의 행을 새 슬라이스로 분산합니다.

슬라이스가 커질수록 클러스터에서 슬라이스를 이동하거나 복사하는 비용이 증가합니다. 또한, 모든 슬라이스는 할당된 스토리지 용량에 맞아야 합니다. 이러한 이유로 슬라이스의 크기를 제한해야 합니다. 슬라이스의 최대 크기는 설정할 수 있지만, 기본적으로 Rebalancer는 1 GiB 이상 사용 중인 슬라이스를 분할합니다. (사용된 공간은 저장소 오버헤드로 인해 사용자 데이터 사이즈보다 더 커집니다)

슬라이스가 너무 많으면 문제가 될 수 있습니다. 즉, 슬라이스가 많으면 많을수록 클러스터에서 관리할 메타데이터가 늘어나기 때문에 쿼리나 그룹 변경이 느려질 수 있습니다. Rebalancer는 슬라이스 분할을 취소할 수 없으므로 일반적으로 분할을 줄이고 Rebalancer가 representation이 필요한 슬라이스 수에 따라 분할하도록 하게 하는 편이 좋습니다. (분할은 ALTER문을 사용하여 수동으로 되돌릴 수 있습니다)

행이 슬라이스 전체에 해시로 분산되기 때문에 하나의 슬라이스가 분할 임계치에 가까워지면 representation의 다른 슬라이스도 마찬가지 일 수 있습니다. 따라서 테이블이 하나의 슬라이스에서 시작하여 커지기 시작하는 경우, 예를 들어 1개 슬라이스 → 2개 슬라이스 → 4개 슬라이스 → 8개 슬라이스 등으로 슬라이스가 급격히 증가하는 것을 경험할 수 있습니다.

경우에 따라서는 슬라이스 분할이 적절하게 분산되지 않은 새 슬라이스를 생성할 수 있습니다. 예를 들어, 1 GiB 슬라이스를 분할하면 1 GiB 보다 약간 적은 데이터를 가지는 슬라이스와 32 KiB의 데이터를 가지는 슬라이스가 만들어집니다. 이 상황은 잘못된 배포 키로 인해 발생하며 다음 섹션에서 설명하는 것처럼 자동으로 해결될 수 있습니다.

읽기 불균형

슬라이스에서 읽기는 항상 랭킹 복제본으로 알려진 select 복제본으로 보내집니다. Representation의 복제본이 잘 분산되어 있어도 랭킹 복제본의 분산은 최적이 아닐 수 있습니다. 이 경우 Rebalancer는 복제본의 순위를 조정하여 클러스터 전체에 읽기가 잘 분산되도록 합니다.

모든 슬라이스 복제본이 동일하기 때문에 비 랭킹 복제본을 읽도록 하는 것은 문제가 되지 않습니다. 비 랭킹 복제본이나 랭킹 복제본 모두 같은 결과를 반환됩니다. 그러나 각 노드의 메모리를 최대한 활용하기 위해서 클러스터는 일관되게 랭킹 복제본을 먼저 사용합니다. 랭킹 복제본을 사용할 수 없게 되면 읽기 액세스는 자동으로 다음 랭킹의 복제본으로 라우팅됩니다.

해제 노드 및 디스크

노드를 클러스터에서 제거될 때, 관리자는 해당 노드를 “soft-failed"로 지정합니다. Rebalancer의 경우 이것은 새로운 복제본을 해당 노드에 배치하지 않음을 의미합니다. Representation 또는 스토리지의 부하 불균형을 평가할 때도 이 노드는 고려되지 않습니다. Rebalancer는 이 노드에서 클러스터의 다른 노드로 복제본을 이동하기 시작합니다.

Rebalancer 구성요소

Rebalancer는 여러 개의 구성요소로 이루어진 시스템입니다.

1. 클러스터의 상태 Model을 구축하기 위해 정보가 수집됩니다.

2. Tasks는 Model을 검토하고 조치가 필요한지 여부를 결정합니다.
3. Tasks는 작업을 Queue에 게시하고 Queue는 작업을 예약합니다.
4. 작업이 Queue에서 나오면 클러스터에 적용됩니다.
5. 작업이 완료되면 새로운 상태를 반영하기 위해 Model이 업데이트됩니다.

분산 모델

모든 슬라이스 복제본의 존재와 위치에 대한 메타데이터가 각 노드에 복제됩니다. 그러나 각 복제본의 크기는 복제본이 있는 노드에서만 알 수 있습니다.

Rebalancer는 클러스터의 모든 노드를 정기적으로 폴링하여 현재 클러스터 상태의 모델을 만듭니다. 폴링 사이에 사용자에 의해 새로운 representation이 만들어지거나 폐기되고 크기가 커지거나 작아질 수 있습니다. Rebalancer의 클러스터 상태 모델은 항상 다소 오래된 것입니다. 이것은 Rebalancer가 때로는 차선의 결정을 내릴 수 있다는 것을 의미합니다.

태스크

Rebalancer가 처리할 수 있는 유형의 문제에 대해서 Rebalancer의 모델을 검사하고 필요한 경우 클러스터에 대한 변경을 스케줄하는 주기적인 작업이 있습니다.

Rebalancer 작업은 독립적으로 스케줄됩니다. 모든 작업은 Rebalancer의 클러스터 상태 모델을 공유하며 다른 태스크에 대기 중인 작업을 알지만 그렇지 않은 경우에는 상호 협력하지 않습니다. 이 태스크의 일부 매개변수(등급 포함)는 관리자가 조정할 수 있습니다.

Rebalancer 작업 개요

각 작업은 독립되어 있지만, 하나의 작업의 결정이 다른 작업의 결정과 충돌하지 않도록 조정됩니다. 예를 들어, 슬라이스가 분할될 때 새 슬라이스는 representation의 나머지 슬라이스와 클러스터의 스토리지 용량을 고려하여 배치됩니다. 새로운 복제본의 순위는 순위 조정 프로세스가 나중에 순위를 재 조정할 필요가 없도록 평가됩니다.

Rebalancer 큐

Rebalancer에 영향받은 모든 변경 사항은 우선순위 큐를 사용하여 스케줄됩니다. 이 큐는 Rebalancer의 속도를 제한하여 클러스터가 변경 사항을 초과로 예약하지 않도록 설계되어 있습니다.

Rebalancer 큐는 다음과 같은 속성이 있습니다.

• 한 번에 하나의 변경 사항을 슬라이스에 적용할 수 있습니다.
• Representation 재분산과 같은 특정 작업의 경우 큐는 동시 실행 수를 제한합니다.
• 한 번에 개별 스토리지 장비에 영향을 미치는 작업의 수를 제한합니다.
• 진행 중인 작업의 총수를 제한합니다.

작업에 우선순위가 할당되고 대기 중인 작업은 우선순위에 따라 전달될 수 있습니다. 일단 작업이 시작되면 큐에 우선순위가 높은 작업이 있어도 중단되지 않습니다.

Rebalancer 작업은 여러 가지 이유로 실패할 수 있습니다. 작업이 실패하면 먼저 클러스터의 변경 사항이 원래대로 되돌려지고, 이후에 Rebalancer는 작업을 재시도할 수 있습니다. Rebalancer가 결정을 내리는 동안 또는 작업이 실행되는 동안 클러스터의 상태는 언제든지 변경할 수 있기 때문에 정상적인 작동에서도 일부 장애가 발생할 것으로 예상됩니다.

Rebalancer가 완료된 후 작업 이력을 유지하지 않으므로 반복적으로 실패하는 작업도 계속해서 재시도 될 수 있습니다. Rebalancer는 작업을 중단시키는 모든 조건이 일시적이라고 가정합니다.

복구 큐 및 버전이 있는 메타데이터

복제본 위치를 포함한 representation 메타데이터에 대한 변경 사항은 테이블 데이터에 사용되는 것과 유사한 MVCC (Multi-Version Concurrency-Control) 방식을 통해 버전이 관리됩니다. Representation이 변경될 때 변경 전에 시작된 트랜잭션은 해당 representation을 보지 않습니다. 이전 트랜잭션은 취소되지 않고 최신 트랜잭션은 트랜잭션을 기다리지 않습니다. 각 트랜잭션 세트는 단지 다른 메타데이터 뷰를 보게 됩니다. 이렇게 하면 현재 실행 중인 트랜잭션과의 조정 없이 메타데이터의 변경을 수행할 수 있습니다.

메타데이터 변경은 트랜잭션 방식이므로 변경이 진행되는 동안 에러가 발생하면 전체 변경 사항이 시작 상태로 롤백됩니다.

Rebalancer가 두 노드 간에 슬라이스 복제본을 이동할 때 이것은 특정 일련의 DDL 변경을 통해 이뤄집니다. 각 변경 사이에 사용자 트랜잭션이 시작될 수 있는 아주 짧은 순간이 있습니다. Rebalancer는 작업이 진행됨에 따라 신규 또는 실행 중인 트랜잭션에 제한적인 영향만 주면서 복제본 이동을 온라인으로 수행할 수 있습니다. 온라인 작업의 핵심은 복구 큐(Recovery Queue)이며 이것은 복제본이 생성되는 되는 동안 손실된 변경 사항에 대한 로그입니다. 복구 큐는 Rebalancer의 우선순위 작업 큐와는 다릅니다. 다음은 복구 큐를 사용하는 온라인 복사의 예입니다.

다음은 복제본 이동의 예입니다. 다른 Rebalancer 작업은 더 복잡하지만 비슷한 방식으로 진행됩니다.

복제본 이동 예제

처음에는 노드 3과 4에 두 개의 슬라이스 복제본이 있습니다. 노드 4에서 현재 이 슬라이스의 복제본이 없는 노드 1로 슬라이스를 이동 중입니다.

Create A New Replica

첫 번째 단계는 노드 1에 비어있는 새 복제본을 만드는 것입니다. 이 복제본은 시스템에서 "빌딩(building)"으로 표시되어 쿼리가 해당 복제본에 액세스하지 않습니다. 동시에 노드 2에 이 복제본을 위한 복구 큐가 생성됩니다. 큐는 슬라이스에 쓰기를 수행하는 쿼리에 대한 다른 복사본처럼 보이지만 다르게 동작합니다. 즉, 큐는 모든 쓰기가 나중에 새 복제본에서 재생할 수 있도록 기록합니다. 이렇게 하면 슬라이스에 대한 업데이트를 차단하지 않고 노드 4에서 노드 1로 복사를 진행할 수 있습니다. 새로운 복제본에 누락된 모든 변경 사항은 복구 큐에 있습니다.

Begin Copy

원래 복제본에서 직렬화 가능(serializable) 읽기는 큐가 작성된 시점의 모든 행을 반환합니다. 이 행은 새로운 빌딩(building) 복제본으로 전송됩니다. 그동안 원본 복제본에 대한 업데이트는 모두 복구 큐(Recovery Queue)에 기록됩니다.

이후에 슬라이스를 수정하는 큐가 생성되기 전에 Epoc A에서 시작된 트랜잭션이 있을 수 있다는 점에 유의하십시오. 이러한 트랜잭션은 큐에 대해 알지 못하므로 큐에 업데이트를 기록하지 않습니다. 이러한 트랜잭션의 업데이트가 직렬화 가능 복사에 의해 누락된 경우 원본 복제본이 삭제되고 새 복제본이 온라인이 될 때 업데이트가 손실됩니다. 따라서 시스템은 이러한 트랜잭션이 실패하게 합니다. 이 상황의 발생을 최소화하기 위해 직렬화 가능 복사는 이미 시작된 트랜잭션이 업데이트를 완료할 수 있도록 일정 기간 (약 1초) 지연됩니다.

Begin Queue Replay

복사가 완료되면 새 복제본은 원본이 복사된 시점까지 원본과 함께 최신 상태로 유지됩니다. 이제 큐의 내용을 읽고 새로운 복제본에 전송하여 새 복제본을 적용합니다.

큐 재생이 진행되는 동안 슬라이스에 대한 업데이트는 계속되고 복구 큐에 기록됩니다. 큐 재생은 새로운 항목이 큐에 추가되는 속도보다 더 빠르게 조정됩니다. 그렇지 않으면 재생이 완료되지 않을 수 있습니다.

End of Queue

큐의 마지막 레코드를 읽을 때 큐는 비동기식에서 동기식 작업으로 변경됩니다. 업데이트는 큐에 계속돼서 저장되지만 새 복제본으로도 전달되어 트랜잭션이 커밋되기 전에 적용됩니다.

Queue Flip

복구 큐의 끝에 도달하면 원래 복제본은 폐기되고 새로운 복제본이 온라인이 됩니다.

큐는 새로운 트랜잭션에 의해 더 이상 업데이트되지 않습니다. Epoc B의 이전 트랜잭션은 계속 큐에 쓰기를 하지만 큐는 동기 모드로 유지되고 새 복제본에 업데이트가 전달되면서 온라인이 됩니다.

폐기된 복제본은 계속 업데이트를 받지만 새 트랜잭션에서 읽을 수는 없습니다. 이것은 Epoch B의 (플립 전) 트랜잭션이 여전히 트랜잭션을 보고 슬라이스에 대한 최신 업데이트를 확인해야 하기 때문입니다. 플립(flip) 후, 큐는 큐 재생이 완료된 이후에 더 이상 업데이트 레코드를 기록하지 않습니다.

Retired

Epoc B의 모든 이전 트랜잭션이 완료되면 복구 큐는 더 이상의 쓰기를 수신하지 않습니다. 큐와 폐기된 복제본은 삭제되고 새로운 복제본만 남습니다.