30. ClustrixDB 分布式架构/Rebalancer

Rebalancer是一个自动化系统，用于维护集群中数据的健康分布。通过修改数据的分布和位置来响应“不健康”集群是Rebalancer的工作。Rebalancer是一个在线进程，它影响对集群的更改，对用户操作的干扰最小。它减轻了数据库管理员手工操作数据放置的负担。

ClustrixDB Rebalancer被设计为自动作为后台进程运行，以便跨集群重新平衡数据。下面几节将描述Rebalancer是如何工作的。对于大多数部署来说，分布和副本的默认值已经足够，通常不需要更改。

健康的集群

在ClustrixDB中，用户表在representation中是垂直分区的，而representation是水平分区为片的。当创建一个新的representation时，系统试图确定数据的分布和位置，如:

该representation具有适当数量的片。
该representation具有适当的分布键，可以在其副本之间平衡行，但仍然允许对特定副本进行快速查询。
副本很好地分布在集群中的存储设备上，而这些存储设备并不会超载。
副本跨区域分布(如果配置)。
副本不放在已退役的节点上。
对每个representation的读取在representation的节点之间保持平衡。

随着时间的推移，representation可能会随着其数据更改或集群成员关系更改而丢失这些属性。本节描述Rebalancer能够纠正的各种情况。

受到保护

默认情况下，Clustrix保留每个片的两个副本。如果意外的节点故障使其中一个副本不可用，则仍然可以通过剩余的副本访问片。当一个片只存在一个副本时，该片上的数据很容易在发生额外故障时丢失。每个片的副本数量可以通过全局变量max_failure指定。

当一个片的副本比期望的少时，Rebalancer将在另一个节点上创建一个新的副本，即一个现有副本。最常见的原因是节点失败或变得不可用。最初，集群将为该节点的副本创建恢复队列，以便在该节点返回quorum时更新它们。但是，如果节点在一段较长时间内不可用，则Rebalancer将开始复制集群中其他地方的副本，并将退出恢复队列。

如果某个节点变得永久不可用，则集群的存储容量会减少。如果没有足够的剩余存储容量来创建新的副本，那么Rebalancer将无法做到这一点，而片将仍然处于保护不足的状态。集群不会自动为重新保护片保留容量。

负载不平衡

如果representation的片在集群中分布不均匀，则Rebalancer将尝试将它们移动到更理想的位置。

Rebalancer以以下方式独立评估每个表示的位置:

假设一个representation的每个部分都按其在表示的键空间中所占的比例施加负载。例如，如果一个片的索引大小构成了整个representation的索引空间的10%，那么也将假定片也构成了representation的10%的负载。当放置给定的片副本时，Rebalancer会考虑预期的活动级别。
当“负载最多的”和“负载最少的”节点之间的差异最小时，representation是分布良好的。

考虑以下具有三个大小相等的片(S1、S2和S3)的表示的示例。每个片有两个副本分布在5个节点的集群中。

这是这种表现形式分布不佳的一个例子。每个片都受到保护，防止节点出现故障，但大多数representation存储在节点2上。

这是一个很好的分布的例子。用红色标出的副本被Rebalancer重新定位，以改善集群平衡。尽管节点1比其他节点多一个副本，但没有节点负载不足。

当节点太满时

如果集群中的某个节点持有的表数据超过其共享的数量，则Rebalancer将尝试将副本从该节点移动到利用率较低的节点。

在移动任何副本之前，Rebalancer计算集群存储设备的负载不平衡。如果这个不平衡值低于一个可配置的阈值，那么Rebalancer就会放任不管。这是为了防止Rebalancer进行小的、不必要的复制操作。

平衡存储利用率是维护representation分布的第二个优先级。在某些情况下，这可能导致较低的存储设备利用率，以换取更好的表示分布。

当一片太大的时候

representation被划分成片，每个片被分配到representation行的一部分。如果一个切片变得很大，Rebalancer将把这个切片分割成几个新的切片，并将原始切片的行分布在其中。切片变得越大，在系统中移动或复制它的成本就越高。所需的最大片大小是可配置的，但默认情况下，Rebalancer将使用大于1 GiB的数据来分割片。(由于存储开销，所使用的空间将略大于用户数据的大小)。

太多的片也可能是一个问题:更多的片意味着集群需要管理更多的元数据，这会使查询和组更改花费更长的时间。Rebalancer不会逆转分割，因此通常的建议是宁可少分割一些，如果存在一个representation需要多少片的问题，则允许Rebalancer进行分割。可以使用ALTER语句手动反转分割，以更改representation的分割。

因为行是散列分布在片之间的，如果一个片接近分割阈值，那么representation的其他片也可能需要分割。

全局rebalancer_split_threshold_mb确定片何时需要分割。对于每个表或每个索引，可以通过DDL覆盖该全局变量。看到片。

读不平衡

ClustrixDB仅从每个片的一个副本中进行独占读取，该片被指定为排序副本。这使得Rebalancer可以更好地管理写操作(同时应用于所有副本)和读操作(始终只使用排序副本)的数据分布和负载。

从写的角度来看，这个五层的representation很好地分布在一个五节点集群中。每个节点平均分担一部分工作。

对于读操作，ClustrixDB指定一个副本作为片的排序副本，并始终从该副本进行读取以平衡集群中的负载。

由于一个片的所有副本都是相同的，将读操作定向到一个没有排序的副本将产生相同的结果。然而，为了更好地利用每个节点的内存，ClustrixDB始终从指定的排名副本中读取数据。如果一个排序副本不可用，则另一个副本将取代它。

退役的节点

当要从集群中删除节点时，管理员可以将其指定为软故障。这将指示Rebalancer不要在该节点上放置新的副本，在评估存储不平衡时也不会考虑它。Rebalancer将开始在softfailed节点上复制其他副本，并将它们放在其他节点上。一旦有了足够的副本，就可以从集群中删除softfailed节点，从而丢失数据保护。

平衡组件

Rebalancer是一个由多个组件组成的系统:

收集信息以构建集群状态的模型
任务检查模型并决定是否需要采取行动
任务将操作提交到调度它们的队列
当一个操作从队列中退出时，它被应用到集群中
当操作完成时，将更新模型以反映新的状态

分布模型

关于每个副本的存在和位置的元数据在每个节点上复制，但是每个副本的大小仅在其所在节点的本地知道。

Rebalancer定期轮询集群中的所有节点，以创建当前集群状态的模型。在轮询之间，representation可以由用户创建或销毁，也可以在大小上增减。集群的Rebalancer模型总是有些过时。这意味着它有时会做出次优决策。

任务

定期任务监视每个Rebalancer任务，并根据需要独立调度纠正措施。每个任务共享集群状态的Rebalancer模型，并知道队列中的其他Rebalancer任务。管理员可以调整这些任务的一些参数，包括它们的速率。

Rebalancer任务总结

Name	Fixes	Priority	Rate
Reprotect	Missing replicas	High	Aggressive
Zone Balance	Slice imbalance for a zone	High	Aggressive
Softfail	Slices on decommissioned hardware	High	Moderate
Reap	Extra replicas/queues	High	Moderate
Split	Large slices	Medium	Moderate
Rerank	Node/zone read imbalance	Low	Conservative
Rerank Distribution	Representation read imbalance	Low	Conservative
Rebalance	Node/zone usage imbalance	Low	Conservative
Rebalance Distribution	Representation write imbalance	Low	Conservative

尽管每个任务都是独立的，但它们都经过了调优，因此一个任务的决策不会与另一个任务的决策发生冲突。例如，当一个片被分割时，新片的放置要考虑到representation的其余片和集群存储的容量。这些片的新副本将被正确排序，以便重新排序过程以后不需要进行调整。

Rebalancer 队列

所有受Rebalancer影响的更改都使用优先级队列进行调度。这个队列的设计是为了对Rebalancer进行速率限制，这样它就不会对集群进行过度订阅，包括:

一次可以对一个片应用一个更改。
一些操作，比如重新分配表示，限制了同时执行的数量。
有限数量的操作可以同时影响单个节点。

操作被分配优先级，一个排队的操作可以被一个更高优先级的操作超越。一旦一个操作开始，它就不会被中断，即使队列中有一个高优先级的操作在等待。

由于多种原因，Rebalancer操作可能会失败。如果操作失败，则会恢复对集群所做的任何更改，然后Rebalancer可能会选择重试该操作。因为集群的状态可以在任何时候改变(当Rebalancer正在做决策或操作正在执行时)，所以即使在正常的操作中也会出现一些失败。

在操作完成后，Rebalancer不保留操作的内存，因此反复失败的操作可能会被反复重试。Rebalancer假设任何导致操作失败的条件都是暂时的。

恢复队列和版本控制的元数据

对Representation元数据(包括副本位置)的更改通过类似于表数据的多版本并发控制(MVCC)方案进行版本控制。当一个Representation被更改时，在更改之前启动的事务将不会遵守它。旧事务不会被取消，新事务也不会等待它们。每个集合只是看到元数据的不同视图。这允许在不与当前运行的事务协调的情况下对元数据进行更改。

元数据更改是事务性的，因此如果在执行更改时遇到错误，整个更改将回滚到开始时的状态。

当Rebalancer在两个节点之间移动一个副本时，它会通过一系列特定的DDL更改来实现。在每次更改之间是用户事务可能开始的时间。Rebalancer可以在线执行复制移动，对新事务或正在运行的事务进行有限的中断。联机操作的关键是恢复队列，它是副本在构建过程中丢失的更改日志。(恢复队列不同于Rebalancer的操作优先队列。)下面是一个使用恢复队列的在线复制移动示例。其他Rebalancer操作更加复杂，但操作过程类似。

复制移动的例子

从左到右阅读，这幅图显示了影响复制移动所需的各种步骤。

初始状态-Epoch A

最初，片的副本驻留在节点3和节点4上。我们将这个片从节点4移动到节点1，这里以前不存在这个片的副本。

创建一个新的副本- Epoch B

第一步是在节点1上创建一个新的空副本。这个副本被标记为构建在系统中，这样查询就不会访问它。在节点2上为该副本同时创建一个恢复队列。对于写入片的查询，该队列看起来就像另一个副本，但是它的功能不同:它记录所有的写入，以便以后可以对新的副本重播这些写入。这允许从节点4复制到节点1，而不会阻塞对片的更新。新副本的更改将存储在恢复队列中

数据复制

从原始副本进行的可序列化读取将返回从创建队列时开始的所有行。这些行被发送到新的构建副本。同时，对原始副本的任何更新都将被记录到队列中。

可能会在创建队列之前的epoch A中启动一些事务，这些事务在提交之后尝试修改片。这些事务不会知道队列，因此不会将它们的更新记录到队列中。如果这些事务的更新被serializable副本错过了，那么当原始副本被删除而新副本被联机时，它们的更新将会丢失。因此，系统将导致任何此类事务失败。为了尽量减少这种情况的发生，将复制延迟一段时间(大约1秒)，以允许进程内事务完成。

结束队列

当读取队列中的最后一条记录时，队列将从异步操作变为同步操作。更新将继续存储在队列中，并在允许事务提交之前应用到新副本。

队列翻转-Epoch-C

当到达恢复队列的末尾时，原始副本将退役，而新副本将在线生成。
队列不再由新的事务更新。来自epoch B的旧事务继续写入它，队列保持同步模式，将更新转发到新的副本，现在已经联机。
已退役的副本将继续接收更新，但不会被新事务读取。纪元B中的事务(在翻转之前)仍然可以看到它，并且必须看到片的最新更新。翻转之后，队列不再存储更新记录，因为队列重播已经完成

退休

一旦epoch B中的所有旧事务完成，恢复队列将不再接收任何写操作。队列和退役副本被删除，只保留新的副本。

最后的状态——Epoch D

完成后，副本的片现在驻留在节点1和节点3上。