16. ClustrixDB Rebalancer

管理平衡

Clustrix Rebalancer被设计成自动作为后台进程运行，以便跨集群重新平衡数据。介绍如何配置和监视rebalancer，但是大多数部署不需要用户干预。

Rebalancer主要通过一组全局变量进行管理，可以通过几个系统表进行监控。如Rebalancer一节所述，Rebalancer应用许多操作，如复制、移动复制和分割片，以保持集群中数据的最佳分布。它被设计成以一种最小化对用户查询影响的方式执行这些操作，并且几乎不需要管理操作。但是，在某些情况下，您可能希望增加或减少rebalancer的侵略性，例如在添加节点之后快速地重新平衡集群，或者在高负载期间消除对用户查询的任何可能干扰。

监控Rebalancer

表rebalancer_activity_log维护当前和过去rebalancer工作的记录。要查看最近的活动，order by started，如下所示。您还可以筛选当前执行的rebalancer操作，其中finished为NULL。

检查最近的Rebalancer活动

sql> select * from system.rebalancer_activity_log order by started desc limit ;

+---------------------+-------------+-----------------------------+----------+---------------+------------------------------+------------+---------------------+---------------------+-------+

| id                  | op          | reason                      | database | relation      | representation               | bytes      | started             | finished            | error |

+---------------------+-------------+-----------------------------+----------+---------------+------------------------------+------------+---------------------+---------------------+-------+

|  | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |   | -- :: | -- :: | NULL  |

|  | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |   | -- :: | -- :: | NULL  |

|  | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY |   | -- :: | -- :: | NULL  |

|  | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |   | -- :: | -- :: | NULL  |

|  | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY |  | -- :: | -- :: | NULL  |

|  | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |   | -- :: | -- :: | NULL  |

|  | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY |   | -- :: | -- :: | NULL  |

|  | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |   | -- :: | -- :: | NULL  |

|  | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |   | -- :: | -- :: | NULL  |

|  | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY |   | -- :: | -- :: | NULL  |

+---------------------+-------------+-----------------------------+----------+---------------+------------------------------+------------+---------------------+---------------------+-------+

 rows in set (0.32 sec)

对于正在进行的rebalancer操作的目标/目的地等细节，连接(使用id) rebalancer_activity_targets、rebalancer_copy_activity或rebalancer_splits。这些是vrels (与实际表相对的虚拟关系)，因此只在活动期间填充。

配置Rebalancer

rebalancer的性能是由几个全局变量控制的。

rebalancer_global_task_limit:指定并发rebalancer操作的数量，适用于所有rebalancer操作。
task_rebalancer_%_interval_ms:定义特定rebalancer任务启动时的间隔时间。
rebalancer_rebalance_task_limit:控制并发再平衡任务的数量。
rebalancer_vdev_task_limit:限制触及单个设备的并发rebalancer操作的数量

任务的频率决定了操作(如rebalancer移动)进入队列的频率。当有许多小容器时，复制和移动只需几秒钟。因此，30秒的默认频率可能意味着rebalancer队列操作的频率低于它所能达到的频率。大多数rebalancer任务一次只对有限数量的操作进行排队，这是实现理想平衡随时间变化所需的操作。值得注意的例外是SOFTFAIL，它将在节点或磁盘发生softfailed时对所有要执行的工作进行排队。

对于reprotect之外的操作，rebalancer在启动事务后暂停5秒(默认)，然后开始从源到目标副本的实际复制。这样做是为了减少未完成的用户事务与rebalancer操作冲突的机会，在这种情况下，用户事务将被取消，并出现以下错误:

MVCC serializable scheduler conflict

请注意，reprotect具有更高的优先级，并且不应用此延迟。

以下是调优rebalancer设置的一些常见用例。请咨询Clustrix支持来更改下面没有讨论的参数

增加rebalance性能

根据设计(如Rebalancer中所述)，Rebalancer采用一种比较悠闲的方式跨集群重新平衡数据。由于节点之间的数据不平衡通常需要一些时间才能表现出来，并且通常不会导致显著的性能问题，所以这通常是可以接受的。然而，在某些情况下，更迅速地重新平衡是可取的:

在将集群扩展到更多节点之后，特别是在负载非常低的情况下(或在评估情况下)
在替换失败的节点之后，平衡工作负载对于满足性能需求至关重要

以下是增加rebalancer性能的建议改变:

sql> set global rebalancer_rebalance_task_limit = ;

sql> set global rebalancer_vdev_task_limit = ;

sql> set global task_rebalancer_rebalance_distribution_interval_ms = ;

sql> set global task_rebalancer_rebalance_interval_ms = ;

如果这些设置导致负载过大，则减少rebalancer_rebalance_task_limit或rebalancer_vdev_task_limit。

一旦rebalancer完成，重置这些全局变量为ClustrixDB的默认值:

sql> SET GLOBAL variable_name = DEFAULT;

提高 SOFTFAIL 性能

正如在管理故障和恢复中所描述的，SOFTFAIL是一种从节点(或磁盘)移动所有数据的方法，用于准备使节点退役或替换。通过正确使用软失效，系统保持对所有数据的充分保护;如果节点在没有软失效的情况下被删除，则会出现一个窗口(直到重新保护完成)，其中的一个故障可能会导致数据丢失

软失效被rebalancer视为高优先级。它与重新平衡不同，因为每个任务的限制和任务间隔不适用。改变这两个全局变量可以增加SOFTFAIL的性能:

sql> set global rebalancer_global_task_limit = ;

sql> set global rebalancer_vdev_task_limit = ;

如果这些设置导致负载过大，则减少rebalancer_global_task_limit或rebalancer_vdev_task_limit。

一旦rebalancer完成，重置这些全局变量为ClustrixDB的默认值:

sql> SET GLOBAL variable_name = DEFAULT;

禁用Rebalancer

禁用Rebalancer语法:

sql> set global rebalancer_optional_tasks_enabled = false;

这将禁用重新排序、拆分、重新分发和重新平衡任务。rebalancer_optional_tasks_enabled的值取代了用于配置单个rebalancer任务的全局变量中的值。

不要长时间禁用Rebalancer，因为Rebalancer在保持最佳数据库性能方面起着至关重要的作用

不应该禁用用于重新保护数据的Rebalancer任务(task_rebalancer_reprotect_interval_ms)。

全局变量

以下全局变量影响Rebalancer活动。注意，这些变量并不适用于单个会话。


Name	Description	Default Value
rebalancer_global_task_limit	同时执行rebalancer操作的最大数量。	16
rebalancer_rebalance_task_limit	每次调度rebalancer_imbalanced和rebalancer_rebalance_distribution的最大操作数。	2
rebalancer_rebalance_threshold	总体写负载变化的最小系数，将触发重新平衡活动。	0.05
rebalancer_reprotect_queue_interval_s	在这么多秒内，排队的副本被认为是健康的，以便在rebalancer_reprotect开始复制之前，让丢失的节点有机会重新联机。	600
rebalancer_split_threshold_kb	rebalancer分割片的大小。	1048576
rebalancer_vdev_task_limit	针对一个设备的最大并发rebalancer操作数。	1
task_rebalancer_rebalance_distribution_interval_ms	运行周期性任务之间的毫秒数为“rebalancer_rebalance_distribution”。指定0以禁用定期任务。	30000
task_rebalancer_rebalance_interval_ms	运行周期性任务之间的毫秒数为“rebalancer_rebalance”。指定0以禁用定期任务	30000
task_rebalancer_reprotect_interval_ms	运行周期性任务“rebalancer_reprotect”之间的毫秒数。指定0以禁用定期任务	15000
task_rebalancer_split_interval_ms	运行周期性任务之间的毫秒数为“rebalancer_split”。指定0以禁用定期任务。	30000
task_rebalancer_zone_balance_interval_ms	运行周期性任务之间的毫秒数为“rebalancer_zone_balance”。指定0以禁用定期任务。	60000
task_rebalancer_zone_missing_interval_ms	运行周期性任务之间的毫秒数“rebalancer_zone_missing”。指定0以禁用定期任务.	60000