http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> starrocks 4.1.1 버젼이고 FE + CN 구조로 K...
# questions-and-troubleshooting
u
@Rocky starrocks 4.1.1 버젼이고 FE + CN 구조로 K8s 환경에 구성되었으며 External Catalog(S3)를 활용하고 있습니다 FE 시작 중 아래와 같은 유형의 다른 tablets 버젼의 에러가 반복 되면서 fe 가 startupprobe, readiness probe, libeness probe failed 가 발생하고 있고, 대한 대응 방법을 알고 싶습니다 com.starrocks.rpc.RpcException: Fail to publish version for tablets: [[34532, 34531, 34530]], error msg : Both txn_log and corresponding tablet_meta missing, host : cn…svc
r
StarRocks 4.1.1 버전(Shared-data 모드)에서 발생하는 
Both txn_log and corresponding tablet_meta missing
에러는 *Autovacuum과 트랜잭션 커밋 간의 레이스 컨디션(Race Condition)*으로 인해 발생하는 알려진 버그(#74906)일 가능성이 매우 높습니다. 이 현상은 트랜잭션 로그(
txn_log
)가 아직 필요한 상태에서 Autovacuum에 의해 조기에 삭제되어, FE가 특정 버전을 Publish 하려 할 때 CN 노드가 해당 메타데이터를 찾지 못해 발생합니다. 이로 인해 해당 파티션의 Publish 과정이 영구적으로 고착(Wedged)되며, FE가 이 작업을 반복 시도하면서 Probe(Startup/Readiness) 실패로 이어질 수 있습니다. 권장 대응 방법 1. 버전 업그레이드 (근본 해결) 해당 이슈는 StarRocks 4.1.2 버전 이상 또는 4.0.13 이상 버전에서 수정되었습니다. 현재 사용 중인 4.1.1 버전에는 이 레이스 컨디션 방지 로직이 포함되어 있지 않으므로, 최신 패치 버전으로 업그레이드하는 것이 가장 확실한 방법입니다. 2. `ADMIN REPAIR TABLE`을 통한 수동 복구 StarRocks 4.1부터 Shared-data 테이블에 대해 
ADMIN REPAIR TABLE
명령어를 지원합니다. FE에 SQL 접속이 가능하다면(Probe 타임아웃을 늘리거나 일시적으로 비활성화하여 진입), 다음 명령어로 고착된 파티션을 강제 복구할 수 있습니다. * 일관성 무시 강제 복구 (권장): 가장 최근의 유효한 버전을 찾아 파티션을 복구합니다. (일부 데이터 유실 가능성 있음)
Copy code
sql
    ADMIN REPAIR TABLE <table_name> PARTITION (<partition_name>)
    PROPERTIES (
        'enforce_consistent_version' = 'false'
    );
* 빈 태블릿으로 복구 (최후의 수단): 메타데이터가 완전히 유실된 경우 해당 태블릿을 비어있는 상태로 복구합니다.
Copy code
sql
    ADMIN REPAIR TABLE <table_name> PARTITION (<partition_name>)
    PROPERTIES (
        'enforce_consistent_version' = 'false',
        'allow_empty_tablet_recovery' = 'true'
    );
_참고: `<table_name>`과 파티션 정보는 에러 로그에 출력된 Tablet ID(34532 등)를 기반으로 
SHOW TABLET 34532
등을 실행하여 확인할 수 있습니다._ 3. FE 시작 지연 대응 (K8s 설정) FE가 Publish 루프에 빠져 Startup/Readiness Probe에 실패하고 있다면, K8s 리소스의 `initialDelaySeconds`나 `failureThreshold`를 일시적으로 크게 늘려 FE가 "Running" 상태를 유지하게 한 뒤 위 복구 명령어를 실행하십시오. 4. 임시 예방 설정 (
fe.conf
) 업그레이드가 어려운 상황이라면, `fe.conf`에서 다음 설정을 조정하여 레이스 컨디션 발생 확률을 낮출 수 있습니다. * `lake_autovacuum_grace_period_minutes`: 이 값을 기본값보다 늘려(예: 60분 이상) 파일이 조기에 삭제되지 않도록 보호 기간을 확보합니다. 요약 1. 현상: 4.1.1 버전의 Autovacuum 버그로 인한 Publish 고착 상태. 2. 해결: 4.1.2 버전으로 업그레이드하십시오. 3. 조치: 업그레이드 전까지는 K8s Probe 시간을 늘린 후 
ADMIN REPAIR TABLE
명령어로 문제가 된 파티션을 복구하십시오. References • faq/shared_data_faq.md • administration/Meta_recovery.md • knowledge/admin_and_operation/shared_data_compaction.md • administration/management/resource_management/Replica.md
u
@Rocky 복구해야할 table 이 어떤 테이블인지 확인하려면?
r
에러 메시지에 포함된 *Tablet ID*(예: 34532)를 사용하여 어떤 테이블과 파티션에 문제가 있는지 확인하는 방법은 다음과 같습니다. 1. SQL 명령어를 통한 확인 (가장 권장) FE에 MySQL 클라이언트로 접속 가능한 상태라면, 아래 명령어를 통해 해당 태블릿의 상세 정보를 바로 조회할 수 있습니다.
Copy code
sql
SHOW TABLET 34532;
출력 결과 예시: 출력되는 결과에서 
DbName
, 
TableName
, 
PartitionName
항목을 확인하십시오. * DbName: 데이터베이스 이름 * TableName: 테이블 이름 * PartitionName: 문제가 발생한 파티션 이름 (이 이름은 
ADMIN REPAIR TABLE
명령 시 필요합니다.) 2. Information Schema 조회를 통한 확인 많은 수의 태블릿 ID를 한꺼번에 확인해야 할 경우 유용합니다.
Copy code
sql
SELECT * FROM information_schema.be_tablets WHERE tablet_id IN (34532, 34531, 34530);
3. FE HTTP API를 통한 확인 (SQL 접속이 어려운 경우) FE가 계속 재시작되어 MySQL 접속이 불안정하다면, FE의 HTTP API 포트(기본 8030)를 통해 정보를 얻을 수 있습니다.
Copy code
bash
curl -u <user>:<password> http://<FE_IP>:<FE_HTTP_PORT>/api/show_tablet?tablet_id=34532
결과는 JSON 형태로 반환되며 테이블 ID와 데이터베이스 정보를 포함합니다. ────────── 만약 FE가 계속 죽어서 확인이 어렵다면? FE가 
StartupProbe
실패로 계속 재시작되어 명령어를 칠 시간이 부족하다면, K8s Manifest에서 임시로 Probe 설정을 완화해야 합니다. 1. K8s 설정 변경: `initialDelaySeconds`를 300(5분) 이상으로 늘리거나 `failureThreshold`를 크게 높여 FE가 재시작되지 않고 유지되도록 합니다. 2. 접속 및 확인: FE가 Running 상태를 유지하는 동안 위 1번(
SHOW TABLET
) 명령으로 테이블명을 확인합니다. 3. 조치: 확인된 테이블과 파티션에 대해 앞서 안내해 드린 
ADMIN REPAIR TABLE
명령을 실행합니다. 요약 가이드 1. 
SHOW TABLET 34532;
실행 2. 결과에서 `TableName`과 
PartitionName
확인 3. 
ADMIN REPAIR TABLE <테이블명> PARTITION (<파티션명>) PROPERTIES("enforce_consistent_version" = "false");
실행하여");` 실행하여 고착` 실행` References • sql-reference/sql-statements/table_bucket_part_index/SHOW_TABLET.md
u
@Rocky
r
Hello, @양명구! How can I assist you today?
u
@Rocky show tablet 10019; 를 실행하니 DBName : statistics TableName : table_statistic_v1
r
확인하신 
_statistics_.table_statistic_v1
테이블은 StarRocks의 *CBO(Cost-Based Optimizer)가 쿼리 계획을 세우기 위해 사용하는 내부 통계 정보 저장 테이블*입니다. 이 테이블에서 발생한 Publish 에러가 FE의 기동 및 Health Check 실패의 원인이 되고 있습니다. 내부 시스템 테이블이지만 복구 방법은 일반 테이블과 동일하며, 데이터의 중요도 측면에서 비즈니스 데이터보다 복구 부담이 적습니다(통계 정보는 다시 수집하면 되기 때문입니다). 다음 단계에 따라 복구를 진행하십시오. 1. 파티션 명 확인 먼저 해당 테이블의 파티션 이름을 확인해야 합니다. 보통 시스템 테이블은 테이블명과 동일하거나 특정 규칙을 따릅니다.
Copy code
sql
SHOW PARTITIONS FROM _statistics_.table_statistic_v1;
_결과에서 
PartitionName
컬럼의 값을 확인하십시오. (예: 
table_statistic_v1
또는 
p0
등)_ 2. 시스템 테이블 복구 실행 확인된 파티션 명을 사용하여 아래 명령어를 실행합니다. (파티션 명이 `table_statistic_v1`이라고 가정할 경우)
Copy code
sql
ADMIN REPAIR TABLE _statistics_.table_statistic_v1 
PARTITION (table_statistic_v1)
PROPERTIES (
    "enforce_consistent_version" = "false"
);
만약 위 명령어로도 해결되지 않거나 메타데이터가 완전히 깨졌다면, 더 강력한 복구 옵션을 사용합니다.
Copy code
sql
ADMIN REPAIR TABLE _statistics_.table_statistic_v1 
PARTITION (table_statistic_v1)
PROPERTIES (
    "enforce_consistent_version" = "false",
    "allow_empty_tablet_recovery" = "true"
);
_주의: `allow_empty_tablet_recovery`를 사용하면 해당 태블릿의 통계 데이터가 초기화될 수 있으나, 시스템은 정상화됩니다._ 3. 통계 데이터 재수집 (선택 사항) 복구 후 시스템이 안정화되면, 유실되었을지 모르는 통계 정보를 최신화하기 위해 아래 명령으로 통계 수집을 다시 유도할 수 있습니다. (필요 시)
Copy code
sql
ANALYZE TABLE <작업_대상_비즈니스_테이블>;
왜 이 문제가 발생했나요? 
_statistics_
테이블은 백그라운드에서 지속적으로 업데이트(Insert/Update)가 발생합니다. StarRocks 4.1.1 버전의 Shared-data 모드에서는 이처럼 쓰기 작업이 빈번한 테이블에서 Autovacuum이 필요한 로그를 너무 빨리 지워버리는 버그가 발생하기 쉽습니다. 결론적으로: 1. 위 
ADMIN REPAIR
명령으로 현재 교착 상태를 해제하십시오. 2. 이후 동일 현상 재발을 방지하기 위해 *StarRocks 4.1.2 이상 버전으로의 업그레이드*를 강력히 권고드립니다. References • sql-reference/sql-statements/table_bucket_part_index/SHOW_TABLET.md • administration/Meta_recovery.md • administration/management/resource_management/Replica.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/data-definition/ANALYZE_TABLE.md
u
@Rocky 임시 조치로 아래 설정을 조정했습니다 ㅇ `lake_autovacuum_grace_period_minutes`: 이 값은 기본값 30이었고 60으로 조정해서 상태를 확인중입니다. 다만, 이 값의 적정한 범위는 어느정도까지 가능합니까?
r
lake_autovacuum_grace_period_minutes
설정은 Shared-data 구조에서 Compaction 완료 후, *이전 버전의 데이터와 메타데이터(txn_log 등)를 즉시 지우지 않고 보관하는 "유예 기간"*을 의미합니다. 질문하신 적정 범위와 설정 시 고려사항은 다음과 같습니다. 1. 권장 범위 및 최대값 공식 문서상에 엄격한 최대 임계값은 정해져 있지 않으나, 운영 환경에 따른 권장 범위는 다음과 같습니다. * 최소값: 해당 클러스터에서 실행되는 *가장 긴 쿼리의 수행 시간*보다 커야 합니다. (기본값 30분은 대부분의 쿼리를 커버합니다.) * 현재 이슈 대응을 위한 설정: 4.1.1 버전의 버그(레이스 컨디션)를 회피하기 위해 일시적으로 60 ~ 120(1~2시간) 정도로 늘리는 것이 일반적입니다. * 상한선: 이론적으로 수천 분 이상 설정도 가능하지만, 굳이 1440(24시간)을 넘기는 것은 권장하지 않습니다. 2. 설정 값 조정 시 발생하는 트레이드오프 이 값을 늘리면 안정성은 높아지지만, 다음과 같은 부작용이 있을 수 있습니다. * 스토리지 비용 증가 (S3 등): 유예 기간 동안 삭제되어야 할 오래된 데이터 파일들이 S3에 계속 남아 있게 되므로 스토리지 사용량이 증가합니다. 쓰기 작업이 빈번한 클러스터일수록 누적되는 파일 양이 많아집니다. * 가비지 데이터 처리 지연: 너무 길게 설정할 경우, 나중에 한꺼번에 많은 양의 Vacuum 작업이 몰리면서 시스템 리소스를 일시적으로 점유할 수 있습니다. 3. 현재 상황에서의 판단 현재 겪고 계신 
txn_log missing
에러는 트랜잭션이 완료(Publish)되기 전에 Autovacuum이 해당 로그를 삭제해버려서 발생합니다. * 60분 설정: 기본값(30분)보다 개선된 상태이지만, 시스템 부하가 높거나 트랜잭션 처리가 지연될 경우 60분으로도 부족할 수 있습니다. * 추천: 만약 60분 설정 후에도 동일 에러가 재발한다면 *120*으로 더 늘려보십시오. 요약 임시 조치로서 60~120분 설정은 매우 적절한 대응입니다. 다만, 이는 근본적인 코드 레벨의 레이스 컨디션을 해결하는 것이 아니라 발생 확률을 낮추는 "시간 벌기"용 조치임을 유의해 주십시오. 가장 안정적인 방법은 4.1.2 버전으로 업데이트하여 Autovacuum 로직 자체가 수정된 버전을 사용하는 것입니다. References • administration/management/FE_configuration.md • faq/shared_data_faq.md • administration/management/resource_management/Replica.md • administration/Meta_recovery.md References • administration/management/FE_configuration.md • faq/shared_data_faq.md
u
@Rocky Fail to publish partition 34529 or txnIds [28158, 28162…라는 메시를 이용해 해당 transaction Id 28158 의 show transaction 명령을 활용하는 방법을 단계별로 알려주세요
r
Fail to publish
에러 메시지에 포함된 트랜잭션 ID(
28158
)를 이용해 현재 해당 작업의 상태와 상세 원인을 파악하는 방법은 다음과 같습니다. 1단계: 대상 데이터베이스 접속 트랜잭션 정보는 데이터베이스별로 관리되므로, 앞서 확인한 
_statistics_
데이터베이스를 지정하여 명령어를 실행하는 것이 정확합니다.
Copy code
sql
USE _statistics_;
2단계: 상세 트랜잭션 정보 조회 아래 명령어를 실행하여 해당 트랜잭션의 현재 상태와 에러 이유를 확인합니다.
Copy code
sql
SHOW TRANSACTION WHERE ID = 28158;
또는 데이터베이스를 이동하지 않고 한 번에 실행하려면:
Copy code
sql
SHOW TRANSACTION FROM _statistics_ WHERE ID = 28158;
3단계: 결과 해석 (주요 확인 항목) 출력 결과에서 다음 항목들을 중점적으로 확인하십시오. * TransactionStatus: * `COMMITTED`: 데이터 쓰기는 성공했으나 사용자가 볼 수 있는 상태(
VISIBLE
)로 넘어가지 못한 상태입니다. (현재 겪고 계신 'Publish' 단계의 병목/오류를 의미합니다.) * `ABORTED`: 트랜잭션이 실패하여 취소된 상태입니다. * `VISIBLE`: 정상적으로 완료된 상태입니다. * Reason: 트랜잭션이 실패했거나 
VISIBLE
상태로 가지 못하고 있다면 여기에 상세 에러 메시지가 표시됩니다. (예: 
tablet 10019 has no scanable replica
, 
txn_log not found
등) * Label: 이 트랜잭션을 생성한 작업의 이름입니다. 
_statistics_
테이블의 경우 보통 `analyze_`로 시작하는 통계 수집 작업인 경우가 많습니다. ────────── 추가 팁: 전체 트랜잭션 현황 파악하기 (SHOW PROC) 특정 ID 외에 시스템 전체에서 어떤 트랜잭션들이 밀려 있는지 확인하고 싶을 때 유용한 방법입니다. 1. 데이터베이스 ID 확인:
Copy code
sql
    SHOW PROC '/transactions';
_여기서 
_statistics_
데이터베이스의 `DbId`(예: 10005)를 확인합니다._ 2. 해당 DB의 트랜잭션 통계 확인:
Copy code
sql
    -- DbId가 10005라고 가정할 때
    SHOW PROC '/transactions/10005';
현재 
running
, 
finished
상태의 트랜잭션 개수를 보여줍니다. 현재 상황에서의 의미 만약 `TransactionStatus`가 COMMITTED 상태에서 멈춰 있고 *Reason*에 
txn_log
관련 메시지가 있다면, 이는 앞서 논의한 *Autovacuum 버그*로 인해 데이터 실제 반영(Publish)에 필요한 로그가 삭제된 상황임을 최종 확정할 수 있습니다. 이 경우 이전에 안내해 드린 
ADMIN REPAIR TABLE
명령을 통해 강제로 상태를 정리해야 합니다. References • sql-reference/sql-statements/loading_unloading/SHOW_TRANSACTION.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md References • sql-reference/sql-statements/loading_unloading/SHOW_TRANSACTION.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • sql-reference/sql-statements/backup_restore/SHOW_RESTORE.md • sql-reference/sql-statements/loading_unloading/SHOW_LOAD.md • loading/SQL_transaction.md
u
@Rocky Fail to publish partision 34529 error fail to publish version for tablets : [[34352, 34350, 34531… show tablet 34532; 로 조회를 해보니 dbname : ‘-statistics_’ tablename : loads_history 로 나오는데 refair 처리 해야되나요?
r
네, 
_statistics_.loads_history
테이블도 동일하게 Repair 처리가 필요합니다. 
loads_history
테이블은 StarRocks에서 발생한 모든 데이터 로드(Insert, Stream Load 등)의 이력을 기록하는 시스템 내부 테이블입니다. 이 테이블에 
Fail to publish
에러가 발생했다는 것은, 로드 이력을 기록하려는 내부 트랜잭션이 앞서 발생한 `table_statistic_v1`과 동일한 원인(Autovacuum으로 인한 로그 유실 등)으로 꼬여있음을 의미합니다. 이 테이블은 비즈니스 데이터가 아닌 *단순 이력 데이터*이므로, 복구 과정에서 일부 이력이 유실되더라도 서비스 운영에는 지장이 없습니다. 아래 단계에 따라 조치해 주세요. 1. 파티션 확인 `loads_history`는 날짜별로 파티션이 나뉘어 있을 가능성이 높습니다. 먼저 문제가 되는 파티션 이름을 확인합니다.
Copy code
sql
SHOW PARTITIONS FROM _statistics_.loads_history;
결과에서 `LastCommitTime`이 과거에 멈춰있거나 에러 메시지의 파티션 ID(
34529
)에 해당하는 `PartitionName`을 찾으십시오. 2. Repair 실행 확인된 파티션에 대해 아래 명령을 실행합니다. (파티션 명이 
p20231027
같은 형태라면 해당 이름을 넣으시면 됩니다. 전체를 다 하셔도 무방합니다.)
Copy code
sql
ADMIN REPAIR TABLE _statistics_.loads_history 
PARTITION (확인된_파티션명)
PROPERTIES (
    "enforce_consistent_version" = "false",
    "allow_empty_tablet_recovery" = "true"
);
3. 왜 모든 시스템 테이블에서 에러가 나나요? 현재 StarRocks 4.1.1 Shared-data 모드에서 *"백그라운드 쓰기 작업이 빈번한 모든 시스템 테이블"*이 이 버그의 타겟이 되고 있습니다. * `table_statistic_v1`: 통계 수집 시 수시로 Insert 발생 * `loads_history`: 모든 로드 작업 시 수시로 Insert 발생 이 테이블들에 쓰기가 발생할 때 Autovacuum이 너무 빨리 돌면 `txn_log`가 사라져 
Fail to publish
상태에 빠지게 됩니다. 결론 1. 조치: `_statistics_.loads_history`와 
_statistics_.table_statistic_v1
모두 위 명령어로 Repair 하십시오. 2. 임시 방편: 이미 설정하신 
lake_autovacuum_grace_period_minutes = 60
(혹은 120) 설정을 유지하여 재발 빈도를 낮추십시오. 3. 근본 해결: 가급적 빠른 시일 내에 *4.1.2 버전 이상으로 업그레이드*를 권장합니다. 4.1.2 버전에서는 이 Publish 관련 레이스 컨디션 버그가 수정되었습니다. References • loading/loading_introduction/troubleshooting_loading.md • sql-reference/sql-statements/table_bucket_part_index/SHOW_TABLET.md • administration/Meta_recovery.md • administration/management/FE_configuration.md • sql-reference/information_schema/loads.md References • loading/loading_introduction/troubleshooting_loading.md • administration/management/FE_configuration.md • sql-reference/information_schema/loads.md
u
@Rocky v4.1.1 에서 현재까지 알려준 auto_vacuum에 대한 재현 test 방법과 재현 후 조치할 수 있는 방법을 알려주세요 예, statistics 의 _loads_history_ 에 재현 이슈 및 해결을 위한 truncate…등
r
v4.1.1(Shared-data 모드)에서 발생하는 Autovacuum과 Publish 간의 레이스 컨디션 이슈를 재현하고, 이를 해결하는 방법을 정리해 드립니다. ────────── 1. 이슈 재현 방법 (Test Scenario) 이 이슈는 *"데이터 쓰기 완료(Commit) 후 실제 반영(Publish)되기 전에, Autovacuum이 필요한 로그(txn_log)를 삭제"*할 때 발생합니다. 이를 인위적으로 유도하려면 유예 기간을 극단적으로 줄이고 부하를 주어야 합니다. 1단계: 환경 설정 (FE) Autovacuum 유예 기간을 최소화하여 로그가 즉시 삭제되도록 설정합니다.
Copy code
sql
-- FE 설정을 임시로 1분으로 변경 (재현용)
ADMIN SET FRONTEND CONFIG ("lake_autovacuum_grace_period_minutes" = "1");
2단계: 시스템 테이블 부하 발생 `_statistics_.loads_history`는 모든 로드 작업 시 기록되므로, 아주 작은 데이터를 반복적으로 로드하여 트랜잭션을 대량으로 생성합니다. * 방법: 루프 문을 사용하여 `INSERT INTO`를 반복 실행하거나, 짧은 간격으로 Stream Load를 발생시킵니다. * 동시에 
ANALYZE TABLE ...
명령을 실행하여 
table_statistic_v1
테이블에도 쓰기 부하를 줍니다. 3단계: 로그 확인 FE의 `fe.warn.log`에서 아래와 같은 패턴이 나타나는지 모니터링합니다. * 
Fail to publish partition ...
* 
get lake txn log failed
혹은 
txn_log not found
────────── 2. 재현 후 조치 방법 (Resolution) 이슈가 재현되어 
Fail to publish
상태에 빠진 경우, 아래 두 가지 방법으로 해결할 수 있습니다. 방법 A: TRUNCATE를 이용한 초기화 (시스템 테이블 전용) 비즈니스 데이터가 아닌 
_statistics_
내 테이블들은 `TRUNCATE`를 통해 모든 메타데이터와 데이터를 깔끔하게 밀어버리는 것이 가장 빠르고 확실한 방법입니다.
Copy code
sql
-- 1. 통계 테이블 초기화
TRUNCATE TABLE _statistics_.table_statistic_v1;

-- 2. 로드 이력 테이블 초기화
TRUNCATE TABLE _statistics_.loads_history;
* 효과: 문제가 된 트랜잭션 로그와 관련된 메타데이터 정보가 모두 삭제되므로, 즉시 새로운 트랜잭션을 정상적으로 처리할 수 있게 됩니다. * 주의: `loads_history`의 과거 이력이 사라지지만, 시스템 운영에는 영향이 없습니다. 방법 B: ADMIN REPAIR를 이용한 강제 복구 (데이터 유지) 데이터를 지우지 않고 복구해야 한다면 이전 단계에서 안내드린 Repair 명령을 사용합니다.
Copy code
sql
ADMIN REPAIR TABLE _statistics_.loads_history 
PROPERTIES (
    "enforce_consistent_version" = "false",
    "allow_empty_tablet_recovery" = "true"
);
────────── 3. 최종 권고 사항 * 테스트 종료 후 복구: 재현 테스트가 끝나면 `lake_autovacuum_grace_period_minutes`를 다시 *60 이상*으로 반드시 복구해야 합니다. * 근본 해결: 이 이슈는 v4.1.2에서 `txn_log`의 라이프사이클 관리 로직이 수정되어 해결되었습니다. 재현 테스트를 통해 문제가 확인되었다면, 운영 환경은 *v4.1.2 이상으로 업그레이드*하는 것이 가장 안전합니다. References • administration/management/FE_configuration.md • sql-reference/sql-statements/table_bucket_part_index/TRUNCATE_TABLE.md • administration/Meta_recovery.md • sql-reference/sql-statements/cluster-management/nodes_processes/ADMIN_REPAIR_TABLE.md
u
@Rocky refair 명령을 수행하였으나, 해결되지 않았고, 그 이후 조치 방법은?
r
ADMIN REPAIR TABLE
명령으로도 해결되지 않는다면, 이는 메타데이터와 실제 저장소(Object Storage) 간의 버전 불일치가 
REPAIR
명령만으로는 해소되지 않을 만큼 깊게 꼬여있는 상태입니다. 특히 
_statistics_
데이터베이스의 시스템 테이블에서 발생한 경우, 다음과 같은 *강제 초기화 방법*을 순차적으로 시도해야 합니다. ────────── 1. 단계: TRUNCATE 실행 (가장 추천) `ADMIN REPAIR`는 기존 데이터를 살리려 노력하지만, `TRUNCATE`는 해당 테이블의 모든 메타데이터와 파일 링크를 삭제하고 0번 버전부터 새로 시작합니다. 시스템 테이블이므로 데이터 유실 걱정 없이 실행하셔도 됩니다.
Copy code
sql
-- 두 테이블 모두 실행
TRUNCATE TABLE _statistics_.loads_history;
TRUNCATE TABLE _statistics_.table_statistic_v1;
확인 사항: 
TRUNCATE
후 다시 데이터를 넣거나 통계 수집(
ANALYZE
)을 했을 때 `Fail to publish`가 다시 발생하는지 확인하십시오. ────────── 2. 단계: 테이블 DROP 및 재생성 (TRUNCATE 실패 시) 만약 
TRUNCATE
작업조차 트랜잭션 충돌로 인해 실패한다면, 테이블을 완전히 삭제했다가 다시 만들어야 합니다. StarRocks의 시스템 테이블은 삭제되어도 다시 생성할 수 있습니다.
Copy code
sql
-- 1. 테이블 삭제
DROP TABLE _statistics_.loads_history;

-- 2. 테이블 재생성 (StarRocks가 자동으로 관리하는 테이블이므로 다시 생성 구문이 필요할 수 있습니다)
-- 보통은 수동으로 생성하기보다 StarRocks 내부 로직에 의해 생성되지만, 
-- 바로 해결이 안 될 경우 FE를 재시작하면 시스템 테이블이 없을 시 자동으로 복구/생성됩니다.
────────── 3. 단계: FE(Frontend) 재시작 메타데이터의 'Publish' 큐(Queue)가 메모리 상에서 꼬여있는 경우, 명령어만으로는 풀리지 않을 수 있습니다. 1. FE 리더(Leader) 노드 재시작: FE를 재시작하면 진행 중이던 `LakePublishThread`가 초기화되면서 꼬여있던 트랜잭션 정보가 정리될 수 있습니다. 2. 재시작 전 확인: 반드시 
lake_autovacuum_grace_period_minutes
설정을 *60(1시간) 이상*으로 고정한 뒤 재시작하십시오. ────────── 4. 단계: 강제 트랜잭션 정리 (고급) `SHOW TRANSACTION WHERE ID = [ID]`를 실행했을 때 상태가 여전히 `COMMITTED`에 머물러 있다면, 시스템적으로 해당 트랜잭션을 포기하게 만들어야 합니다. 하지만 Shared-data 모드에서는 사용자가 직접 
ABORT
하기가 어려운 경우가 많습니다. 이때는 *버전 업그레이드(v4.1.2 이상)*를 진행하는 것이 사실상 유일한 해결책일 수 있습니다. v4.1.2에는 다음과 같은 패치가 포함되어 있습니다. * `lake_autovacuum`이 `txn_log`를 삭제하기 전, 해당 로그가 실제 Publish 되었는지 한 번 더 확인하는 로직 추가. * 이미 로그가 삭제된 경우 해당 버전을 건너뛰거나 에러를 복구하는 안정성 강화. ────────── 요약 가이드 1. 지금 즉시 *`TRUNCATE TABLE statistics.loads_history;`*를 실행하십시오. 2. 그 후에도 에러가 반복된다면 *FE 노드들을 순차적으로 재시작*하십시오. 3. 이후에도 동일 현상이 발생한다면, 운영 환경의 안정성을 위해 *v4.1.2 또는 최신 버전(v4.1.x 계열의 최신)*으로 업그레이드할 것을 강력히 권고드립니다. (이 이슈는 v4.1.1의 알려진 치명적 결함 중 하나입니다.) References • sql-reference/sql-statements/table_bucket_part_index/TRUNCATE_TABLE.md • administration/management/FE_configuration.md • sql-reference/sql-statements/table_bucket_part_index/DROP_TABLE.md • administration/Meta_recovery.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md References • sql-reference/sql-statements/table_bucket_part_index/TRUNCATE_TABLE.md • sql-reference/sql-statements/table_bucket_part_index/DROP_TABLE.md • administration/management/FE_configuration.md • administration/Meta_recovery.md • loading/SQL_transaction.md • loading/loading_introduction/troubleshooting_loading.md -loading) -failure) • quick_start/shared_data.md
u
@Rocky 특정 transactionid 를 삭제하려면?
r
특정 Transaction ID(TXN_ID)를 직접 '삭제'하거나 '중지'하는 명령은 트랜잭션의 종류와 상태에 따라 다릅니다. StarRocks에서 트랜잭션을 제어하는 방법은 다음과 같습니다. 1. 로드 작업(Load Job)인 경우 대부분의 데이터 로드 트랜잭션은 *Label(라벨)*을 기준으로 취소합니다. 우선 해당 ID의 라벨을 확인해야 합니다. * 라벨 확인:
Copy code
sql
    SHOW TRANSACTION WHERE ID = 34529; -- 예시 ID
결과에서 
Label
컬럼의 값을 확인합니다. * 취소 명령:
Copy code
sql
    CANCEL LOAD WHERE LABEL = "확인된_라벨명";
2. 컴팩션(Compaction) 트랜잭션인 경우 (Shared-data) Shared-data 모드에서 백그라운드로 도는 컴팩션 작업은 TXN_ID로 직접 취소할 수 있습니다.
Copy code
sql
CANCEL COMPACTION WHERE TXN_ID = 34529;
주의: 이 명령은 FE 리더(Leader) 노드에서 실행해야 하며, 아직 
COMMITTED
상태가 되기 전의 작업만 취소 가능합니다. 3. SQL 트랜잭션 (BEGIN ... COMMIT)인 경우 현재 세션에서 진행 중인 SQL 트랜잭션이라면 
ROLLBACK
명령을 사용합니다.
Copy code
sql
ROLLBACK;
이미 세션이 끊겼다면 StarRocks가 일정 시간 후 자동으로 롤백 처리합니다. 4. 'Fail to Publish' 상태의 스택된 트랜잭션 질문하신 
Fail to publish
에러와 관련된 트랜잭션은 이미 
COMMITTED
 상태일 가능성이 높습니다. * 상태 확인: `SHOW TRANSACTION WHERE ID = ...`에서 `TransactionStatus`가 `COMMITTED`라면, 데이터는 이미 스토리지에 써졌지만 '가시화(Publish)' 단계에서 멈춘 것입니다. * 삭제 가능 여부: StarRocks에서 이미 `COMMITTED`된 트랜잭션 기록을 강제로 삭제하는 SQL 명령은 없습니다. 이 기록은 FE의 메모리와 메타데이터에 남아 있으며, 유효 기간이 지나면 자동으로 정리됩니다. * 조치 방법: 앞서 안내드린 대로 *`TRUNCATE TABLE`*을 실행하면, 해당 테이블과 관련된 모든 미결 트랜잭션 상태를 무시하고 메타데이터를 새로 시작하므로 실질적인 '정리' 효과를 볼 수 있습니다. 요약 대상 | 방법 일반 로드 | `SHOW TRANSACTION`으로 라벨 확인 후 
CANCEL LOAD
컴팩션 | 
CANCEL COMPACTION WHERE TXN_ID = ...
시스템 테이블 | 
TRUNCATE TABLE _statistics_.loads_history
(기록 삭제 및 초기화) 만약 특정 TXN_ID가 계속해서 FE 로그에 에러를 뿌리며 시스템에 부하를 주고 있다면, *FE 노드 재시작*을 통해 메모리상의 Publish 큐를 강제로 비워주는 것이 가장 확실한 방법입니다. References • sql-reference/sql-statements/loading_unloading/CANCEL_LOAD.md • administration/management/compaction.md • sql-reference/sql-statements/loading_unloading/SHOW_TRANSACTION.md • loading/SQL_transaction.md • sql-reference/sql-statements/table_bucket_part_index/TRUNCATE_TABLE.md References • administration/management/compaction.md • loading/SQL_transaction.md • sql-reference/sql-statements/loading_unloading/SHOW_TRANSACTION.md • sql-reference/sql-statements/cluster-management/nodes_processes/KILL.md • knowledge/trouble_shooting/fe_deadlock_problems.md
u
@Rocky statisrics.loads_history 통계 테이블 pattitionId 만 삭제해서 위 문제를 해결할수 있나요?
r
결론부터 말씀드리면, 
_statistics_.loads_history
테이블의 특정 `partitionId`만 삭제하는 방식은 추천되지 않으며, 문제 해결이 되지 않을 가능성이 높습니다. 그 이유는 다음과 같습니다. 1. 시스템 테이블의 구조적 제한 `_statistics_.loads_history`와 같은 시스템 테이블은 내부적으로 자동 관리되는 테이블입니다. 일반적인 비즈니스 테이블처럼 사용자가 명시적으로 파티션을 관리(DROP PARTITION)하도록 설계되지 않았으며, 강제로 특정 파티션 메타데이터만 건드릴 경우 오히려 시스템 메타데이터 불일치가 심화될 수 있습니다. 2. 'Fail to Publish'의 본질적 문제 이 이슈는 데이터 내용의 문제가 아니라 *"버전 흐름(Version Chain)"*의 문제입니다. * 현재 파티션은 *버전 N*을 완료하려고 하는데, 이를 위해 필요한 이전 로그(
txn_log
)를 Autovacuum이 지워버린 상태입니다. * 특정 파티션의 데이터만 지운다고 해서 FE(Frontend) 메모리에 로드된 "다음에 반영해야 할 버전 번호"나 "끊어진 버전 체인" 정보가 자동으로 복구되지 않습니다. * 오히려 삭제(
DELETE
또는 
DROP PARTITION
) 명령 자체도 하나의 트랜잭션이므로, 이 명령 역시 `Fail to publish`에 걸려 수행되지 않을 가능성이 매우 큽니다. 3. 해결을 위한 올바른 접근 순서 특정 파티션만 골라 삭제하기보다 아래의 방법을 순차적으로 시도하는 것이 가장 안전하고 확실합니다. 1. 전체 초기화 (
TRUNCATE
): `TRUNCATE TABLE statistics.loads_history;`를 실행하면 해당 테이블의 모든 파티션 정보와 메타데이터가 제거되고 버전이 *0*으로 리셋됩니다. 이것이 "가장 깔끔하게" 끊어진 체인을 복구하는 방법입니다. 시스템 테이블이므로 데이터를 다 지워도 운영에 지장이 없습니다. 2. FE 리더 재시작: 만약 
TRUNCATE
조차 먹히지 않는다면, FE 리더 노드를 재시작하여 메모리 내에 꼬여있는 트랜잭션 큐를 강제로 비워야 합니다. 3. DB 삭제 후 재성성 (최후의 수단): 정말 해결이 안 된다면 
DROP TABLE
후 다시 생성하거나, FE 재시작을 통해 시스템이 자동으로 테이블을 복구하도록 유도해야 합니다. 요약 
partitionId
단위의 부분 삭제는 문제를 해결하기보다 *`TRUNCATE`를 통해 테이블 전체의 메타데이터 버전을 초기화*하는 것이 v4.1.1의 Autovacuum 이슈를 해결하는 표준 조치 방법입니다. References • sql-reference/sql-statements/table_bucket_part_index/TRUNCATE_TABLE.md • administration/Meta_recovery.md • loading/loading_introduction/troubleshooting_loading.md -failure) References • knowledge/admin_and_operation/shared_data_compaction.md
2 Views
Open in Slack
PreviousNext
Powered by