데이터 복제본 관리
이 문서는 클러스터 관리자를 대상으로 합니다. Apache Doris의 복제본 균형 조정 및 복구 메커니즘, 스케줄링 우선순위, 복제본 상태 조회 방법, 복제본 이상이나 클러스터 부하 편향에 대응하기 위한 일반적인 운영 방법을 설명합니다.
Doris는 0.9.0 버전부터 최적화된 복제본 관리 전략과 더 다양한 복제본 상태 조회 도구를 제공합니다. 이 문서는 복제본 스케줄링 원리를 이해하고 복제본 손상, 노드 중단, 디스크 사용량 편향 등의 상황에서 클러스터를 빠르게 복구하는 데 도움이 됩니다.
Colocation 속성이 있는 테이블의 복제본 복구 및 균형 조정은 Colocate Join을 참조하세요.
적용 시나리오
| 시나리오 | 권장 절 |
|---|---|
| 복제본 스케줄링 원리 이해 | 복제본 복구, 복제본 균형 조정 |
| 클러스터 전체의 복제본 상태 조회 | 복제본 상태 조회 |
| 특정 Tablet의 비정상 복제본 찾기 | Tablet 단위 상태 확인 |
| BE 중단 또는 디스크 장애 후 수동 복구 | 권장 운영 방법 |
| 복구 및 균형 조정 속도 조절 또는 균형 조정 일시 중지 | 리소스 제어, 관련 설정 |
| 클러스터 부하 편향 또는 불균등한 디스크 사용량 | 복제본 균형 조정 |
용어
| 용어 | 의미 |
|---|---|
| Tablet | Doris 테이블의 논리적 샤드입니다. 하나의 테이블은 여러 샤드로 구성됩니다. |
| 복제본 | 샤드의 사본입니다. 기본적으로 샤드에는 3개의 복제본이 있습니다. |
| 정상 복제본 | Backend가 활성 상태이며 버전이 완전한 복제본입니다. |
| TabletChecker (TC) | 모든 Tablet을 주기적으로 스캔하고 상태를 확인한 후, 그 결과에 따라 Tablet을 TabletScheduler로 보낼지 결정하는 상주 백그라운드 스레드입니다. |
| TabletScheduler (TS) | TabletChecker가 복구를 위해 보낸 Tablet을 처리하고 클러스터 복제본의 균형 조정도 수행하는 상주 백그라운드 스레드입니다. |
| TabletSchedCtx (TSC) | Tablet을 캡슐화한 객체입니다. TC는 Tablet을 선택한 후 TSC로 감싸서 TS에 보냅니다. |
| 스토리지 매체 | 데이터를 저장하는 매체입니다. Doris는 파티션 단위로 서로 다른 스토리지 매체(SSD 및 HDD)를 지정할 수 있습니다. 복제본 스케줄링 전략은 각 스토리지 매체를 별도로 스케줄링합니다. |
전체 작업 흐름은 다음과 같습니다.
+--------+ +-----------+
| Meta | | Backends |
+---^----+ +------^----+
| | | 3. Send clone tasks
1. Check tablets | | |
+--------v------+ +-----------------+
| TabletChecker +--------> TabletScheduler |
+---------------+ +-----------------+
2. Waiting to be scheduled
위 그림은 작업 흐름을 간략히 나타낸 것입니다. TabletChecker는 Tablet 상태를 확인하고 복구가 필요한 Tablet을 TabletScheduler로 보냅니다. TabletScheduler는 BE에 clone 작업을 전달합니다.
복제본 상태
다양한 상황으로 인해 동일한 Tablet의 여러 복제본이 서로 다른 상태가 될 수 있습니다. Doris는 클러스터가 오류 상태에서 최대한 빠르게 복구될 수 있도록 이러한 복제본을 자동으로 복구합니다.
복제본 건전성 상태
| 상태 | 의미 |
|---|---|
| BAD | 복제본이 손상된 상태입니다. 디스크 장애, 버그 등으로 인한 복구 불가능한 손상을 포함하며, 이에 국한되지 않습니다. |
| VERSION_MISSING | 버전이 누락된 상태입니다. Doris에서는 각 데이터 적재 배치가 하나의 데이터 버전에 해당하며, 복제본의 데이터는 여러 개의 연속된 버전으로 구성됩니다. 데이터 적재 오류, 지연 등의 이유로 일부 복제본의 데이터 버전이 불완전할 수 있습니다. |
| HEALTHY | 정상 복제본입니다. 데이터가 정상이며, 복제본이 있는 BE 노드도 정상 상태입니다(하트비트가 정상이고 노드가 서비스 해제 중이 아님). |
Tablet 건전성 상태
Tablet의 건전성 상태는 모든 복제본의 상태에 따라 결정됩니다. 다음과 같은 상태가 있습니다.
| 상태 | 의미 |
|---|---|
| REPLICA_MISSING | 복제본이 누락된 상태입니다. 활성 복제본 수가 예상 복제본 수보다 적습니다. |
| VERSION_INCOMPLETE | 활성 복제본 수는 예상 복제본 수 이상이지만, 정상 복제본 수가 예상 수보다 적습니다. |
| REPLICA_RELOCATING | 완전한 버전을 가진 활성 복제본 수는 replication num과 같지만, 이러한 복제본이 있는 BE 노드 중 일부를 사용할 수 없습니다(예: 서비스 해제 중). |
| REPLICA_MISSING_IN_CLUSTER | 다중 클러스터 환경에서 정상 복제본 수는 예상 수 이상이지만, 해당 클러스터 내의 복제본 수가 예상 수보다 적습니다. |
| REDUNDANT | 복제본이 초과된 상태입니다. 모든 정상 복제본이 해당 클러스터 내에 있지만 그 수가 예상 수를 초과하거나, 사용할 수 없는 복제본이 추가로 존재합니다. |
| FORCE_REDUNDANT | 특수한 상태입니다. "기존 복제본 수 >= 사용 가능한 노드 수 >= 예상 복제본 수이고, 활성 복제본 수 < 예상 복제본 수"인 경우에만 나타납니다. 이 경우 새 복제본을 생성할 노드를 확보하기 위해 먼저 복제본 하나를 삭제해야 합니다. |
| COLOCATE_MISMATCH | Colocation 테이블에만 해당하는 샤드 상태입니다. 샤드 복제본의 분포가 Colocation Group에 지정된 분포와 일치하지 않습니다. |
| COLOCATE_REDUNDANT | Colocation 테이블에만 해당하는 샤드 상태입니다. Colocation 테이블의 샤드 복제본이 초과되어 있습니다. |
| HEALTHY | 정상 샤드로, 위의 1~8번 조건 중 어느 것에도 해당하지 않습니다. |
복제본 복구
TabletChecker는 상주 백그라운드 프로세스로서 모든 샤드의 상태를 주기적으로 확인합니다. 비정상 상태의 샤드는 스케줄링과 복구를 위해 TabletScheduler로 전달됩니다. 실제 복구 작업은 BE의 clone 작업이 수행하며, FE는 이러한 clone 작업을 생성하는 역할만 담당합니다.
참고 1: 복제본 복구의 기본 원리는 먼저 복제본을 생성하거나 보충하여 예상 수를 맞춘 다음, 초과 복제본을 삭제하는 것입니다.
참고 2: clone 작업은 지정된 원격 BE에서 지정된 대상 BE로 특정 데이터를 복사하는 과정입니다.
상태별 복구 방법
Doris는 상태에 따라 서로 다른 복구 방법을 사용합니다.
-
REPLICA_MISSING / REPLICA_RELOCATING
사용 가능하고 부하가 낮은 BE 노드를 대상으로 선택하고, 정상 복제본을 원본으로 선택합니다. clone 작업은 원본에서 대상으로 완전한 복제본을 복사합니다. 복제본을 보충할 때는 스토리지 매체를 고려하지 않고 사용 가능한 BE 노드를 바로 선택합니다.
-
VERSION_INCOMPLETE
비교적 완전한 복제본을 대상으로 선택하고, 정상 복제본을 원본으로 선택합니다. clone 작업은 원본에서 누락된 버전을 복사하여 대상 복제본을 보완합니다.
-
REPLICA_MISSING_IN_CLUSTER
REPLICA_MISSING과 동일하게 처리합니다.
-
REDUNDANT
복제본 복구 후에는 일반적으로 샤드에 초과 복제본이 생깁니다. 초과 복제본 중 하나를 선택하여 삭제합니다. 삭제할 복제본은 다음 우선순위에 따라 선택합니다.
- 복제본이 있는 BE의 서비스 해제가 완료됨
- 복제본이 손상됨
- 복제본이 있는 BE에 연결할 수 없거나 BE가 서비스 해제 중임
- 복제본이 CLONE 상태임(clone 작업 실행 중의 중간 상태)
- 복제본에 누락된 버전이 있음
- 복제본이 잘못된 클러스터에 있음
- 복제본이 있는 BE의 부하가 높음
-
FORCE_REDUNDANT
REDUNDANT와 달리, 이 경우에는 활성 복제본 수가 예상 수보다 적지만 새 복제본을 생성할 수 있는 추가 노드가 없습니다. 따라서 새 복제본을 생성할 노드를 확보하기 위해 먼저 복제본 하나를 삭제해야 합니다. 복제본 삭제 순서는 REDUNDANT와 동일합니다.
-
COLOCATE_MISMATCH
Colocation Group의 복제본 분포에 지정된 BE 노드 중 하나를 복제본 보충 대상 노드로 선택합니다.
-
COLOCATE_REDUNDANT
Colocation Group의 복제본 분포에 지정되지 않은 BE 노드의 복제본을 삭제합니다.
Doris는 복제본 노드를 선택할 때 동일한 Tablet의 복제본을 같은 호스트의 서로 다른 BE에 배치하지 않습니다. 따라서 같은 호스트의 모든 BE가 중단되더라도 모든 복제본이 손실되는 것을 방지할 수 있습니다.
스케줄링 우선순위
TabletScheduler에서 스케줄링을 기다리는 샤드에는 상태에 따라 서로 다른 우선순위가 부여됩니다. 우선순위가 높은 샤드부터 스케줄링됩니다. 현재 다음과 같은 우선순위가 있습니다.
| 우선순위 | 적용 조건 |
|---|---|
| VERY_HIGH | REDUNDANT: 초과 복제본이 있는 샤드입니다. 긴급성은 가장 낮지만 가장 빠르게 처리할 수 있고 디스크 공간과 기타 리소스를 신속하게 확보할 수 있으므로 먼저 처리합니다. FORCE_REDUNDANT: 위와 동일합니다. |
| HIGH | REPLICA_MISSING이며 대부분의 복제본이 누락됨(예: 3개 중 2개 손실). VERSION_INCOMPLETE이며 대부분의 복제본에 누락된 버전이 있음. COLOCATE_MISMATCH: Colocation 테이블과 관련된 샤드는 가능한 한 빨리 복구해야 함. COLOCATE_REDUNDANT. |
| NORMAL | REPLICA_MISSING이지만 대부분의 복제본이 활성 상태임(예: 3개 중 1개 손실). VERSION_INCOMPLETE이지만 대부분의 복제본이 완전한 버전을 가지고 있음. REPLICA_RELOCATING이며 대부분의 복제본을 재배치해야 함(예: 3개 중 2개). |
| LOW | REPLICA_MISSING_IN_CLUSTER. REPLICA_RELOCATING이지만 대부분의 복제본이 안정적인 상태임. |
수동 우선순위 설정
스케줄링 우선순위는 시스템이 자동으로 결정합니다. 그러나 특정 테이블이나 파티션을 더 빠르게 복구하려면 다음 명령으로 해당 테이블 또는 파티션에 우선 복구를 지정할 수 있습니다.
ADMIN REPAIR TABLE tbl [PARTITION (p1, p2, ...)];
이 명령은 TabletChecker가 Tablet을 스캔할 때 우선 복구로 표시된 테이블 또는 파티션에서 문제가 있는 Tablet에 VERY_HIGH 우선순위를 부여하도록 알립니다.
참고: 이 명령은 힌트일 뿐이며 복구 성공을 보장하지 않습니다. TabletScheduler의 스케줄링 과정에서 우선순위가 변경될 수 있습니다. Master FE가 전환되거나 재시작되면 이 정보는 사라집니다.
우선순위를 취소하려면 다음 명령을 사용합니다.
ADMIN CANCEL REPAIR TABLE tbl [PARTITION (p1, p2, ...)];
우선순위 동적 조정
우선순위를 통해 심하게 손상된 샤드를 먼저 복구하여 시스템 가용성을 높일 수 있습니다. 그러나 우선순위가 높은 복구 작업이 계속 실패하면 우선순위가 낮은 작업은 스케줄링되지 못할 수 있습니다. 따라서 Doris는 모든 작업에 스케줄링 기회가 주어지도록 실행 상태에 따라 작업 우선순위를 동적으로 조정합니다.
- 스케줄링이 연속으로 5회 실패하면(예: 리소스를 확보하지 못하거나 적절한 원본 또는 대상을 찾지 못한 경우) 우선순위를 낮춥니다.
- 작업이 30분 동안 스케줄링되지 않으면 우선순위를 높입니다.
- 동일한 Tablet 작업의 우선순위는 5분마다 최대 한 번 조정합니다.
초기 우선순위의 중요도를 유지하기 위해 다음 규칙을 적용합니다. 초기 우선순위가 VERY_HIGH이면 NORMAL까지만 낮추고, 초기 우선순위가 LOW이면 HIGH까지만 높입니다. 이 동적 조정은 사용자가 수동으로 설정한 우선순위에도 적용됩니다.
복제본 균형 조정
Doris는 클러스터 내에서 복제본 균형 조정을 자동으로 수행합니다. 현재 부하 균형 조정과 파티션 균형 조정이라는 두 가지 전략을 지원합니다.
| 전략 | 주요 목표 | 적용 시나리오 | 참고 |
|---|---|---|---|
| 부하 균형 조정 | 노드의 디스크 사용량과 복제본 수를 모두 균등하게 조정 | 디스크 용량과 복제본 균형을 모두 고려해야 하는 경우 | 두 가지 측면을 사용하여 점수 계산 |
| 파티션 균형 조정 | 각 파티션의 복제본을 노드에 균등하게 분산 | 파티션 읽기/쓰기 요구 수준이 높고 핫스팟을 방지해야 하는 경우 | 디스크 사용량을 고려하지 않으므로 디스크 용량에 주의 필요 |
이 전략은 FE 시작 전에 tablet_rebalancer_type으로만 설정할 수 있으며, 실행 중 전환은 지원하지 않습니다.
어떤 전략을 사용하든 복제본 균형 조정은 동일한 Tablet의 복제본이 같은 호스트의 BE에 배치되지 않도록 합니다.
부하 균형 조정
부하 균형 조정의 기본 원리는 특정 샤드에 대해 먼저 부하가 낮은 노드에 복제본을 생성한 다음, 부하가 높은 노드에서 해당 샤드의 복제본을 삭제하는 것입니다. 또한 서로 다른 스토리지 매체가 존재하므로 같은 클러스터의 BE 노드에는 한두 종류의 스토리지 매체가 있을 수 있습니다. 스토리지 매체가 A인 샤드는 균형 조정 후에도 가능한 한 스토리지 매체 A에 저장되어야 합니다. 따라서 클러스터의 BE 노드를 스토리지 매체별로 나누고, 각 스토리지 매체의 BE 노드 그룹에 대해 부하 균형 조정 스케줄링을 별도로 수행합니다.
BE 노드 부하
ClusterLoadStatistics(CLS)는 클러스터 내 각 Backend의 부하 균형 상태를 나타냅니다. TabletScheduler는 이 통계를 사용하여 클러스터 균형 조정을 시작합니다. 현재 각 BE의 부하 점수인 loadScore는 디스크 사용률과 복제본 수라는 두 지표를 사용하여 계산합니다. 점수가 높을수록 BE의 부하가 높습니다.
디스크 사용률과 복제본 수에는 각각 capacityCoefficient와 replicaNumCoefficient라는 가중치 계수가 있으며, 두 계수의 합은 항상 1입니다.
- 유효한
backend_load_capacity_coeficient매개변수가 설정되어 있으면(값 범위:0.0~1.0)capacityCoefficient = backend_load_capacity_coeficient가 됩니다. - 그렇지 않으면 실제 디스크 사용률에 따라
capacityCoefficient가 동적으로 조정됩니다.- BE의 전체 디스크 사용률이 50% 미만이면
capacityCoefficient는 0.5입니다. - 디스크 사용률이 75%를 초과하면(FE 설정 항목
capacity_used_percent_high_water로 조정 가능) 값은 1입니다. - 사용률이 50%에서 75% 사이이면 다음 공식에 따라 가중치 계수가 점진적으로 증가합니다.
- BE의 전체 디스크 사용률이 50% 미만이면
capacityCoefficient = 2 * disk usage - 0.5
이 가중치 계수는 디스크 사용률이 너무 높을 때 Backend의 부하 점수를 높여 BE의 부하를 가능한 한 빠르게 줄일 수 있도록 합니다.
TabletScheduler는 20초마다 CLS를 갱신합니다.
파티션 균형 조정
파티션 균형 조정의 기본 원리는 각 Backend에 있는 각 파티션의 복제본 수 차이, 즉 파티션 편향을 최소화하는 것입니다. 따라서 디스크 사용률은 고려하지 않고 복제본 수만 고려합니다.
마이그레이션 횟수를 최소화하기 위해 파티션 균형 조정은 이차원 탐욕 전략을 사용하며, 파티션 편향이 가장 큰 파티션부터 균형을 조정합니다. 파티션의 균형을 조정할 때는 클러스터 전체에서 Backend 간 복제본 수 차이, 즉 클러스터 편향/전체 편향을 줄이는 방향을 선택합니다.
편향 통계
편향 통계는 ClusterBalanceInfo로 표현됩니다.
partitionInfoBySkew: 파티션 편향을 키로 정렬하여 최대 파티션 편향을 쉽게 찾을 수 있도록 합니다.beByTotalReplicaCount: 각 Backend의 전체 복제본 수를 키로 정렬합니다.
ClusterBalanceInfo도 CLS에 저장되며 20초마다 갱신됩니다. 최대 파티션 편향을 가진 파티션이 여러 개일 수 있으며, 이 경우 하나를 무작위로 선택하여 계산합니다.
균형 조정 전략의 스케줄링
각 스케줄링 라운드에서 TabletScheduler는 LoadBalancer를 사용하여 일정 수의 정상 샤드를 균형 조정 후보로 선택합니다. 다음 스케줄링 라운드에서는 이러한 후보 샤드를 바탕으로 균형 조정 스케줄링을 시도합니다.
리소스 제어
복제본 복구와 균형 조정은 모두 BE 간 복제본 복사를 통해 수행됩니다. 동일한 BE에서 너무 많은 작업을 동시에 실행하면 상당한 IO 부하가 발생합니다. 따라서 Doris는 스케줄링 시 각 노드에서 실행할 수 있는 작업 수를 제어합니다.
| 리소스 | 설명 |
|---|---|
| 리소스 제어 단위 | 최소 단위는 디스크, 즉 be.conf에 지정된 데이터 경로입니다. |
| 복제본 복구 슬롯 | 각 디스크에는 기본적으로 2개의 슬롯이 있습니다. clone 작업은 원본과 대상에서 각각 슬롯 하나를 사용합니다. 사용 가능한 슬롯이 0이면 더 이상 작업을 할당하지 않습니다. 슬롯 수는 FE의 schedule_slot_num_per_hdd_path 또는 schedule_slot_num_per_ssd_path로 조정할 수 있습니다. |
| 균형 조정 작업 슬롯 | 각 디스크는 기본적으로 균형 조정 작업용 독립 슬롯 2개를 제공합니다. 복구 작업이 슬롯을 점유하여 부하가 높은 노드가 균형 조정으로 공간을 확보하지 못하는 상황을 방지하기 위한 것입니다. |
복제본 상태 조회
복제본 상태 조회는 주로 복제본의 상태와 복제본 복구 및 균형 조정 작업의 실행 상태를 파악하는 데 사용합니다. 이러한 상태 정보는 대부분 Master FE 노드에만 존재하므로, 다음 명령은 Master FE에 직접 연결하여 실행해야 합니다.
복제본 상태
전체 상태 확인
SHOW PROC '/cluster_health/tablet_health'; 명령으로 전체 클러스터의 복제본 상태를 조회할 수 있습니다.
+-------+--------------------------------+-----------+------------+-------------------+----------------------+----------------------+--------------+----------------------------+-------------------------+-------------------+---------------------+----------------------+----------------------+------------------+-----------------------------+-----------------+-------------+------------+
| DbId | DbName | TabletNum | HealthyNum | ReplicaMissingNum | VersionIncompleteNum | ReplicaRelocatingNum | RedundantNum | ReplicaMissingInClusterNum | ReplicaMissingForTagNum | ForceRedundantNum | ColocateMismatchNum | ColocateRedundantNum | NeedFurtherRepairNum | UnrecoverableNum | ReplicaCompactionTooSlowNum | InconsistentNum | OversizeNum | CloningNum |
+-------+--------------------------------+-----------+------------+-------------------+----------------------+----------------------+--------------+----------------------------+-------------------------+-------------------+---------------------+----------------------+----------------------+------------------+-----------------------------+-----------------+-------------+------------+
| 10005 | default_cluster:doris_audit_db | 84 | 84 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 13402 | default_cluster:ssb1 | 709 | 708 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 10108 | default_cluster:tpch1 | 278 | 278 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Total | 3 | 1071 | 1070 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+-------+--------------------------------+-----------+------------+-------------------+----------------------+----------------------+--------------+----------------------------+-------------------------+-------------------+---------------------+----------------------+----------------------+------------------+-----------------------------+-----------------+-------------+------------+
주요 열에 대한 설명은 다음과 같습니다.
HealthyNum: 해당 데이터베이스에서 정상 상태인 Tablet 수입니다.ReplicaCompactionTooSlowNum: 복제본의 버전 수가 너무 많은 Tablet 수입니다.InconsistentNum: 복제본 간에 불일치가 있는 Tablet 수입니다.Total행: 클러스터 전체의 통계입니다. 정상적인 경우TabletNum과HealthyNum은 같아야 합니다. 다르면 세부 정보를 조회하여 해당 Tablet을 찾을 수 있습니다.
예를 들어, ssb1 데이터베이스에는 비정상 상태인 Tablet이 1개 있습니다. 다음 명령으로 해당 Tablet을 조회할 수 있습니다. 여기서 13402는 해당 DbId입니다.
SHOW PROC '/cluster_health/tablet_health/13402';
+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+
| ReplicaMissingTablets | VersionIncompleteTablets | ReplicaRelocatingTablets | RedundantTablets | ReplicaMissingInClusterTablets | ReplicaMissingForTagTablets | ForceRedundantTablets | ColocateMismatchTablets | ColocateRedundantTablets | NeedFurtherRepairTablets | UnrecoverableTablets | ReplicaCompactionTooSlowTablets | InconsistentTablets | OversizeTablets |
+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+
| 14679 | | | | | | | | | | | | | |
+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+
출력에는 ReplicaMissing 상태인 비정상 Tablet의 ID(예: 14679)가 표시됩니다. 다음 절에서는 특정 Tablet의 각 복제본 상태를 조회하는 방법을 설명합니다.
테이블(파티션) 단위 상태 확인
다음 명령으로 지정된 테이블 또는 파티션의 복제본 상태를 조회할 수 있으며, WHERE 절로 상태를 필터링할 수 있습니다. 예를 들어, 파티션 p1과 p2에서 상태가 OK인 복제본을 조회하려면 테이블 tbl1에 대해 다음 명령을 실행합니다.
SHOW REPLICA STATUS FROM tbl1 PARTITION (p1, p2) WHERE STATUS = "OK";
+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
| TabletId | ReplicaId | BackendId | Version | LastFailedVersion | LastSuccessVersion | CommittedVersion | SchemaHash | VersionNum | IsBad | State | Status |
+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
| 29502429 | 29502432 | 10006 | 2 | -1 | 2 | 1 | -1 | 2 | false | NORMAL | OK |
| 29502429 | 36885996 | 10002 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
| 29502429 | 48100551 | 10007 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
| 29502433 | 29502434 | 10001 | 2 | -1 | 2 | 1 | -1 | 2 | false | NORMAL | OK |
| 29502433 | 44900737 | 10004 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
| 29502433 | 48369135 | 10006 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
이 출력은 모든 복제본의 상태를 보여 줍니다.
IsBad값이true이면 복제본이 손상되었음을 의미합니다.Status열은 다른 상태를 표시합니다. 자세한 내용은HELP SHOW REPLICA STATUS;를 실행하여 확인하세요.
SHOW REPLICA STATUS 명령은 주로 복제본의 건전성 상태를 조회하는 데 사용합니다. 복제본에 대한 추가 정보를 조회하려면 다음 명령을 사용합니다.
SHOW TABLETS FROM tbl1;
+----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
| TabletId | ReplicaId | BackendId | SchemaHash | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | DataSize | RowCount | State | LstConsistencyCheckTime | CheckVersion | CheckVersionHash | VersionCount | PathHash | MetaUrl | CompactionStatus |
+----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
| 29502429 | 29502432 | 10006 | 1421156361 | 2 | 0 | 2 | 0 | -1 | 0 | N/A | 784 | 0 | NORMAL | N/A | -1 | -1 | 2 | -5822326203532286804 | url | url |
| 29502429 | 36885996 | 10002 | 1421156361 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | 784 | 0 | NORMAL | N/A | -1 | -1 | 2 | -1441285706148429853 | url | url |
| 29502429 | 48100551 | 10007 | 1421156361 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | 784 | 0 | NORMAL | N/A | -1 | -1 | 2 | -4784691547051455525 | url | url |
+----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
위 출력에는 복제본 크기, 행 수, 버전 수, 복제본이 있는 데이터 경로 등의 추가 정보가 표시됩니다.
참고: 여기서
State열의 내용은 복제본의 건전성 상태가 아니라 CLONE, SCHEMA_CHANGE, ROLLUP 등 복제본의 작업 상태를 나타냅니다.
또한 다음 명령으로 지정된 테이블 또는 파티션의 복제본 분포를 조회하여 균등하게 분산되어 있는지 확인할 수 있습니다.
SHOW REPLICA DISTRIBUTION FROM tbl1;
+-----------+------------+-------+---------+
| BackendId | ReplicaNum | Graph | Percent |
+-----------+------------+-------+---------+
| 10000 | 7 | | 7.29 % |
| 10001 | 9 | | 9.38 % |
| 10002 | 7 | | 7.29 % |
| 10003 | 7 | | 7.29 % |
| 10004 | 9 | | 9.38 % |
| 10005 | 11 | > | 11.46 % |
| 10006 | 18 | > | 18.75 % |
| 10007 | 15 | > | 15.62 % |
| 10008 | 13 | > | 13.54 % |
+-----------+------------+-------+---------+
출력에는 각 BE 노드에 있는 테이블 tbl1의 복제본 수와 비율이 간단한 그래프와 함께 표시됩니다.
Tablet 단위 상태 확인
특정 Tablet을 찾아야 할 때는 다음 명령을 사용합니다. 예를 들어, ID가 29502553인 Tablet을 조회하려면 다음과 같이 실행합니다.
SHOW TABLET 29502553;
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
| DbName | TableName | PartitionName | IndexName | DbId | TableId | PartitionId | IndexId | IsSync | DetailCmd |
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
| default_cluster:test | test | test | test | 29502391 | 29502428 | 29502427 | 29502428 | true | SHOW PROC '/dbs/29502391/29502428/partitions/29502427/29502428/29502553'; |
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
출력에는 Tablet이 속한 데이터베이스, 테이블, 파티션, rollup 테이블 등의 정보가 표시됩니다. DetailCmd 열의 명령을 복사하여 실행합니다.
SHOW PROC '/dbs/29502391/29502428/partitions/29502427/29502428/29502553';
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
| ReplicaId | BackendId | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | SchemaHash | DataSize | RowCount | State | IsBad | VersionCount | PathHash | MetaUrl | CompactionStatus |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
| 43734060 | 10004 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | -8566523878520798656 | url | url |
| 29502555 | 10002 | 2 | 0 | 2 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | 1885826196444191611 | url | url |
| 39279319 | 10007 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | 1656508631294397870 | url | url |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
출력에는 해당 Tablet의 모든 복제본 상태가 표시됩니다. 내용은 SHOW TABLETS FROM tbl1;과 같지만, 특정 Tablet 하나의 모든 복제본 상태를 명확하게 확인할 수 있습니다.
복제본 스케줄링 작업
다음 명령으로 대기 중, 실행 중, 완료된 스케줄링 작업을 각각 조회할 수 있습니다.
| 상태 | 명령 |
|---|---|
| 대기 중 | SHOW PROC '/cluster_balance/pending_tablets'; |
| 실행 중 | SHOW PROC '/cluster_balance/running_tablets'; |
| 완료 | SHOW PROC '/cluster_balance/history_tablets'; |
출력 예시(pending_tablets):
+----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
| TabletId | Type | Status | State | OrigPrio | DynmPrio | SrcBe | SrcPath | DestBe | DestPath | Timeout | Create | LstSched | LstVisit | Finished | Rate | FailedSched | FailedRunning | LstAdjPrio | VisibleVer | VisibleVerHash | CmtVer | CmtVerHash | ErrMsg |
+----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
| 4203036 | REPAIR | REPLICA_MISSING | PENDING | HIGH | LOW | -1 | -1 | -1 | -1 | 0 | 2019-02-21 15:00:20 | 2019-02-24 11:18:41 | 2019-02-24 11:18:41 | N/A | N/A | 2 | 0 | 2019-02-21 15:00:43 | 1 | 0 | 2 | 0 | unable to find source replica |
+----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
각 열의 의미는 다음과 같습니다.
| 열 | 의미 |
|---|---|
| TabletId | 스케줄링을 기다리는 Tablet의 ID입니다. 하나의 스케줄링 작업은 하나의 Tablet만 대상으로 합니다. |
| Type | 작업 유형: REPAIR 또는 BALANCE입니다. |
| Status | REPLICA_MISSING 등 Tablet의 현재 상태입니다. |
| State | 스케줄링 작업 상태: PENDING / RUNNING / FINISHED / CANCELLED / TIMEOUT / UNEXPECTED입니다. |
| OrigPrio | 초기 우선순위입니다. |
| DynmPrio | 동적 조정 후의 현재 우선순위입니다. |
| SrcBe | 원본 BE 노드의 ID입니다. |
| SrcPath | 원본 BE 노드 경로의 해시 값입니다. |
| DestBe | 대상 BE 노드의 ID입니다. |
| DestPath | 대상 BE 노드 경로의 해시 값입니다. |
| Timeout | 작업이 성공적으로 스케줄링된 후 적용되는 제한 시간이며, 단위는 초입니다. |
| Create | 작업이 생성된 시각입니다. |
| LstSched | 작업이 마지막으로 스케줄링된 시각입니다. |
| LstVisit | 작업에 마지막으로 접근한 시각입니다. 여기서 "접근"은 스케줄링과 작업 실행 보고를 포함하여 작업과 관련된 모든 처리를 의미합니다. |
| Finished | 작업이 완료된 시각입니다. |
| Rate | clone 작업의 데이터 복사 속도입니다. |
| FailedSched | 작업 스케줄링이 실패한 횟수입니다. |
| FailedRunning | 작업 실행이 실패한 횟수입니다. |
| LstAdjPrio | 우선순위가 마지막으로 조정된 시각입니다. |
| CmtVer / CmtVerHash / VisibleVer / VisibleVerHash | clone 작업 실행에 사용되는 버전 정보입니다. |
| ErrMsg | 작업 스케줄링 및 실행 중 발생한 오류 메시지입니다. |
running_tablets의 각 열은 pending_tablets와 의미가 같습니다.
history_tablets는 기본적으로 최근 완료된 작업 1000개만 보관합니다. 각 열의 의미는 위와 같습니다.
State값이FINISHED이면 작업이 정상적으로 완료되었음을 의미합니다.- 그 외의 값은
ErrMsg열의 오류 메시지를 바탕으로 원인을 진단할 수 있습니다.
클러스터 부하 및 스케줄링 리소스 조회
클러스터 부하
다음 명령으로 클러스터의 현재 부하를 조회할 수 있습니다.
SHOW PROC '/cluster_balance/cluster_load_stat/location_default';
먼저 스토리지 매체별 구분이 표시됩니다.
+---------------+
| StorageMedium |
+---------------+
| HDD |
| SSD |
+---------------+
특정 스토리지 매체의 세부 정보를 조회하면 해당 매체가 있는 BE 노드의 균형 상태를 확인할 수 있습니다.
SHOW PROC '/cluster_balance/cluster_load_stat/location_default/HDD';
+----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
| BeId | Cluster | Available | UsedCapacity | Capacity | UsedPercent | ReplicaNum | CapCoeff | ReplCoeff | Score | Class |
+----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
| 10003 | default_cluster | true | 3477875259079 | 19377459077121 | 17.948 | 493477 | 0.5 | 0.5 | 0.9284678149967587 | MID |
| 10002 | default_cluster | true | 3607326225443 | 19377459077121 | 18.616 | 496928 | 0.5 | 0.5 | 0.948660871419998 | MID |
| 10005 | default_cluster | true | 3523518578241 | 19377459077121 | 18.184 | 545331 | 0.5 | 0.5 | 0.9843539990641831 | MID |
| 10001 | default_cluster | true | 3535547090016 | 19377459077121 | 18.246 | 558067 | 0.5 | 0.5 | 0.9981869446537612 | MID |
| 10006 | default_cluster | true | 3636050364835 | 19377459077121 | 18.764 | 547543 | 0.5 | 0.5 | 1.0011489897614072 | MID |
| 10004 | default_cluster | true | 3506558163744 | 15501967261697 | 22.620 | 468957 | 0.5 | 0.5 | 1.0228319835582569 | MID |
| 10007 | default_cluster | true | 4036460478905 | 19377459077121 | 20.831 | 551645 | 0.5 | 0.5 | 1.057279369420761 | MID |
| 10000 | default_cluster | true | 4369719923760 | 19377459077121 | 22.551 | 547175 | 0.5 | 0.5 | 1.0964036415787461 | MID |
+----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
각 열의 의미는 다음과 같습니다.
| 열 | 의미 |
|---|---|
| Available | 값이 true이면 BE의 하트비트가 정상이고 서비스 해제 중이 아님을 의미합니다. |
| UsedCapacity | BE가 이미 사용 중인 디스크 공간이며, 단위는 바이트입니다. |
| Capacity | BE의 전체 디스크 공간이며, 단위는 바이트입니다. |
| UsedPercent | BE의 디스크 공간 사용률이며, 단위는 백분율입니다. |
| ReplicaNum | BE에 있는 복제본 수입니다. |
| CapCoeff / ReplCoeff | 디스크 공간과 복제본 수에 대한 가중치 계수입니다. |
| Score | 부하 점수입니다. 점수가 높을수록 부하가 높습니다. |
| Class | 부하 수준에 따른 분류: LOW / MID / HIGH입니다. 균형 조정 스케줄링은 부하가 높은 노드에서 낮은 노드로 복제본을 마이그레이션합니다. |
더 상세하게 조회하여 특정 BE의 각 경로 사용량을 확인할 수 있습니다. 예를 들어, ID가 10001인 BE를 조회하려면 다음과 같이 실행합니다.
SHOW PROC '/cluster_balance/cluster_load_stat/location_default/HDD/10001';
+------------------+------------------+---------------+---------------+---------+--------+----------------------+
| RootPath | DataUsedCapacity | AvailCapacity | TotalCapacity | UsedPct | State | PathHash |
+------------------+------------------+---------------+---------------+---------+--------+----------------------+
| /home/disk4/palo | 498.757 GB | 3.033 TB | 3.525 TB | 13.94 % | ONLINE | 4883406271918338267 |
| /home/disk3/palo | 704.200 GB | 2.832 TB | 3.525 TB | 19.65 % | ONLINE | -5467083960906519443 |
| /home/disk1/palo | 512.833 GB | 3.007 TB | 3.525 TB | 14.69 % | ONLINE | -7733211489989964053 |
| /home/disk2/palo | 881.955 GB | 2.656 TB | 3.525 TB | 24.65 % | ONLINE | 4870995507205544622 |
| /home/disk5/palo | 694.992 GB | 2.842 TB | 3.525 TB | 19.36 % | ONLINE | 1916696897889786739 |
+------------------+------------------+---------------+---------------+---------+--------+----------------------+
출력에는 지정된 BE의 각 데이터 경로에 대한 디스크 사용량이 표시됩니다.
스케줄링 리소스
다음 명령으로 각 노드의 슬롯 사용 현황을 조회할 수 있습니다.
SHOW PROC '/cluster_balance/working_slots';
+----------+----------------------+------------+------------+-------------+----------------------+
| BeId | PathHash | AvailSlots | TotalSlots | BalanceSlot | AvgRate |
+----------+----------------------+------------+------------+-------------+----------------------+
| 10000 | 8110346074333016794 | 2 | 2 | 2 | 2.459007474009069E7 |
| 10000 | -5617618290584731137 | 2 | 2 | 2 | 2.4730105014001578E7 |
| 10001 | 4883406271918338267 | 2 | 2 | 2 | 1.6711402709780257E7 |
| 10001 | -5467083960906519443 | 2 | 2 | 2 | 2.7540126380326536E7 |
| 10002 | 9137404661108133814 | 2 | 2 | 2 | 2.417217089806745E7 |
| 10002 | 1885826196444191611 | 2 | 2 | 2 | 1.6327378456676323E7 |
+----------+----------------------+------------+------------+-------------+----------------------+
슬롯 사용 현황은 데이터 경로 단위로 표시됩니다. AvgRate는 해당 경로에서 수행된 clone 작업의 과거 통계에 기반한 복사 속도이며, 단위는 초당 바이트입니다.
우선 복구 조회
다음 명령은 ADMIN REPAIR TABLE 명령으로 우선 복구가 설정된 테이블 또는 파티션을 보여 줍니다.
SHOW PROC '/cluster_balance/priority_repair';
RemainingTimeMs는 이러한 우선 복구 항목이 우선 복구 큐에서 자동으로 제거되기까지 남은 시간을 나타냅니다. 이를 통해 우선 복구가 계속 실패하면서 리소스를 점유하는 것을 방지합니다.
스케줄러 통계 조회
Doris는 실행 중 TabletChecker와 TabletScheduler에 대한 통계를 수집합니다. 다음 명령으로 이 통계를 조회할 수 있습니다.
SHOW PROC '/cluster_balance/sched_stat';
+---------------------------------------------------+-------------+
| Item | Value |
+---------------------------------------------------+-------------+
| num of tablet check round | 12041 |
| cost of tablet check(ms) | 7162342 |
| num of tablet checked in tablet checker | 18793506362 |
| num of unhealthy tablet checked in tablet checker | 7043900 |
| num of tablet being added to tablet scheduler | 1153 |
| num of tablet schedule round | 49538 |
| cost of tablet schedule(ms) | 49822 |
| num of tablet being scheduled | 4356200 |
| num of tablet being scheduled succeeded | 320 |
| num of tablet being scheduled failed | 4355594 |
| num of tablet being scheduled discard | 286 |
| num of tablet priority upgraded | 0 |
| num of tablet priority downgraded | 1096 |
| num of clone task | 230 |
| num of clone task succeeded | 228 |
| num of clone task failed | 2 |
| num of clone task timeout | 2 |
| num of replica missing error | 4354857 |
| num of replica version missing error | 967 |
| num of replica relocating | 0 |
| num of replica redundant error | 90 |
| num of replica missing in cluster error | 0 |
| num of balance scheduled | 0 |
+---------------------------------------------------+-------------+
각 행의 의미는 다음과 같습니다.
| 지표 | 의미 |
|---|---|
| num of tablet check round | Tablet Checker가 실행된 횟수입니다. |
| cost of tablet check(ms) | Tablet Checker의 총 소요 시간입니다. |
| num of tablet checked in tablet checker | Tablet Checker가 확인한 Tablet 수입니다. |
| num of unhealthy tablet checked in tablet checker | Tablet Checker가 확인한 비정상 Tablet 수입니다. |
| num of tablet being added to tablet scheduler | Tablet Scheduler에 전달된 Tablet 수입니다. |
| num of tablet schedule round | Tablet Scheduler가 실행된 횟수입니다. |
| cost of tablet schedule(ms) | Tablet Scheduler의 총 소요 시간입니다. |
| num of tablet being scheduled | 스케줄링된 Tablet의 총수입니다. |
| num of tablet being scheduled succeeded | 성공적으로 스케줄링된 Tablet의 총수입니다. |
| num of tablet being scheduled failed | 스케줄링에 실패한 Tablet의 총수입니다. |
| num of tablet being scheduled discard | 스케줄링에 실패하여 폐기된 Tablet의 총수입니다. |
| num of tablet priority upgraded | 우선순위가 상향된 횟수입니다. |
| num of tablet priority downgraded | 우선순위가 하향된 횟수입니다. |
| num of clone task | 생성된 clone 작업 수입니다. |
| num of clone task succeeded | 성공한 clone 작업 수입니다. |
| num of clone task failed | 실패한 clone 작업 수입니다. |
| num of clone task timeout | 제한 시간을 초과한 clone 작업 수입니다. |
| num of replica missing error | 검사 중 복제본 누락 상태로 확인된 Tablet 수입니다. |
| num of replica version missing error | 검사 중 버전 누락 상태로 확인된 Tablet 수입니다(num of replica relocating 및 num of replica missing in cluster error 포함). |
| num of replica relocating | 검사 중 복제본 재배치 상태로 확인된 Tablet 수입니다. |
| num of replica redundant error | 검사 중 복제본 초과 상태로 확인된 Tablet 수입니다. |
| num of replica missing in cluster error | 검사 중 해당 클러스터에 속하지 않은 상태로 확인된 Tablet 수입니다. |
| num of balance scheduled | 균형 조정 스케줄링 횟수입니다. |
참고: 위의 모든 상태 값은 과거부터 누적된 값입니다. FE 로그에도 이러한 통계가 주기적으로 출력되며, 괄호 안의 값은 이전 통계 출력 이후 각 통계의 변화량을 나타냅니다.
관련 설정
조정 가능한 매개변수(FE)
다음 매개변수는 모두 fe.conf에서 설정할 수 있습니다.
| 매개변수 | 설명 | 기본값 | 중요도 |
|---|---|---|---|
| use_new_tablet_scheduler | 새로운 복제본 스케줄링 방식을 활성화할지 여부입니다. 새로운 복제본 스케줄링 방식은 이 문서에서 설명하는 방식입니다. | true | 높음 |
| tablet_repair_delay_factor_second | 일상적인 재시작, 업그레이드 등에서 불필요한 복제본 복구 작업이 대량으로 발생하지 않도록 스케줄링 우선순위별로 복구를 서로 다른 시간만큼 지연합니다. 기본 계수에 따라 HIGH는 base coefficient * 1, NORMAL은 base coefficient * 2, LOW는 base coefficient * 3만큼 지연합니다. 우선순위가 낮을수록 대기 시간이 깁니다. 복제본을 빠르게 복구해야 할 때는 이 값을 낮추세요. | 60초 | 높음 |
| schedule_slot_num_per_path | 복제본 복구를 위해 각 디스크에 할당하는 기본 슬롯 수로, 단일 디스크에서 동시에 실행할 수 있는 복제본 복구 작업 수를 나타냅니다. 값이 클수록 복구는 빨라지지만 IO에 미치는 영향도 커집니다. | 2 | 높음 |
| balance_load_score_threshold | 클러스터 균형 조정의 임계값입니다. BE 노드의 부하 점수와 평균 부하 점수 간 편차가 이 값을 초과하지 않으면 클러스터가 균형 상태인 것으로 간주합니다. 더 균등한 부하를 원하면 이 값을 낮추세요. | 0.1(즉, 10%) | 중간 |
| storage_high_watermark_usage_percent | 디스크의 최대 공간 사용률 제한입니다. 이 제한을 초과하면 해당 디스크를 더 이상 균형 조정 스케줄링의 대상으로 사용하지 않습니다. | 0.85 | 중간 |
| storage_min_left_capacity_bytes | 디스크에 남아 있어야 하는 최소 공간입니다. 남은 공간이 이 제한보다 작으면 해당 디스크를 더 이상 균형 조정 스케줄링의 대상으로 사용하지 않습니다. | 2097152000(2 GB) | 중간 |
| disable_balance | 균형 조정 기능을 비활성화할지 여부를 제어합니다. 균형 조정 중에는 일부 기능(예: ALTER TABLE)이 금지되며, 균형 조정이 오래 지속될 수 있습니다. 금지된 작업을 최대한 빨리 수행해야 할 때는 true로 설정하세요. | false | 중간 |
조정 가능한 매개변수(BE)
다음 매개변수는 모두 be.conf에서 설정할 수 있습니다.
| 매개변수 | 설명 | 기본값 | 중요도 |
|---|---|---|---|
| clone_worker_count | 복제본 균형 조정 속도에 영향을 줍니다. 디스크 부하가 낮을 때 이 매개변수를 조정하여 복제본 균형 조정 속도를 높일 수 있습니다. | 3 | 중간 |
조정할 수 없는 매개변수
다음 매개변수는 아직 변경할 수 없으며, 참고용으로만 나열합니다.
| 항목 | 설명 |
|---|---|
| TabletChecker 스케줄링 간격 | TabletChecker는 20초마다 검사와 스케줄링을 수행합니다. |
| TabletScheduler 스케줄링 간격 | TabletScheduler는 5초마다 스케줄링합니다. |
| TabletScheduler의 배치당 스케줄링 작업 수 | TabletScheduler는 라운드당 최대 50개의 Tablet을 스케줄링합니다. |
| TabletScheduler의 대기 중 및 실행 중 작업 최대 수 | 대기 중 및 실행 중 작업의 최대 수는 2000개입니다. 이를 초과하면 TabletChecker는 TabletScheduler를 위한 새 스케줄링 작업을 더 이상 생성하지 않습니다. |
| TabletScheduler의 균형 조정 작업 최대 수 | 균형 조정 작업의 최대 수는 500개입니다. 이를 초과하면 새 균형 조정 작업을 생성하지 않습니다. |
| 디스크당 균형 조정 작업 슬롯 수 | 디스크당 균형 조정 작업 슬롯 수는 2개입니다. 이 슬롯은 복제본 복구에 사용하는 슬롯과 독립적입니다. |
| 클러스터 균형 정보 갱신 간격 | TabletScheduler는 20초마다 클러스터 부하 점수를 다시 계산합니다. |
| clone 작업의 최소 및 최대 제한 시간 | clone 작업의 제한 시간은 3분에서 2시간 사이입니다. 구체적인 제한 시간은 (tablet size) / (5 MB/s)로 계산합니다. clone 작업은 실행이 3회 실패하면 종료됩니다. |
| 우선순위 동적 조정 전략 | 우선순위 조정의 최소 간격은 5분입니다. Tablet의 스케줄링이 5회 실패하면 우선순위를 낮추고, 30분 동안 스케줄링되지 않으면 우선순위를 높입니다. |
관련 문제
- 경우에 따라 기본 복제본 복구 및 균형 조정 전략이 네트워크 대역폭을 모두 사용할 수 있습니다(BE당 디스크 수가 많고 기가비트 네트워크 카드를 사용하는 환경에서 자주 발생). 이 경우 일부 매개변수를 조정하여 동시에 실행되는 균형 조정 및 복구 작업 수를 줄여야 합니다.
- 현재 Colocate 테이블의 복제본 균형 조정 전략은 동일한 Tablet의 복제본이 같은 호스트의 BE에 분산되지 않도록 보장하지 못합니다. 그러나 Colocate 테이블의 복제본 복구 전략은 이러한 잘못된 분포를 감지하여 수정합니다. 수정 후에는 균형 조정 전략이 복제본을 다시 불균형 상태로 판단하고 재조정할 수 있습니다. 그 결과 두 상태가 계속 번갈아 발생하여 Colocate Group이 안정화되지 못할 수 있습니다. 이러한 경우에는 Colocate 속성을 사용할 때 클러스터 구성을 가능한 한 균일하게 유지하여 복제본이 같은 호스트에 분산될 가능성을 줄이세요.
권장 운영 방법
클러스터 복제본 복구 및 균형 조정 진행 제어와 관리
대부분의 경우 Doris는 기본 매개변수 설정으로 복제본 복구와 클러스터 균형 조정을 자동으로 수행할 수 있습니다. 그러나 특정 테이블 또는 파티션의 우선 복구, 클러스터 부하를 줄이기 위한 클러스터 균형 조정 비활성화, Colocation이 아닌 테이블 데이터의 우선 복구 등 특정 목표를 달성하기 위해 매개변수를 수동으로 조정해야 할 때도 있습니다. 이 절에서는 매개변수를 변경하여 클러스터 복제본 복구 및 균형 조정의 진행을 제어하고 관리하는 방법을 설명합니다.
1. 손상된 복제본 삭제
경우에 따라 Doris가 특정 손상된 복제본을 자동으로 감지하지 못하여, 쿼리나 데이터 적재 시 해당 복제본에서 오류가 자주 보고될 수 있습니다. 이 경우 손상된 복제본을 수동으로 삭제해야 합니다. 이 방법은 버전 수가 너무 많아 -235 오류를 발생시키는 복제본이나 파일이 손상된 복제본 등을 삭제할 때 적용할 수 있습니다.
절차:
-
해당 복제본의 Tablet ID를 찾습니다. 여기서는 10001이라고 가정합니다.
-
show tablet 10001;을 실행한 다음, 반환된show proc문을 실행하여 Tablet의 각 복제본에 대한 세부 정보를 조회합니다. -
삭제할 복제본이 있는 Backend ID가 20001이라고 가정합니다. 다음 문을 실행하여 복제본을
bad로 표시합니다.ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "10001", "backend_id" = "20001", "status" = "bad"); -
show proc문을 다시 실행하여 해당 복제본의IsBad열이true인지 확인합니다.
bad로 표시된 복제본은 더 이상 데이터 적재와 쿼리에 참여하지 않습니다. 동시에 복제본 복구 로직이 새 복제본을 자동으로 보충합니다.
2. 테이블 또는 파티션 우선 복구
help admin repair table;을 실행하여 도움말을 확인하세요. 이 명령은 지정된 테이블 또는 파티션의 Tablet을 우선적으로 복구하도록 시도합니다.
3. 균형 조정 작업 중지
균형 조정 작업은 일정량의 네트워크 대역폭과 IO 리소스를 사용합니다. 새 균형 조정 작업의 생성을 중지하려면 다음 명령을 실행합니다.
ADMIN SET FRONTEND CONFIG ("disable_balance" = "true");
4. 모든 복제본 스케줄링 작업 중지
복제본 스케줄링 작업에는 균형 조정과 복구 작업이 포함됩니다. 이러한 작업은 일정량의 네트워크 대역폭과 IO 리소스를 사용합니다. 다음 명령은 모든 복제본 스케줄링 작업을 중지합니다(이미 실행 중인 작업은 제외하며, Colocation 테이블과 일반 테이블 모두 포함).
ADMIN SET FRONTEND CONFIG ("disable_tablet_scheduler" = "true");
5. Colocation 테이블의 모든 복제본 스케줄링 작업 중지
Colocation 테이블과 일반 테이블의 복제본 스케줄링은 독립적으로 실행됩니다. 경우에 따라 Colocation 테이블의 균형 조정 및 복구 작업을 먼저 중지하여 클러스터 리소스를 일반 테이블 복구에 사용하고 싶을 수 있습니다.
ADMIN SET FRONTEND CONFIG ("disable_colocate_balance" = "true");
6. 더 보수적인 전략으로 복제본 복구
Doris는 복제본 누락, BE 중단 등을 감지하면 복제본을 자동으로 복구합니다. 일시적인 문제(예: 짧은 BE 중단)로 인한 오류를 줄이기 위해 Doris는 이러한 작업의 시작을 지연합니다.
-
tablet_repair_delay_factor_second매개변수: 기본값은 60초입니다. 복구 작업의 우선순위에 따라 복구 작업은 60초, 120초 또는 180초의 지연 후 시작됩니다. 다음 명령은 이 시간을 늘려 더 긴 비정상 상태를 허용하고 불필요한 복구 작업이 시작되지 않도록 합니다.ADMIN SET FRONTEND CONFIG ("tablet_repair_delay_factor_second" = "120");
7. 더 보수적인 전략으로 Colocation Group 재분배 시작
Colocation Group을 재분배할 때는 대량의 Tablet 마이그레이션이 발생할 수 있습니다. colocate_group_relocate_delay_second는 재분배 시작까지의 지연 시간을 제어하며, 기본값은 1800초입니다. BE 노드가 장시간 오프라인 상태일 수 있다면 이 매개변수를 늘려 불필요한 재분배를 방지해 보세요.
ADMIN SET FRONTEND CONFIG ("colocate_group_relocate_delay_second" = "3600");
8. 복제본 균형 조정 속도 높이기
Doris의 복제본 균형 조정 로직은 먼저 정상 복제본을 추가한 다음 기존 복제본을 삭제하여 복제본을 마이그레이션합니다. 기존 복제본을 삭제할 때는 균형 조정 작업이 데이터 적재 작업에 영향을 주지 않도록 해당 복제본에서 이미 시작된 데이터 적재 작업이 완료될 때까지 기다립니다. 그러나 이 대기로 인해 균형 조정 로직의 실행 속도가 느려집니다. 다음 매개변수를 사용하면 Doris가 이 대기를 건너뛰고 기존 복제본을 바로 삭제합니다.
ADMIN SET FRONTEND CONFIG ("enable_force_drop_redundant_replica" = "true");
이 작업으로 인해 균형 조정 중 일부 데이터 적재 작업이 실패하여 재시도가 필요할 수 있지만, 균형 조정 속도는 크게 향상됩니다.
빠른 클러스터 복구를 위한 권장 절차
클러스터를 정상 상태로 빠르게 복구하려면 다음 방법을 고려하세요.
- 우선순위가 높은 작업에서 오류를 발생시키는 Tablet을 찾아 문제가 있는 복제본을
bad로 표시합니다. ADMIN REPAIR문을 사용하여 특정 테이블을 우선적으로 복구합니다.- 클러스터 리소스 소비를 줄이기 위해 복제본 균형 조정 로직을 중지하고, 클러스터가 복구된 후 다시 활성화합니다.
- 빈번한 BE 중단으로 인한 연쇄적인 영향을 처리할 수 있도록 더 보수적인 전략으로 복구 작업을 시작합니다.
- 필요에 따라 Colocation 테이블의 스케줄링 작업을 비활성화하여 클러스터 리소스를 우선순위가 높은 다른 데이터의 복구에 집중합니다.
자주 묻는 질문
Q: SHOW PROC '/cluster_health/tablet_health' 명령에서 오류가 발생하거나 데이터가 불완전하게 표시됩니다. 어떻게 해야 하나요?
이 명령은 Master FE에 직접 연결해야 합니다. 현재 연결된 FE가 Master인지 확인하세요.
Q: 복제본이 오랫동안 REPLICA_MISSING 상태이며 복구되지 않습니다. 어떻게 문제를 해결하나요?
ErrMsg를 확인하려면 SHOW PROC '/cluster_balance/pending_tablets'를 실행하세요. 일반적인 원인으로는 적절한 원본 또는 대상을 찾을 수 없는 경우, 디스크 공간 부족, 노드의 서비스 해제 진행 등이 있습니다.
Q: 복구 작업의 스케줄링 실패가 너무 많습니다. 어떻게 해야 하나요?
SHOW PROC '/cluster_balance/sched_stat'로 실패 통계를 조회하세요. schedule_slot_num_per_hdd_path 또는 schedule_slot_num_per_ssd_path를 늘리는 것을 고려하거나, 디스크 공간 부족이나 사용 불가능한 노드 등의 문제가 있는지 확인하세요.
Q: 복제본 균형 조정이 네트워크 대역폭을 모두 사용하고 있습니다. 어떻게 해야 하나요?
동시에 실행되는 균형 조정 및 복구 작업 수를 줄이거나, 임시로 ADMIN SET FRONTEND CONFIG ("disable_balance" = "true");를 실행하세요.
Q: Colocate Group이 오랫동안 안정화되지 않습니다. 어떻게 해야 하나요?
클러스터 구성을 가능한 한 균일하게 유지하고 colocate_group_relocate_delay_second를 늘려 불필요한 재분배를 줄이세요.
Q: BE가 중단된 직후 대량의 복제본 복구가 시작되어 부하가 급격히 변동합니다. 어떻게 해야 하나요?
tablet_repair_delay_factor_second를 늘려 더 긴 유예 시간을 허용하세요.
Q: bad 복제본을 삭제한 후에도 오류가 계속 발생합니다. 어떻게 해야 하나요?
SHOW PROC '/dbs/.../<tablet_id>'로 모든 복제본이 다시 보충되었는지 확인하고, clone 작업이 완료될 때까지 기다리세요.