Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space ML1 and version 5.3
Sv translation
languageen
Info

The Clustrix Rebalancer is designed to run automatically as a background process to rebalance data across the cluster. The following section describes how you can configure and monitor the rebalancer, but the majority of deployments should not require user intervention.

The Rebalancer is managed primarily through a set of global variables, and can be monitored through several system tables (or vrels). As described in the Rebalancer section, the rebalancer applies a number of actions such as copying replicas, moving replicas, and splitting slices in order to maintain an optimal distribution of data on the cluster. It is designed to perform these operations in a manner that minimizes impact to user queries, and requires little administrative action. However, there may be circumstances where you wish to either increase or decrease the aggressiveness of the rebalancer, such as quickly rebalancing the cluster after node addition or eliminating any possible interference with user queries during periods of heavy load.

The sections below will discuss monitoring of rebalancer behavior, and specific use cases of rebalancer tuning.  

Table of Contents
maxLevel1

Anchor
Rebalancer_Monitoring
Rebalancer_Monitoring
Monitoring the Rebalancer

The table rebalancer_activity_log maintains a record of current and past rebalancer work. To see recent activity, order by started, as shown below. You can also filter for currently executing rebalancer actions with WHERE finished IS NULL.

Check recent Rebalancer activity
sql> select * from system.rebalancer_activity_log order by started desc limit 10; 
+---------------------+-------------+-----------------------------+----------+---------------+------------------------------+------------+---------------------+---------------------+-------+
| id                  | op          | reason                      | database | relation      | representation               | bytes      | started             | finished            | error |
+---------------------+-------------+-----------------------------+----------+---------------+------------------------------+------------+---------------------+---------------------+-------+
| 5832803107035702273 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  236879872 | 2017-01-13 05:35:01 | 2017-01-13 05:35:01 | NULL  | 
| 5832802677131749377 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  478674944 | 2017-01-13 05:33:21 | 2017-01-13 05:33:21 | NULL  | 
| 5832802504311179267 | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY |  473628672 | 2017-01-13 05:32:41 | 2017-01-13 05:34:08 | NULL  | 
| 5832791312486337538 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  475987968 | 2017-01-13 04:49:15 | 2017-01-13 04:49:15 | NULL  | 
| 5832791036763671553 | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY | 1195999232 | 2017-01-13 04:48:11 | 2017-01-13 04:49:15 | NULL  | 
| 5832788503671368706 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  754778112 | 2017-01-13 04:38:21 | 2017-01-13 04:38:21 | NULL  | 
| 5832788202047166465 | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY |  471269376 | 2017-01-13 04:37:11 | 2017-01-13 04:38:29 | NULL  | 
| 5832674257801927682 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  754778112 | 2017-01-12 21:15:01 | 2017-01-12 21:15:01 | NULL  | 
| 5832673827981474818 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  471400448 | 2017-01-12 21:13:21 | 2017-01-12 21:13:21 | NULL  | 
| 5832673526398766083 | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY |  755400704 | 2017-01-12 21:12:11 | 2017-01-12 21:13:43 | NULL  | 
+---------------------+-------------+-----------------------------+----------+---------------+------------------------------+------------+---------------------+---------------------+-------+
10 rows in set (0.32 sec)

For details such as target/destination for in-progress rebalancer actions, JOIN (using id) to rebalancer_activity_targets, rebalancer_copy_activity, or rebalancer_splits.  These are vrels (virtual relations, as opposed to actual tables), and so are only populated for the duration of the activity. 

Configuring the Rebalancer

The aggressiveness of the rebalancer is controlled by several global variables. 

  • rebalancer_global_task_limit: specifies the number of concurrent rebalancer actions, applicable to all rebalancer actions.
  • task_rebalancer_%_interval_ms: defines the interval time of when a particular rebalancer task is initiated.
  • rebalancer_rebalance_task_limit: controls the number of concurrent rebalancing tasks.
  • rebalancer_vdev_task_limit: limits the number of concurrent rebalancer actions that touch a single device.

The frequency of the tasks determine how often operations, such as rebalancer moves, may be enqueued. When there are many small containers, the copies and moves take only a few seconds. As such, a default frequency of 30 seconds may mean that the rebalancer queues operations less frequently than it could. Most rebalancer tasks enqueue a limited number of operations at a time, as the required operations to achieve ideal balance change over time. The notable exception is SOFTFAIL, which enqueues all work to be performed once a node or disk has been softfailed.

For operations other than reprotect, the rebalancer pauses for 5 seconds (default) after starting the transaction, before commencing the actual copy from source to target replica. This is done to reduce the chances of an outstanding user transaction conflicting with the rebalancer operation, in which case the user transaction will be canceled, with this error:

MVCC serializable scheduler conflict

Note that reprotect has a higher priority and does not apply this delay.  

The following are some common use cases for tuning the rebalancer settings. Please consult with Clustrix Support to change parameters not discussed below.  

Increasing Rebalance Aggressiveness

By design (as described in Rebalancer) the rebalancer takes a somewhat leisurely approach to rebalancing data across the cluster. Since data imbalances between nodes typically take some time to manifest and generally do not cause significant performance issues, this is generally acceptable. However, in some situations, it is desirable to rebalance much more quickly:

  • After expanding a cluster to more nodes, particularly where load is very low off-peak (or in an evaluation situation)
  • After replacing a failed node, where balanced workload is critical to meeting performance requirements

Following are recommended changes to increase rebalancer aggressiveness:

Increasing Rebalance Aggressiveness
sql> set global rebalancer_rebalance_task_limit = 8;
sql> set global rebalancer_vdev_task_limit = 4;
sql> set global task_rebalancer_rebalance_distribution_interval_ms = 5000;
sql> set global task_rebalancer_rebalance_interval_ms = 5000;

If these settings cause too great a load, reduce the rebalancer_rebalance_task_limit or rebalancer_vdev_task_limit.

Once the rebalancer has finished, reset these globals back to ClustrixDB's default:

sql> SET GLOBAL variable_name = DEFAULT; 

Increasing SOFTFAIL Aggressiveness

As described in Administering Failure and Recovery, SOFTFAIL is a means of moving all data from a node (or disk) in preparation for decommissioning or replacing a node. With proper use of SOFTFAIL, the system maintains full protection of all data; if a node is removed without SOFTFAIL, there is a window (until reprotect completes) where a failure could lead to data loss.

SOFTFAIL is treated as a high priority by the rebalancer. It differs from rebalancing, in that the per-task limit and task intervals do not apply. Changing these two globals can increase SOFTFAIL aggressiveness:

Increasing SOFTFAIL Aggressiveness
sql> set global rebalancer_global_task_limit = 32;
sql> set global rebalancer_vdev_task_limit = 16;

If these settings cause too great a load, reduce the rebalancer_global_task_limit or rebalancer_vdev_task_limit.

Once the rebalancer has finished, reset these globals back to ClustrixDB's default:

sql> SET GLOBAL variable_name = DEFAULT; 

Disabling the Rebalancer 

To disable the Rebalancer:

sql> set global rebalancer_optional_tasks_enabled = false;

This disables the rerank, split, redistribute and rebalance tasks. The value for rebalancer_optional_tasks_enabled supersedes the values in the global variables used to configure the individual rebalancer tasks. 

Warning

Do not leave the Rebalancer disabled for long periods of time, as the Rebalancer plays a crucial role in maintaining optimal database performance.

The Rebalancer tasks for reprotecting data (task_rebalancer_reprotect_interval_ms) should never be disabled. 

Global Variables

The following global variables impact Rebalancer activity. Note that these variables do not apply to an individual sessions.

NameDescriptionDefault Value
rebalancer_global_task_limit Maximum number of simultaneous rebalancer operations.16
rebalancer_rebalance_task_limitMaximum number of operations that rebalancer_imbalanced and rebalancer_rebalance_distribution will each schedule at once.2
rebalancer_rebalance_thresholdMinimum coefficient of overall write load variation that will trigger rebalance activity.0.05
rebalancer_reprotect_queue_interval_sQueued replicas count as healthy for this many seconds, to give missing nodes the chance to come back online before rebalancer_reprotect starts copying.600
rebalancer_split_threshold_kbSize at which the rebalancer splits slices.1048576
rebalancer_vdev_task_limit Maximum number of simultaneous rebalancer operations targeting one device.1
task_rebalancer_rebalance_distribution_interval_ms Milliseconds between runs of periodic task "rebalancer_rebalance_distribution". Specify 0 to disable periodic task.30000
task_rebalancer_rebalance_interval_ms Milliseconds between runs of periodic task "rebalancer_rebalance". Specify 0 to disable periodic task.30000
task_rebalancer_reprotect_interval_ms Milliseconds between runs of periodic task "rebalancer_reprotect". Specify 0 to disable periodic task.15000
task_rebalancer_split_interval_ms Milliseconds between runs of periodic task "rebalancer_split". Specify 0 to disable periodic task.30000
task_rebalancer_zone_balance_interval_msMilliseconds between runs of periodic task "rebalancer_zone_balance". Specify 0 to disable periodic task.60000
task_rebalancer_zone_missing_interval_msMilliseconds between runs of periodic task "rebalancer_zone_missing". Specify 0 to disable periodic task.60000
Sv translation
languageko
Info

Clustrix Rebalancer는 백그라운드 프로세스로 자동 실행되어 클러스터 내 데이터를 재분배합니다. 다음 섹션에서는 rebalancer를 어떻게 조정하고 모니터하는지 설명하고 있습니다. 그러나 대부분의 deploy 환경에서는 효과적인 데이터 분산의 유지를 위해서 사용자 개입이 필요하지 않습니다.

Rebalancer는 주로 글로벌 변수를 통해 관리되며 여러 시스템 테이블(또는 vrels)을 통해 모니터링할 수 있습니다. Rebalancer 섹션에서 설명한 대로, rebalancer는 클러스터에서 최적의 데이터 분산을 유지하기 위해 복제본 복사, 복제본 이동, 슬라이스 분할 또는 재분배와 같은 많은 작업을 수행합니다. 사용자 쿼리에 대한 영향을 최소화하면서 이러한 작업을 수행하도록 설계되었으므로 관리자의 추가 작업이 거의 필요하지 않습니다. 그러나 노드 추가 후 클러스터를 신속히 리밸런싱하거나 부하가 높은 기간 동안 사용자 쿼리와의 간섭현상을 최소화하기 위해서 rebalancer의 워크로드를 높이거나 낮추는 경우가 있습니다.

아래 섹션에서는 rebalancer 모니터링과 rebalancer 튜닝의 구체적인 사용 사례에 관해 설명합니다.

Table of Contents

Rebalancer 모니터링

rebalancer_activity_log 테이블에는 현재 및 과거의 rebalancer 작업에 대한 기록이 있습니다. 최근 활동을 보려면 아래에 나오는 것과 같이 "started"로 정렬하십시오. "WHERE finished IS NULL"을 사용하여 현재 실행 중인 rebalancer 동작을 필터링할 수도 있습니다.

최근 Rebalancer 활동 확인
sql> select * from rebalancer_activity_log order by started desc limit 10; 
+---------------------+-------------+-----------------------------+----------+---------------+------------------------------+------------+---------------------+---------------------+-------+
| id                  | op          | reason                      | database | relation      | representation               | bytes      | started             | finished            | error |
+---------------------+-------------+-----------------------------+----------+---------------+------------------------------+------------+---------------------+---------------------+-------+
| 5832803107035702273 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  236879872 | 2017-01-13 05:35:01 | 2017-01-13 05:35:01 | NULL  | 
| 5832802677131749377 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  478674944 | 2017-01-13 05:33:21 | 2017-01-13 05:33:21 | NULL  | 
| 5832802504311179267 | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY |  473628672 | 2017-01-13 05:32:41 | 2017-01-13 05:34:08 | NULL  | 
| 5832791312486337538 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  475987968 | 2017-01-13 04:49:15 | 2017-01-13 04:49:15 | NULL  | 
| 5832791036763671553 | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY | 1195999232 | 2017-01-13 04:48:11 | 2017-01-13 04:49:15 | NULL  | 
| 5832788503671368706 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  754778112 | 2017-01-13 04:38:21 | 2017-01-13 04:38:21 | NULL  | 
| 5832788202047166465 | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY |  471269376 | 2017-01-13 04:37:11 | 2017-01-13 04:38:29 | NULL  | 
| 5832674257801927682 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  754778112 | 2017-01-12 21:15:01 | 2017-01-12 21:15:01 | NULL  | 
| 5832673827981474818 | rerank      | distribution read imbalance | statd    | statd_history | __idx_statd_history__PRIMARY |  471400448 | 2017-01-12 21:13:21 | 2017-01-12 21:13:21 | NULL  | 
| 5832673526398766083 | slice split | slice too big               | statd    | statd_history | __idx_statd_history__PRIMARY |  755400704 | 2017-01-12 21:12:11 | 2017-01-12 21:13:43 | NULL  | 
+---------------------+-------------+-----------------------------+----------+---------------+------------------------------+------------+---------------------+---------------------+-------+
10 rows in set (0.32 sec)

현재 진행 중인 rebalancer 동작의 target / destination과 같은 세부 사항은 다음을 참조하십시오.

JOIN (using id) to rebalancer_activity_targets, rebalancer_copy_activity, or rebalancer_splits.

여기에 있는 것은 vrels(실제 테이블과 반대되는 가상 relations)이므로 활동 기간 동안만 채워집니다.

Rebalancer 튜닝

Rebalancer의 워크로드는 위에 표시된 여러 글로벌 변수에 의해 제어됩니다.

  • 동시 rebalancer 작업 수(rebalancer_global_task_limit)는 모든 rebalancer 작업에 적용됩니다.
  • 해당 rebalancer 태스크에 대한 작업 빈도는 task_rebalancer_%_interval_ms와 같은 글로벌 변수에 의해 제어됩니다.
  • rebalancer_rebalance_task_limit는 허용된 동시 리밸런싱 태스크의 수를 제어합니다.
  • rebalancer_vdev_task_limit는 단일 디바이스에 적용되는 동시 rebalancer 작업 수를 제한합니다.

태스크 빈도는 이동(move)과 같은 rebalancer 작업이 큐에 추가되는 빈도를 결정합니다. 작은 컨테이너가 많으면 복사 및 이동에 몇 초밖에 걸리지 않습니다. 따라서, 기본 빈도 30초는 rebalancer가 수행할 수 있는 것보다 덜 빈번하게 큐에 추가함을 의미합니다. 이상적인 밸런스를 성취하기 위한 필요한 작업이 시간이 지남에 따라 변경하므로, 대부분의 rebalancer 태스크는 한 번에 제한된 수의 작업을 큐에 추가시킵니다. 주목할 만한 예외는 SOFTFAIL입니다. SOFTFAIL은 노드 또는 디스크가 softfail 된 후 수행할 모든 작업을 큐에 추가합니다.

reprotect 이외의 작업의 경우 rebalancer는 소스에서 대상 복제본으로 실제 복사를 시작하기 전으로 트랜잭션을 시작한 후 5초(기본값) 동안 일시 중지합니다. 이는 현재 대기 중인 사용자 트랜잭션과의 충돌 (또는 상관관계 발생) 가능성을 줄이기 위함입니다. Rebalancer 복사 작업이 실행되면 대기 중인 트랜잭션은 아래의 오류 문자와 함께 취소됩니다.

MVCC serializable scheduler conflict

우선순위가 더 높은 "reprotect"는 지연 없이 바로 실행됩니다.

다음은 rebalancer 설정 조정에 대한 일반적인 사용 사례입니다. 아래에서 설명하지 않은 파리미터를 변경하려면 Clustrix 지원팀에 문의하십시오.

리밸런싱 워크로드 높이기

Rebalancer에서 설명한 대로 Clustrix Rebalancer는 클러스터 전체에 데이터를 리밸런싱함에 있어 다소 여유롭게 처리하도록 설계되었습니다. 일반적으로 노드 간의 데이터 불균형이 나타나기까지 어느 정도 시간이 걸리고 일반적으로 불균형으로 인한 중요한 성능 문제가 바로 발생하지 않기 때문입니다. 그러나 아래와 같은 경우에는 훨씬 더 신속하게 리밸런스를 실행하는 정책이 더 바람직합니다.

  • 클러스터에 더 많은 노드를 추가한 후 (특히 피크 시간이 아니거나 테스트 상황인 경우)
  • 장애가 발생한 노드를 교체한 후 (특별히 균등하게 분산된 워크로드가 성능 요구 사항 충족에 아주 중요한 경우)

다음은 rebalancer 워크로드를 높이기 위한 권장 변경 사항입니다.

리밸런싱 워크로드 높이기
sql> set global rebalancer_rebalance_task_limit = 8;
sql> set global rebalancer_vdev_task_limit = 4;
sql> set global task_rebalancer_rebalance_distribution_interval_ms = 5000;
sql> set global task_rebalancer_rebalance_interval_ms = 5000;

이 설정으로 인해 너무 많은 로드가 발생하면 rebalancer_rebalance_task_limit 또는 rebalancer_vdev_task_limit를 줄이십시오.

Rebalancer가 완료된 후에 이 글로벌 변수를 ClustrixDB 기본값으로 다시 설정하십시오.

sql> SET GLOBAL variable_name = DEFAULT; 

SOFTFAIL 워크로드 늘리기

Administering Failure and Recovery에서 설명한 것처럼 SOFTFAIL은 노드를 폐기 또는 교체하기 위해 노드(또는 디스크)에서 모든 데이터를 이동하는 수단입니다. SOFTFAIL을 적절히 사용하면 시스템의 모든 데이터를 완벽히 보호할 수 있습니다. 그러나, SOFTFAIL 없이 노드를 제거하면 데이터의 재보호(reprotect)가 완료되기 전까지 데이터가 손실될 수 있는 시간대가 존재하게 됩니다.

SOFTFAIL은 rebalancer가 최우선적으로 취급합니다. 태스크 당 제한 및 태스크 간격이 적용되지 않는다는 점에서 리밸런싱과 다릅니다. 이 두 가지 글로벌 변수를 변경하려면 SOFTFAIL 워크로드가 높아질 수 있습니다.

SOFTFAIL 강도 늘리기
sql> set global rebalancer_global_task_limit = 32;
sql> set global rebalancer_vdev_task_limit = 16;

이 설정으로 인해 너무 많은 로드가 발생하면 rebalancer_global_task_limit 또는 rebalancer_vdev_task_limit를 줄이십시오.

Rebalancer가 완료되면 이 글로벌 변수를 ClustrixDB 기본값으로 다시 설정하십시오.

sql> SET GLOBAL variable_name = DEFAULT; 

Rebalancer 비활성화

Warning

Rebalancer가 최적의 데이터베이스 성능을 유지하는 데 중요한 역할을 하므로 장시간 rebalancer를 비활성 상태에 두는 것을 권장하지 않습니다.

Rebalancer를 비활성화하려면 각 rebalancer 태스크 간격을 0으로 설정하십시오.

Rebalancer 비활성화
sql> set global task_rebalancer_rebalance_distribution_interval_ms = 0;
sql> set global task_rebalancer_rebalance_interval_ms = 0;
sql> set global task_rebalancer_redistribute_interval_ms = 0; 
sql> set global task_rebalancer_split_interval_ms = 0; 

데이터 재보호와 관련된 글로벌 변수(task_rebalancer_reprotect_interval_ms)는 디스크 또는 노드 장애 시에만 활성화되므로 재설정할 필요가 없습니다. 뜻하지 않게 비활성화 상태로 두면 이중 장애 발생 시 데이터 손실 가능성이 커집니다.

글로벌 변수

다음 글로벌 변수는 Rebalancer 활동에 영향을 미칩니다. 이 변수는 개별 세션에는 적용되지 않습니다.

변수설명기본값
rebalancer_global_task_limit 동시 rebalancer 작업의 최대 수16
rebalancer_rebalance_task_limitrebalancer_imbalanced 및 rebalancer_rebalance_distribution이 각각 한 번에 스케줄하는 작업의 최대 수2
rebalancer_rebalance_threshold리밸런스를 트리거하는 전체 쓰기 로드 변동의 최소 계수0.05
rebalancer_reprotect_queue_interval_s대기 중인 복제본은 이 값만큼의 초 동안 정상적인 것으로 간주되어 rebalancer_reprotect가 복사를 시작하기 전에 누락된 노드가 온라인으로 돌아갈 수 있는 기회를 제공합니다.600
rebalancer_split_threshold_kbRebalancer가 슬라이스를 분할하는 크기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_redistribute_interval_ms 주기 태스크 "rebalancer_redistribute" 실행 사이 밀리 초. 주기 태스크를 비활성화하려면 0을 지정하십시오.0
task_rebalancer_reprotect_interval_ms 주기 태스크 "rebalancer_reprotect" 실행 사이 밀리 초. 주기 태스크를 비활성화하려면 0을 지정하십시오.15000
task_rebalancer_split_interval_ms 주기 태스크 "rebalancer_split" 실행 사이 밀리 초. 주기 태스크를 비활성화하려면 0을 지정하십시오.30000