<@U0A71G31CDV> Starrocks FE,CN 조합으로internal catalo...
# questions-and-troubleshootings
Sangwon
07/07/2026, 5:25 AM@Rocky Starrocks FE,CN 조합으로internal catalog pk table사용중인데, 쿼리 칠 때마다 데이터 개수가 달라지는데 이게 원인이 뭐야?
r
Rocky
07/07/2026, 5:25 AMStarRocks의 *Primary Key(PK) 테이블*을 FE+CN(Shared-data 모드) 환경에서 사용할 때 쿼리마다 데이터 개수가 다르게 나오는 현상은 크게 세 가지 원인으로 압축될 수 있습니다.
1. 데이터 가시성(Visibility) 설정 문제 (
enable_sync_publishenable_sync_publishenable_sync_publish = trueINSERTSHOW ALTER TABLE MATERIALIZED VIEWcount(_)SELECT count(_) FROM tableADMIN SHOW FRONTEND CONFIG LIKE 'enable_sync_publish';SELECT count(*) FROM table_statistics_s
Sangwon
07/07/2026, 5:44 AM@Rocky stream load할때, upsert잖아 update, insert가 각각 몇 건이 수행됐는지 알수있어?
r
Rocky
07/07/2026, 5:44 AM결론부터 말씀드리면, StarRocks의 Stream Load 결과(JSON 응답)에서는 Update와 Insert가 각각 몇 건인지 나누어 보여주지 않습니다.
1. 원인: Internal Upsert 메커니즘
StarRocks의 *Primary Key(PK) 테이블*은 내부적으로 모든 쓰기 작업을 Delete+Insert(UPSERT) 방식으로 처리합니다.
* 데이터 로드 시, 해당 PK가 이미 존재하는지 PK 인덱스에서 확인합니다.
* PK가 있으면: 기존 데이터의 위치를 찾아서 삭제 표시(Delete Vector 업데이트)를 하고, 새 데이터를 씁니다.
* PK가 없으면: 그냥 새 데이터를 씁니다.
이 과정이 원자적으로 수행되지만, 로드 결과 인터페이스에서는 둘 다 성공적으로 입력된 행으로 간주하여 *`NumberLoadedRows`*라는 하나의 합계 수치로만 반환합니다.
2. Stream Load 응답 예시
Copy code
json
{
"Status": "Success",
"NumberTotalRows": 100,
"NumberLoadedRows": 100, // Insert와 Update의 합계
"NumberFilteredRows": 0,
"NumberUnselectedRows": 0,
...
}*opr
RonJay
07/07/2026, 9:49 AM@Rocky internal catalog에 external catalog mview 를 만들어놧는데 fe 재부팅시 rEPLAY속도가 느린 이유는?
r
Rocky
07/07/2026, 9:50 AMInternal Catalog에 External Catalog(Hive, Iceberg, Glue 등) 기반의 *Materialized View(MV)*를 생성한 환경에서 FE 재부팅 시 리플레이(Replay) 속도가 느려지는 원인은 주로 외부 메타데이터와의 동기화 과정 및 방대한 파티션 정보 때문입니다.
주요 원인과 해결 방안은 다음과 같습니다.
1. 외부 카탈로그 메타데이터 조회 블로킹 (가장 유력한 원인)
StarRocks FE가 재시작하며 Edit Log를 리플레이할 때, 특정 버전이나 상황에서 *외부 시스템(Hive Metastore, HDFS, S3 등)에 직접 통신을 시도*하는 경우가 있습니다.
* 원인: 리플레이 과정 중 외부 테이블의 통계 정보(Statistics)나 파티션 정보를 업데이트하려는 로직이 실행되면서, 외부 카탈로그 응답이 늦어지면 리플레이 스레드(Replayer) 전체가 대기 상태에 빠집니다.
* 관련 버그: 최근 StarRocks 커뮤니티에서 `OP_ADD_EXTERNAL_BASIC_STATS_META`와 같은 로그를 리플레이할 때 외부 HMS 호출로 인해 리플레이가 멈추거나 느려지는 현상이 보고된 바 있습니다.
2. 방대한 파티션 메타데이터와 Edit Log 비대화
External Catalog 기반의 MV는 데이터 정합성을 위해 외부 테이블의 파티션 변경 사항을 추적합니다.
* 원인: 외부 테이블의 파티션 개수가 수만 개 이상으로 많거나, MV가 참조하는 범위가 넓을 경우 FE가 관리해야 할 메타데이터 양이 급증합니다. 이 정보들이 Edit Log에 누적되면 재부팅 시 로드해야 할 양이 많아져 시간이 오래 걸립니다.
* 현상:
meta/imagemeta/bdbimage Copy code
sql
ALTER SYSTEM CREATE IMAGE;meta/imagefe.logfe.warn.logMetadataMgr.getTableHMSr
RonJay
07/07/2026, 10:09 AM@Rocky mv_plan_cache_thread_pool_size를 늘리면 fe 부팅시 MV REPLAY시간이 짧아져?
r
Rocky
07/07/2026, 10:09 AM결론부터 말씀드리면, `mv_plan_cache_thread_pool_size`를 늘린다고 해서 FE 부팅 시의 MV 리플레이(Replay) 속도가 직접적으로 빨라지지는 않습니다.
이 설정값이 왜 리플레이 속도와 직접적인 관련이 없는지, 그리고 실제로 리플레이가 느린 원인과 해결책은 무엇인지 정리해 드립니다.
1. `mv_plan_cache_thread_pool_size`의 역할
이 파라미터는 FE 부팅 과정이 아니라, *사용자의 쿼리가 들어왔을 때 MV를 이용한 쿼리 재작성(Query Rewrite)에 필요한 플랜 캐시를 관리하는 스레드 풀*의 크기를 의미합니다. (v3.2에 도입)
* 주 용도: 쿼리 최적화 단계에서 MV를 사용해 쿼리를 변환할 때, 매번 플랜을 새로 생성하지 않고 캐시된 플랜을 가져오는 과정의 병렬 처리를 돕습니다.
* 리플레이와 무관한 이유: FE 부팅 시 수행되는 리플레이는 BDB JE(Berkeley DB)에 저장된 Edit Log를 순차적으로 읽어 메모리에 메타데이터 객체를 복구하는 과정입니다. 이 과정은 기본적으로 *단일 스레드(
replayerenable_materialized_view_concurrent_preparebackground_refresh_metadata_interval_millisr
RonJay
07/07/2026, 12:31 PM@Rocky enable_profile true 설정하면변경되는 점과 그 효과, 그리고 성능상의 디메리트가 있나
r
Rocky
07/07/2026, 12:32 PMenable_profilehttp://<FE_IP>:8030/queryget_query_profile(query_id) Copy code
sql
SET enable_profile = true;
-- 분석할 쿼리 실행
SELECT ... ;
SET enable_profile = false;SET GLOBALr
RonJay
07/08/2026, 1:11 AM@Rocky bdb edit log 쌓인거 수동으로 checkpoint생성하는법
r
Rocky
07/08/2026, 1:11 AMBDB Edit Log(메타데이터 변경 이력)이 너무 많이 쌓여 수동으로 Checkpoint(이미지 파일 생성 및 로그 정리)를 수행하는 방법은 다음과 같습니다.
1. 수동 Checkpoint 명령어 실행
StarRocks의 *Leader FE*에 접속하여 아래 SQL 명령어를 실행합니다. 이 명령은 현재 메모리에 있는 메타데이터를 스냅샷 형태의
image Copy code
sql
ALTER SYSTEM CREATE IMAGE;fe.logtriggering a new checkpoint manually...begin to generate new image: image.xxxxfinished save image.xxxxcheckpoint finished save image.xxxxmetameta/image/image.<버전번호>meta/bdb/.jdbimage.jdbimageshow proc '/frontends';Joinr
RonJay
07/08/2026, 1:24 AM@Rocky Starrocks 재기동시 Mview 리로딩할때 시간이 소요되는 이유와 시간이 안걸리는 케이스
r
Rocky
07/08/2026, 1:24 AMStarRocks FE가 재기동될 때 Materialized View(MV) 로딩(리로딩)으로 인해 시간이 소요되는 주된 이유는 메타데이터 복구(Replay) 과정에서의 직렬 처리와 외부 시스템과의 통신 지연 때문입니다.
반면, 로딩이 거의 즉시 완료되어 시간이 걸리지 않는 케이스는 메타데이터가 최신 상태로 유지되었거나 로컬 자원만 사용하는 경우입니다. 상세 내용은 다음과 같습니다.
──────────
1. 시간이 오래 걸리는 이유
1. 외부 카탈로그(HMS/S3 등) 통신 블로킹:
* 가장 큰 원인입니다. *External Catalog(Hive, Iceberg, Glue 등)*를 기반으로 생성된 MV가 많을 때, FE는 부팅 시 MV의 상태를 확인하기 위해 외부 메타데이터 서비스(HMS 등)에 연결을 시도합니다.
* 이 과정에서 네트워크 I/O가 발생하며, 외부 시스템의 응답이 늦어지면 단일 스레드로 동작하는 메타데이터 리플레이 스레드가 해당 응답을 받을 때까지 멈추게(Blocking) 되어 전체 부팅 시간이 길어집니다.
2. BDB JE Edit Log의 양:
* StarRocks는 모든 메타데이터 변경 사항을 BDB JE에 Edit Log 형식으로 저장합니다. 마지막 체크포인트(Image 생성) 이후 변경 내역이 수만 건 쌓여 있다면, 부팅 시 이를 순차적으로 하나씩 다시 읽어 MV 객체를 메모리에 생성해야 합니다.
3. 순차적 리플레이 (Sequential Replay):
* 기본적으로 메타데이터 복구는 순차적으로 진행됩니다. MV가 수천 개라면 하나하나 상태를 확인하고 플랜 정보를 복구하는 과정이 누적되어 병목이 됩니다.
──────────
2. 시간이 걸리지 않는 케이스 (빠른 케이스)
1. 내부 테이블(OLAP) 기반 MV:
* StarRocks 내부에 직접 저장된 OLAP 테이블만을 기반으로 만든 MV는 외부 시스템과 통신할 필요가 없습니다. 모든 데이터가 FE의 로컬 디스크(Meta 디렉토리)에 있으므로 리플레이 속도가 매우 빠릅니다.
2. 최신 이미지 파일(Checkpoint) 존재:
*
ALTER SYSTEM CREATE IMAGE;enable_materialized_view_concurrent_prepareenable_mv_post_image_reload_cachebackground_refresh_metadata_interval_millisignore_materialized_view_error = true2 Views