FE 구성 — 로깅, 서버, 메타데이터

원문 보기 위키 갱신 2026.10.11

FE 파라미터는 동적 파라미터와 정적 파라미터로 나뉘며, 이 문서는 로깅(Logging), 서버(Server), 메타데이터·클러스터 관리(Metadata and cluster management) 영역의 FE 구성 항목을 기본값, 타입, 변경 가능 여부, 도입 버전과 함께 정리한 참고 자료입니다. 파라미터 이름과 설정값, 코드 예시는 원문 그대로 유지되므로 fe.conf 작성 시 그대로 대입해 사용할 수 있습니다.

출처: 문서

본문

FE 파라미터는 동적 파라미터(dynamic)와 정적 파라미터(static)로 분류됩니다.

동적 파라미터는 SQL 명령으로 구성하고 조정할 수 있어 매우 편리합니다. 다만 FE를 재시작하면 설정이 무효화되므로, 변경 내용이 사라지지 않도록 fe.conf 파일의 구성 항목도 함께 수정할 것을 권장합니다.
정적 파라미터는 FE 구성 파일 fe.conf에서만 구성하고 조정할 수 있습니다. 이 파일을 수정한 후에는 변경 사항을 적용하기 위해 반드시 FE를 재시작해야 합니다.

파라미터가 동적 파라미터인지는 ADMIN SHOW CONFIG 출력의 IsMutable 컬럼으로 알 수 있습니다. TRUE이면 동적 파라미터입니다.

동적, 정적 FE 파라미터 모두 fe.conf 파일에서 구성할 수 있다는 점에 유의하세요.

FE 구성 항목 조회하기

FE가 시작된 뒤에는 MySQL 클라이언트에서 ADMIN SHOW FRONTEND CONFIG 명령을 실행해 파라미터 구성을 확인할 수 있습니다. 특정 파라미터의 구성만 조회하려면 다음 명령을 실행합니다.

ADMIN SHOW FRONTEND CONFIG [LIKE "pattern"];

반환되는 필드에 대한 자세한 설명은 ADMIN SHOW CONFIG 문서를 참고하세요.

노트: 클러스터 관리 관련 명령을 실행하려면 관리자 권한이 있어야 합니다.

FE 파라미터 구성하기

FE 동적 파라미터 구성

FE 동적 파라미터는 ADMIN SET FRONTEND CONFIG로 구성하거나 변경할 수 있습니다.

ADMIN SET FRONTEND CONFIG ("key" = "value");

노트: ADMIN SET FRONTEND로 변경한 구성은 FE가 재시작되면 fe.conf 파일의 기본값으로 복원됩니다. 따라서 변경을 영구적으로 유지하려면 fe.conf의 구성 항목도 함께 수정하기를 권장합니다.

FE 정적 파라미터 구성

노트: FE 정적 파라미터는 구성 파일 fe.conf에서 값을 변경하고, 변경 사항이 적용되도록 FE를 재시작하는 방식으로 설정합니다.

이 문서에서는 다음 유형의 FE 구성을 소개합니다.

로깅
서버
메타데이터와 클러스터 관리

로깅 (Logging)

`audit_log_delete_age`

기본값: 30d
타입: String
단위: -
변경 가능: 아니요
설명: 감사 로그 파일의 보존 기간입니다. 기본값 30d는 각 감사 로그 파일을 30일간 보관할 수 있다는 뜻이며, StarRocks는 각 감사 로그 파일을 검사해 30일 전에 생성된 파일을 삭제합니다.
도입 버전: -

`audit_log_dir`

기본값: StarRocksFE.STARROCKS_HOME_DIR + "/log"
타입: String
단위: -
변경 가능: 아니요
설명: 감사 로그 파일을 저장하는 디렉터리입니다.
도입 버전: -

`audit_log_enable_compress`

기본값: false
타입: Boolean
단위: N/A
변경 가능: 아니요
설명: true이면 생성되는 Log4j2 구성이 순환(rotated)된 감사 로그 파일 이름(fe.audit.log.*)에 ".gz" 접미사를 덧붙여서, 롤오버 시 Log4j2가 압축(.gz)된 감사 로그 아카이브 파일을 만들도록 합니다. 이 설정은 FE 시작 시 Log4jConfig.initLogging에서 읽히며 감사 로그의 RollingFile 애플렌더에 적용되고, 활성 감사 로그가 아니라 순환/아카이브된 파일에만 영향을 줍니다. 시작 시 값이 초기화되므로 변경 사항을 적용하려면 FE를 재시작해야 합니다. 감사 로그 순환 설정(audit_log_dir, audit_log_roll_interval, audit_roll_maxsize, audit_log_roll_num)과 함께 사용하세요.
도입 버전: 3.2.12

`audit_log_error_message_max_length`

기본값: 1024
타입: Int
단위: 문자
변경 가능: 예
설명: 실패한 구문에 대해 감사 로그에 기록되는 ErrorMessage 필드의 최대 길이입니다. UTF-16 코드 단위로 세므로 이모지처럼 기본 다국어 평면(BMP) 밖의 문자는 두 글자로 계산됩니다. 이보다 긴 메시지는 잘린 뒤 ... /* truncated, audit_log_error_message_max_length=<value> */ 접미사가 붙으며, 이 접미사는 길이 제한에 포함되지 않습니다. 0으로 설정하면 에러 메시지 자체를 기록하지 않아 감사 레코드에서 해당 필드가 생략됩니다. 에러 메시지는 값과 문제의 토큰까지 실패한 구문을 그대로 인용하기 때문에, enable_sql_desensitize_in_log가 true이거나 enable_audit_sql이 false이면 에러 메시지 역시 기록되지 않습니다.
도입 버전: 4.2.0

`audit_log_json_format`

기본값: false
타입: Boolean
단위: N/A
변경 가능: 예
설명: true이면 FE 감사 이벤트가 기본 파이프 구분 "key=value" 문자열 대신 구조화된 JSON으로 기록됩니다(주석이 달린 AuditEvent 필드의 Map을 Jackson ObjectMapper가 직렬화). 이 설정은 AuditLogBuilder가 처리하는 모든 내장 감사 싱크에 적용됩니다. 연결 감사, 쿼리 감사, big-query 감사(해당 이벤트가 기준을 충족하면 big-query 임계값 필드가 JSON에 추가됨), slow-audit 출력이 그 대상입니다. big-query 임계값용으로 주석 처리된 필드와 "features" 필드는 특별 취급됩니다(일반 감사 엔트리에서는 제외되고, big-query 또는 feature 로그 중 해당하는 쪽에 포함됨). 이 옵션을 켜면 로그 수집기나 SIEM이 파싱하기 쉬워지지만, 로그 형식이 바뀌므로 기존 파이프 구분 형식을 가정한 파서는 업데이트가 필요할 수 있습니다.
도입 버전: 3.2.7

`audit_log_modules`

기본값: slow_query, query
타입: String[]
단위: -
변경 가능: 아니요
설명: StarRocks가 감사 로그 엔트리를 생성하는 모듈 목록입니다. 기본적으로 slow_query 모듈과 query 모듈에 대해 감사 로그를 생성합니다. connection 모듈은 v3.0부터 지원됩니다. 모듈 이름은 쉼표(,)와 공백으로 구분합니다.
도입 버전: -

`audit_log_roll_interval`

기본값: DAY
타입: String
단위: -
변경 가능: 아니요
설명: StarRocks가 감사 로그 엔트리를 순환(rotate)하는 시간 간격입니다. 유효한 값은 DAY와 HOUR입니다.
- 이 파라미터를 DAY로 설정하면 감사 로그 파일 이름에 yyyyMMdd 형식의 접미사가 붙습니다.
- 이 파라미터를 HOUR로 설정하면 감사 로그 파일 이름에 yyyyMMddHH 형식의 접미사가 붙습니다.
도입 버전: -

`audit_log_roll_num`

기본값: 90
타입: Int
단위: -
변경 가능: 아니요
설명: audit_log_roll_interval 파라미터가 지정하는 각 보존 기간 내에서 유지할 수 있는 감사 로그 파일의 최대 개수입니다.
도입 버전: -

`audit_stmt_before_execute`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: 구문 실행 전에 FE가 BEFORE_QUERY 감사 이벤트를 기록할지 제어합니다. 활성화하면 ConnectProcessor가 실행 전에 감사 레코드 하나를 기록하고, 실행 후에도 정상적인 AFTER_QUERY 감사 레코드를 기록합니다. 이 코드 경로에서 다중 구문(multi-statement) 요청의 감사 레코드는 하위 구문 단위가 아니라 명령 단위로 유지됩니다.
도입 버전: -

`bdbje_log_level`

기본값: INFO
타입: String
단위: -
변경 가능: 아니요
설명: StarRocks에서 Berkeley DB Java Edition(BDB JE)이 사용하는 로깅 레벨을 제어합니다. BDB 환경 초기화 중 BDBEnvironment.initConfigs()가 이 값을 com.sleepycat.je 패키지의 Java 로거와 BDB JE 환경 파일 로깅 레벨(EnvironmentConfig.FILE_LOGGING_LEVEL)에 적용합니다. SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST, ALL, OFF 같은 표준 java.util.logging.Level 이름을 받습니다. ALL로 설정하면 모든 로그 메시지가 활성화됩니다. 상세도를 높이면 로그 양이 늘어나고 디스크 I/O와 성능에 영향을 줄 수 있습니다. 값은 BDB 환경이 초기화될 때 읽히므로 환경을 (재)초기화한 후에만 적용됩니다.
도입 버전: v3.2.0

`big_query_log_delete_age`

기본값: 7d
타입: String
단위: -
변경 가능: 아니요
설명: FE big query 로그 파일(fe.big_query.log.*)이 자동 삭제 전까지 유지되는 기간을 제어합니다. 이 값은 Log4j 삭제 정책에 IfLastModified age로 전달되며, 마지막 수정 시각이 이 값보다 오래된 순환된 big query 로그는 제거됩니다. d(일), h(시), m(분), s(초) 접미사를 지원합니다. 예: 7d(7일), 10h(10시간), 60m(60분), 120s(120초). 이 항목은 big_query_log_roll_interval, big_query_log_roll_num과 함께 동작해 어떤 파일을 보존하거나 제거할지 결정합니다.
도입 버전: v3.2.0

`big_query_log_dir`

기본값: Config.STARROCKS_HOME_DIR + "/log"
타입: String
단위: -
변경 가능: 아니요
설명: FE가 big query 덤프 로그(fe.big_query.log.*)를 기록하는 디렉터리입니다. Log4j 구성은 이 경로를 사용해 fe.big_query.log와 그 순환 파일을 위한 RollingFile 애플렌더를 만듭니다. 순환과 보존은 big_query_log_roll_interval(시간 기반 접미사), log_roll_size_mb(크기 트리거), big_query_log_roll_num(최대 파일 수), big_query_log_delete_age(수명 기반 삭제)가 관리합니다. big query 레코드는 big_query_log_cpu_second_threshold, big_query_log_scan_rows_threshold, big_query_log_scan_bytes_threshold처럼 사용자가 정의한 임계값을 초과한 쿼리에 대해 기록됩니다. big_query_log_modules로 어떤 모듈이 이 파일에 로그를 남길지 제어하세요.
도입 버전: v3.2.0

`big_query_log_modules`

기본값: {"query"}
타입: String[]
단위: -
변경 가능: 아니요
설명: 모듈별 big query 로깅을 활성화하는 모듈 이름 접미사 목록입니다. 일반적으로 논리 컴포넌트 이름을 값으로 사용합니다. 예컨대 기본값 query는 big_query.query를 만듭니다.
도입 버전: v3.2.0

`big_query_log_roll_interval`

기본값: "DAY"
타입: String
단위: -
변경 가능: 아니요
설명: big_query 로그 애플렌더의 순환 파일 이름에 들어가는 날짜 컴포넌트를 만들 때 쓰는 시간 간격을 지정합니다. 유효한 값(대소문자 구분 없음)은 DAY(기본값)와 HOUR입니다. DAY는 일 단위 패턴("%d{yyyyMMdd}")을, HOUR는 시간 단위 패턴("%d{yyyyMMddHH}")을 만듭니다. 이 값은 크기 기반 롤오버(big_query_roll_maxsize)와 인덱스 기반 롤오버(big_query_log_roll_num)와 결합되어 RollingFile filePattern을 이룹니다. 잘못된 값은 로그 구성 생성 실패(IOException)를 일으키고 로그 초기화나 재구성을 막을 수 있습니다. big_query_log_dir, big_query_roll_maxsize, big_query_log_roll_num, big_query_log_delete_age와 함께 사용하세요.
도입 버전: v3.2.0

`big_query_log_roll_num`

기본값: 10
타입: Int
단위: -
변경 가능: 아니요
설명: big_query_log_roll_interval당 유지할 순환된 FE big query 로그 파일의 최대 개수입니다. 이 값은 fe.big_query.log의 RollingFile 애플렌더 DefaultRolloverStrategy max 속성에 바인딩됩니다. 로그가 (시간 기준이나 log_roll_size_mb에 의해) 순환될 때 StarRocks는 big_query_log_roll_num까지의 인덱스 파일을 유지하고(filePattern은 시간 접미사와 인덱스를 사용), 이 개수를 넘는 오래된 파일은 롤오버에 의해 제거될 수 있습니다. big_query_log_delete_age는 추가로 마지막 수정 시각 기준으로 파일을 삭제할 수 있습니다.
도입 버전: v3.2.0

`dump_log_delete_age`

기본값: 7d
타입: String
단위: -
변경 가능: 아니요
설명: 덤프 로그 파일의 보존 기간입니다. 기본값 7d는 각 덤프 로그 파일을 7일간 보관할 수 있다는 뜻이며, StarRocks는 각 덤프 로그 파일을 검사해 7일 전에 생성된 파일을 삭제합니다.
도입 버전: -

`dump_log_dir`

기본값: StarRocksFE.STARROCKS_HOME_DIR + "/log"
타입: String
단위: -
변경 가능: 아니요
설명: 덤프 로그 파일을 저장하는 디렉터리입니다.
도입 버전: -

`dump_log_modules`

기본값: query
타입: String[]
단위: -
변경 가능: 아니요
설명: StarRocks가 덤프 로그 엔트리를 생성하는 모듈 목록입니다. 기본적으로 query 모듈에 대해 덤프 로그를 생성합니다. 모듈 이름은 쉼표(,)와 공백으로 구분합니다.
도입 버전: -

`dump_log_roll_interval`

기본값: DAY
타입: String
단위: -
변경 가능: 아니요
설명: StarRocks가 덤프 로그 엔트리를 순환하는 시간 간격입니다. 유효한 값은 DAY와 HOUR입니다.
- 이 파라미터를 DAY로 설정하면 덤프 로그 파일 이름에 yyyyMMdd 형식의 접미사가 붙습니다.
- 이 파라미터를 HOUR로 설정하면 덤프 로그 파일 이름에 yyyyMMddHH 형식의 접미사가 붙습니다.
도입 버전: -

`dump_log_roll_num`

기본값: 10
타입: Int
단위: -
변경 가능: 아니요
설명: dump_log_roll_interval 파라미터가 지정하는 각 보존 기간 내에서 유지할 수 있는 덤프 로그 파일의 최대 개수입니다.
도입 버전: -

`edit_log_write_slow_log_threshold_ms`

기본값: 2000
타입: Int
단위: 밀리초
변경 가능: 예
설명: JournalWriter가 느린 edit-log 배치 쓰기를 감지하고 기록하는 데 쓰는 임계값(밀리초)입니다. 배치 커밋 후 배치 처리 시간이 이 값을 초과하면 JournalWriter가 배치 크기, 소요 시간, 현재 저널 큐 크기를 담은 WARN을 남깁니다(약 2초마다 한 번으로 속도 제한). 이 설정은 FE 리더에서 발생 가능한 IO나 복제 지연에 대한 로깅/알림만 제어할 뿐 커밋이나 롤 동작은 바꾸지 않습니다(edit_log_roll_num 및 커밋 관련 설정 참조). 이 임계값과 무관하게 메트릭 업데이트는 계속 이루어집니다.
도입 버전: v3.2.3

`enable_audit_sql`

기본값: true
타입: Boolean
단위: -
변경 가능: 아니요
설명: 이 항목을 true로 설정하면 FE 감사 서브시스템이 ConnectProcessor가 처리한 구문의 SQL 텍스트를 FE 감사 로그(fe.audit.log)에 기록합니다. 저장되는 구문은 다른 제어 설정의 영향을 받습니다. 암호화된 구문은 마스킹되고(AuditEncryptionChecker), enable_sql_desensitize_in_log 설정에 따라 민감한 자격 증명이 가려지거나 비식별화될 수 있으며, 다이제스트 기록은 enable_sql_digest가 제어합니다. false로 설정하면 ConnectProcessor가 감사 이벤트에서 구문 텍스트를 "?"로 대체합니다. 다른 감사 필드(사용자, 호스트, 소요 시간, qe_slow_log_ms를 통한 slow-query 감지, 메트릭)는 계속 기록됩니다. SQL 감사를 켜면 포렌식과 문제 해결 가시성이 높아지지만 민감한 SQL 내용이 노출되고 로그 양과 I/O가 늘어날 수 있습니다. 끄면 감사 로그에서 전체 구문 가시성을 잃는 대신 개인정보 보호가 개선됩니다.
도입 버전: -

`enable_print_load_profile_to_log`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: true로 설정하면 로드 프로파일(Stream Load, Routine Load, Broker Load, Merge Commit 등)이 ProfileManager로 푸시될 때 쿼리 프로파일 로그와 같은 형식의 한 줄 JSON 레코드로 프로파일 로그(fe.profile.log)에도 INFO 레벨로 추가 기록됩니다. 이 덕분에 profile_info_reserved_num 제한으로 ProfileManager에서 축출된 뒤에도 로드 프로파일을 로그에서 복구할 수 있습니다. fe.log가 아니라 프로파일 로그를 쓰는 이유는, 프로파일 로그의 JSON 레이아웃이 훨씬 작은 sys_log_json_max_string_length가 아니라 sys_log_json_profile_max_string_length로 문자열을 제한하기 때문에 큰 로드 프로파일이 잘리지 않기 때문입니다. 파일은 profile_log_* 파라미터에 따라 순환·보존됩니다. 쿼리 타입이 Load인 프로파일만 기록되며 쿼리 프로파일은 영향을 받지 않습니다. 로드 프로파일은 실제로 수집된 경우에만 기록됩니다(예: enable_profile이 켜져 있거나 로드가 big-load 프로파일 임계값을 초과할 때).
도입 버전: -

`enable_profile_log`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: 프로파일 로깅을 활성화할지 여부입니다. 이 기능이 켜져 있으면 FE가 쿼리별 프로파일 로그(ProfileManager가 만든 직렬화된 queryDetail JSON)를 프로파일 로그 싱크에 기록합니다. 이 로깅은 enable_collect_query_detail_info도 함께 켜져 있을 때만 수행되며, enable_profile_log_compress가 켜져 있으면 기록 전에 JSON이 gzip으로 압축될 수 있습니다. 프로파일 로그 파일은 profile_log_dir, profile_log_roll_num, profile_log_roll_interval로 관리되고 profile_log_delete_age(7d, 10h, 60m, 120s 같은 형식 지원)에 따라 순환·삭제됩니다. 이 기능을 끄면 프로파일 로그 기록이 중단되어 디스크 I/O, 압축 CPU, 저장 공간 사용이 줄어듭니다. 어떤 쿼리가 기록될지는 profile_log_latency_threshold_ms로 더 걸러낼 수 있습니다.
도입 버전: v3.2.5

`enable_qe_slow_log`

기본값: true
타입: Boolean
단위: N/A
변경 가능: 예
설명: 활성화하면 FE 내장 감사 플러그인(AuditLogBuilder)이 측정된 실행 시간("Time" 필드)이 qe_slow_log_ms로 설정된 임계값을 초과하는 쿼리 이벤트를 slow-query 감사 로그(AuditLog.getSlowAudit)에 기록합니다. 비활성화하면 해당 slow-query 엔트리는 기록되지 않습니다(일반 쿼리·연결 감사 로그에는 영향 없음). slow-audit 엔트리는 전역 audit_log_json_format 설정(JSON 대 일반 문자열)을 따릅니다. 이 플래그로 일반 감사 로깅과 별개로 slow-query 감사 볼륨 생성을 제어하세요. qe_slow_log_ms가 낮거나 장시간 실행되는 쿼리가 많은 워크로드에서는 이를 끄는 것이 로그 I/O를 줄일 수 있습니다.
도입 버전: 3.2.11

`enable_sql_desensitize_in_log`

기본값: false
타입: Boolean
단위: -
변경 가능: 아니요
설명: 이 항목을 true로 설정하면 민감한 SQL 내용이 로그, 쿼리 상세 레코드, 쿼리 프로파일에 기록되기 전에 대체되거나 숨겨집니다. 이 구성을 따르는 코드 경로로는 ConnectProcessor.formatStmt(감사 로그), StmtExecutor.addRunningQueryDetail(쿼리 상세), SimpleExecutor.formatSQL(내부 실행기 로그), StmtExecutor.buildTopLevelProfile / processProfileAsync(프로파일의 Summary 섹션에 저장되는 Sql Statement와 ExplainPlan 정보 문자열)가 있습니다. 이 기능이 켜져 있으면 잘못된 SQL은 고정된 비식별화 메시지로 대체될 수 있고, 자격 증명(사용자/비밀번호)은 숨겨지며, SQL 포매터가 살균된(sanitized) 표현을 만들도록 요구됩니다(다이제스트 스타일 출력을 가능하게 할 수도 있음). enable_explain_in_profile 세션 변수가 추가하는 ExplainPlan 필드에는 이 구성이 내장된 EXPLAIN COSTS 텍스트의 리터럴 다이제스트 렌더링도 강제하므로, 프로파일이 저장된 Sql Statement가 숨겼을 리터럴을 새어 들이지 않습니다. 이를 통해 감사/내부 로그와 프로파일에서 민감한 리터럴과 자격 증명 누출이 줄어들지만, 로그·쿼리 상세·프로파일에 더 이상 원본 전체 SQL 텍스트가 담기지 않으므로 리플레이나 디버깅에 영향을 줄 수 있습니다.
도입 버전: -

`internal_log_delete_age`

기본값: 7d
타입: String
단위: -
변경 가능: 아니요
설명: FE 내부 로그 파일(internal_log_dir에 기록)의 보존 기간을 지정합니다. 값은 기간 문자열입니다. 지원 접미사: d(일), h(시), m(분), s(초). 예: 7d(7일), 10h(10시간), 60m(60분), 120s(120초). 이 항목은 RollingFile Delete 정책이 사용하는 <IfLastModified age="..."/> 술어로 log4j 구성에 치환되어 들어갑니다. 마지막 수정 시각이 이 기간보다 이전인 파일은 로그 롤오버 시 제거됩니다. 값을 늘리면 디스크 공간을 더 빨리 확보하고, 줄이면 내부 materialized view나 statistics 로그를 더 오래 보관합니다.
도입 버전: v3.2.4

`internal_log_dir`

기본값: Config.STARROCKS_HOME_DIR + "/log"
타입: String
단위: -
변경 가능: 아니요
설명: FE 로깅 서브시스템이 내부 로그(fe.internal.log)를 저장하는 데 쓰는 디렉터리입니다. 이 구성은 Log4j 구성에 치환되어 들어가며, InternalFile 애플렌더가 내부/materialized view/statistics 로그를 기록할 위치와 internal.<module> 아래 모듈별 로거가 파일을 둘 위치를 결정합니다. 디렉터리가 존재하고 쓰기 가능하며 충분한 디스크 공간이 있는지 확인하세요. 이 디렉터리 파일의 로그 순환과 보존은 log_roll_size_mb, internal_log_roll_num, internal_log_delete_age, internal_log_roll_interval이 제어합니다. sys_log_to_console이 켜져 있으면 내부 로그가 이 디렉터리 대신 콘솔로 기록될 수 있습니다.
도입 버전: v3.2.4

`internal_log_json_format`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: 이 항목을 true로 설정하면 내부 statistic/audit 엔트리가 컴팩트한 JSON 객체로 statistic audit 로거에 기록됩니다. JSON에는 "executeType"(InternalType: QUERY 또는 DML), "queryId", "sql", "time"(경과 밀리초) 키가 들어갑니다. false로 설정하면 같은 정보가 포맷된 텍스트 한 줄("statistic execute: ... | QueryId: [...] | SQL: ...")로 기록됩니다. JSON을 켜면 기계 파싱과 로그 프로세서 연동이 좋아지지만, 원본 SQL 텍스트가 로그에 포함되어 민감 정보가 노출되고 로그 크기가 커질 수 있습니다.
도입 버전: -

`internal_log_modules`

기본값: {"base", "statistic"}
타입: String[]
단위: -
변경 가능: 아니요
설명: 전용 내부 로깅을 받을 모듈 식별자 목록입니다. 각 항목 X마다 Log4j가 레벨 INFO, additivity="false"인 internal.<X> 이름의 로거를 만들고, 이 로거들은 내부 애플렌더(fe.internal.log에 기록)로 라우팅되거나 sys_log_to_console이 켜져 있으면 콘솔로 보내집니다. 짧은 이름이나 패키지 조각을 자유롭게 쓸 수 있으며, 실제 로거 이름은 internal. + 설정된 문자열이 됩니다. 내부 로그 파일의 순환과 보존은 internal_log_dir, internal_log_roll_num, internal_log_delete_age, internal_log_roll_interval, log_roll_size_mb를 따릅니다. 모듈을 추가하면 해당 런타임 메시지가 디버깅과 감사에 편리하도록 내부 로거 스트림으로 분리됩니다.
도입 버전: v3.2.4

`internal_log_roll_interval`

기본값: DAY
타입: String
단위: -
변경 가능: 아니요
설명: FE 내부 로그 애플렌더의 시간 기반 순환 간격을 제어합니다. 받아들이는 값(대소문자 구분 없음)은 HOUR와 DAY입니다. HOUR는 시간 단위 파일 패턴("%d{yyyyMMddHH}")을, DAY는 일 단위 파일 패턴("%d{yyyyMMdd}")을 만들고, RollingFile TimeBasedTriggeringPolicy가 순환된 fe.internal.log 파일 이름에 사용합니다. 잘못된 값은 초기화 실패를 일으킵니다(활성 Log4j 구성을 만들 때 IOException이 던져짐). 순환 동작은 internal_log_dir, internal_roll_maxsize, internal_log_roll_num, internal_log_delete_age 같은 관련 설정에도 의존합니다.
도입 버전: v3.2.4

`internal_log_roll_num`

기본값: 90
타입: Int
단위: -
변경 가능: 아니요
설명: 내부 애플렌더(fe.internal.log)에 대해 유지할 순환된 내부 FE 로그 파일의 최대 개수입니다. 이 값은 Log4j DefaultRolloverStrategy의 max 속성으로 사용됩니다. 롤오버가 발생하면 StarRocks는 internal_log_roll_num까지 아카이브 파일을 유지하고 더 오래된 것은 제거합니다(internal_log_delete_age의 영향도 받음). 값을 낮추면 디스크 사용은 줄지만 로그 이력이 짧아지고, 높이면 더 많은 내부 로그 이력을 보존합니다. 이 항목은 internal_log_dir, internal_log_roll_interval, internal_roll_maxsize와 함께 동작합니다.
도입 버전: v3.2.4

`log_cleaner_audit_log_min_retention_days`

기본값: 3
타입: Int
단위: 일
변경 가능: 예
설명: 감사 로그 파일의 최소 보존 일수입니다. 디스크 사용률이 높더라도 이보다 새로운 감사 로그 파일은 삭제되지 않습니다. 이를 통해 컴플라이언스와 문제 해결을 위해 감사 로그가 보존됩니다.
도입 버전: -

`log_cleaner_check_interval_second`

기본값: 300
타입: Int
단위: 초
변경 가능: 예
설명: 디스크 사용률을 점검하고 로그를 정리하는 간격(초)입니다. 클리너가 주기적으로 각 로그 디렉터리의 디스크 사용률을 확인하고 필요하면 정리를 트리거합니다. 기본값은 300초(5분)입니다.
도입 버전: -

`log_cleaner_disk_usage_target`

기본값: 60
타입: Int
단위: 백분율
변경 가능: 예
설명: 로그 정리 후 목표 디스크 사용률(백분율)입니다. 로그 정리는 디스크 사용률이 이 임계값 아래로 내려올 때까지 계속됩니다. 클리너는 가장 오래된 로그 파일부터 하나씩 삭제해 목표치에 도달합니다.
도입 버전: -

`log_cleaner_disk_usage_threshold`

기본값: 80
타입: Int
단위: 백분율
변경 가능: 예
설명: 로그 정리를 트리거하는 디스크 사용률 임계값(백분율)입니다. 디스크 사용률이 이 임계값을 넘으면 로그 정리가 시작됩니다. 클리너는 설정된 각 로그 디렉터리를 독립적으로 점검하고 임계값을 넘은 디렉터리를 처리합니다.
도입 버전: -

`log_cleaner_disk_util_based_enable`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: 디스크 사용률 기반 자동 로그 정리를 활성화합니다. 활성화하면 디스크 사용률이 임계값을 초과할 때 로그가 정리됩니다. 로그 클리너는 FE 노드에서 백그라운드 데몬으로 실행되며 로그 파일이 쌓여 디스크 공간이 고갈되는 상황을 예방합니다.
도입 버전: -

`log_plan_cancelled_by_crash_be`

기본값: true
타입: boolean
단위: -
변경 가능: 예
설명: BE 크래시나 RPC 예외로 쿼리가 취소될 때 쿼리 실행 플랜 로깅을 활성화할지 여부입니다. 이 기능이 켜져 있으면 StarRocks가 BE 크래시나 RpcException으로 취소된 쿼리의 실행 플랜(TExplainLevel.COSTS)을 WARN 엔트리로 기록합니다. 로그 엔트리에는 QueryId, SQL, COSTS 플랜이 담기고, ExecuteExceptionHandler 경로에서는 예외 스택트레이스도 함께 기록됩니다. enable_collect_query_detail_info가 켜져 있으면 플랜이 쿼리 상세에 저장되므로 이 로깅은 건너뜁니다(코드 경로에서는 쿼리 상세가 null인지 확인). 참고로 ExecuteExceptionHandler에서는 첫 재시도(retryTime == 0)에만 플랜이 기록됩니다. 전체 COSTS 플랜은 클 수 있어 이 기능을 켜면 로그 양이 늘어날 수 있습니다.
도입 버전: v3.2.0

`log_register_and_unregister_query_id`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: QeProcessorImpl이 쿼리 등록/해제 메시지(예: "register query id = {}", "deregister query id = {}")를 기록하도록 허용할지 여부입니다. 로그는 쿼리의 ConnectContext가 null이 아니고, 명령이 COM_STMT_EXECUTE가 아니거나 세션 변수 isAuditExecuteStmt()가 true인 경우에만 기록됩니다. 이 메시지는 모든 쿼리 생명주기 이벤트마다 기록되므로 켜면 로그 양이 매우 많아지고 높은 동시성 환경에서 처리량 병목이 될 수 있습니다. 디버깅이나 감사가 필요할 때만 켜고, 로깅 오버헤드를 줄여 성능을 개선하려면 끄세요.
도입 버전: v3.3.0, v3.4.0, v3.5.0

`log_roll_size_mb`

기본값: 1024
타입: Int
단위: MB
변경 가능: 아니요
설명: 시스템 로그 파일 또는 감사 로그 파일의 최대 크기입니다.
도입 버전: -

`proc_profile_file_retained_days`

기본값: 1
타입: Int
단위: 일
변경 가능: 예
설명: sys_log_dir/proc_profile 아래에 생성되는 프로세스 프로파일링 파일(CPU·메모리)을 보관하는 일수입니다. ProcProfileCollector가 현재 시각(yyyyMMdd-HHmmss 형식)에서 proc_profile_file_retained_days일을 뺀 기준 시각을 계산하고, 타임스탬프 부분이 그 기준보다 사전순으로 앞선(즉 timePart.compareTo(timeToDelete) < 0) 프로파일 파일을 삭제합니다. 삭제는 proc_profile_file_retained_size_bytes가 제어하는 크기 기준 컷오프도 함께 따릅니다. 프로파일 파일은 cpu-profile-과 mem-profile- 접두사를 사용하며 수집 후 압축됩니다.
도입 버전: v3.2.12

`proc_profile_file_retained_size_bytes`

기본값: 2L * 1024 * 1024 * 1024 (2147483648)
타입: Long
단위: Bytes
변경 가능: 예
설명: 프로파일 디렉터리 아래에 유지할 수집된 CPU·메모리 프로파일 파일(접두사 cpu-profile-, mem-profile-)의 최대 총 바이트 수입니다. 유효한 프로파일 파일의 합계가 proc_profile_file_retained_size_bytes를 초과하면 수집기가 가장 오래된 프로파일 파일을 삭제해 남은 총 크기가 proc_profile_file_retained_size_bytes 이하가 될 때까지 진행합니다. proc_profile_file_retained_days보다 오래된 파일은 크기와 관계없이 제거됩니다. 이 설정은 프로파일 아카이브의 디스크 사용을 제어하며 proc_profile_file_retained_days와 상호작용해 삭제 순서와 보존을 결정합니다.
도입 버전: v3.2.12

`profile_log_delete_age`

기본값: 1d
타입: String
단위: -
변경 가능: 아니요
설명: FE 프로파일 로그 파일이 삭제 대상이 되기 전까지 유지되는 기간을 제어합니다. 이 값은 Log4j의 <IfLastModified age="..."/> 정책에 주입되고(Log4jConfig 경유) profile_log_roll_interval, profile_log_roll_num 같은 순환 설정과 함께 적용됩니다. 지원 접미사: d(일), h(시), m(분), s(초). 예: 7d(7일), 10h(10시간), 60m(60분), 120s(120초).
도입 버전: v3.2.5

`profile_log_dir`

기본값: Config.STARROCKS_HOME_DIR + "/log"
타입: String
단위: -
변경 가능: 아니요
설명: FE 프로파일 로그가 기록되는 디렉터리입니다. Log4jConfig가 이 값을 사용해 프로파일 관련 애플렌더를 배치합니다(이 디렉터리 아래 fe.profile.log 같은 파일 생성). 이 파일들의 순환과 보존은 profile_log_roll_size_mb, profile_log_roll_num, profile_log_delete_age가 관리하고, 타임스탬프 접미사 형식은 profile_log_roll_interval(DAY 또는 HOUR 지원)이 제어합니다. 기본 디렉터리가 STARROCKS_HOME_DIR 아래에 있으므로 FE 프로세스가 이 디렉터리에 쓰기·순환·삭제 권한을 갖도록 하세요.
도입 버전: v3.2.5

`profile_log_latency_threshold_ms`

기본값: 0
타입: Long
단위: 밀리초
변경 가능: 예
설명: 프로파일이 fe.profile.log에 기록되기 위한 최소 쿼리 지연 시간(밀리초)입니다. 실행 시간이 이 값 이상인 쿼리만 기록됩니다. 0으로 설정하면 모든 프로파일이 기록됩니다(임계값 없음). 느린 쿼리만 기록해 로그 양을 줄이려면 양수를 사용하세요.
도입 버전: -

`profile_log_roll_interval`

기본값: DAY
타입: String
단위: -
변경 가능: 아니요
설명: 프로파일 로그 파일 이름의 날짜 부분을 생성하는 데 쓰는 시간 단위를 제어합니다. 유효한 값(대소문자 구분 없음)은 HOUR와 DAY입니다. HOUR는 "%d{yyyyMMddHH}" 패턴(시간 단위 버킷)을, DAY는 "%d{yyyyMMdd}" 패턴(일 단위 버킷)을 만듭니다. 이 값은 Log4j 구성에서 profile_file_pattern을 계산할 때 사용되며 롤오버 파일 이름의 시간 기반 컴포넌트에만 영향을 줍니다. 크기 기반 롤오버는 여전히 profile_log_roll_size_mb가, 보존은 profile_log_roll_num / profile_log_delete_age가 제어합니다. 잘못된 값은 로깅 초기화 중 IOException을 일으킵니다(에러 메시지: "profile_log_roll_interval config error: <value>"). 대량 프로파일링에서 시간당 파일 크기를 제한하려면 HOUR를, 일 단위 집계에는 DAY를 선택하세요.
도입 버전: v3.2.5

`profile_log_roll_num`

기본값: 5
타입: Int
단위: -
변경 가능: 아니요
설명: 프로파일 로거에 대해 Log4j DefaultRolloverStrategy가 유지하는 순환된 프로파일 로그 파일의 최대 개수를 지정합니다. 이 값은 로깅 XML에 ${profile_log_roll_num}로 주입됩니다(예: <DefaultRolloverStrategy max="${profile_log_roll_num}" fileIndex="min">). 순환은 profile_log_roll_size_mb나 profile_log_roll_interval에 의해 트리거되며, 순환이 일어나면 Log4j가 이 개수까지의 인덱스 파일을 유지하고 더 오래된 인덱스 파일은 제거 대상이 됩니다. 실제 디스크 보존은 profile_log_delete_age와 profile_log_dir 위치의 영향도 받습니다. 값을 낮추면 디스크 사용은 줄지만 보존되는 이력이 제한되고, 높이면 더 많은 프로파일 로그 이력을 보존합니다.
도입 버전: v3.2.5

`profile_log_roll_size_mb`

기본값: 1024
타입: Int
단위: MB
변경 가능: 아니요
설명: FE 프로파일 로그 파일의 크기 기반 롤오버를 트리거하는 크기 임계값(메가바이트)을 설정합니다. 이 값은 ProfileFile 애플렌더의 Log4j RollingFile SizeBasedTriggeringPolicy에 사용되며, 프로파일 로그가 profile_log_roll_size_mb를 초과하면 순환됩니다. profile_log_roll_interval에 도달해도 시간 기준으로 순환될 수 있습니다. 두 조건 중 하나라도 만족되면 롤오버가 일어납니다. profile_log_roll_num, profile_log_delete_age와 결합해 얼마나 많은 과거 프로파일 파일을 유지하고 언제 오래된 파일을 삭제할지 제어합니다. 순환된 파일의 압축은 enable_profile_log_compress가 제어합니다.
도입 버전: v3.2.5

`qe_slow_log_ms`

기본값: 5000
타입: Long
단위: 밀리초
변경 가능: 예
설명: 쿼리가 slow query인지 판단하는 데 쓰는 임계값입니다. 쿼리의 응답 시간이 이 임계값을 초과하면 fe.audit.log에 slow query로 기록됩니다.
도입 버전: -

`slow_lock_log_l2_info_interval_ms`

기본값: 3000L
타입: Long
단위: 밀리초
변경 가능: 예
별칭: slow_lock_log_every_ms(원래 이름이며 하위 호환을 위해 유지됩니다. 두 이름은 같은 파라미터를 가리킵니다)
설명: L2 slow-lock 로그 티어의 최소 간격(밀리초)입니다. L2는 스택트레이스 없이 전체 lock-info JSON 한 줄을 기록합니다. slow-lock 로깅은 세 개의 티어로 나뉘어 점진적으로 스로틀됩니다(가장 엄격한 것이 먼저). L1 = 전체 정보 + 스택(slow_lock_log_l1_stack_interval_ms), L2 = 스택 없는 전체 정보(이 파라미터), L3 = 일반 텍스트 요약 한 줄(slow_lock_log_l3_brief_interval_ms). 하나의 slow-lock 이벤트에 대해 현재 스로틀이 허용하는 가장 풍부한 티어가 기록되며, 높은 티어를 선택하면 느슨한 티어의 윈도도 소모하므로 총 로그 볼륨이 가장 느슨한 허용 티어의 속도를 넘지 않습니다. 스로틀 범위는 기록하는 계층에 따라 다릅니다. LockManager.logSlowLockTrace에서는 전역(모든 rid에 걸친 정적 게이트 하나), QueryableReentrantReadWriteLock에서는 인스턴스별(각 lock 객체, 예: 각 RoutineLoadJob에 자체 게이트), 레거시 LockUtils 경로에서는 Database별입니다. 0(또는 음수)으로 설정하면 L2 게이트가 꺼져 항상 허용됩니다. 장기 경합 중 로그 볼륨을 줄이려면 더 큰 값을, 더 자주 전체 정보 진단을 얻으려면 더 작은 값을 사용하세요.
도입 버전: v3.2.0(slow_lock_log_every_ms로 도입), v4.1에서 slow_lock_log_l2_info_interval_ms로 이름 변경

`slow_lock_print_stack`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: slow-lock 경고 안에 소유자/현재 스레드 스택트레이스를 담을지의 마스터 스위치입니다. LockManager.logSlowLockTrace(소유자별 "stack" 필드)와 QueryableReentrantReadWriteLock.getLockInfoToJson(레거시 db-lock 경로와 RoutineLoadJob의 잡별 락이 쓰는 소유자/가장 오래된 리더/현재 스레드 "stack" 필드) 양쪽에 적용됩니다. 이 기능을 켜면 락을 쥔 정확한 스레드 스택을 제공해 디버깅에 도움이 됩니다. 끄면 높은 동시성 환경에서 스택트레이스 캡처와 직렬화로 생기는 로그 볼륨과 CPU/메모리 오버헤드가 줄어듭니다. 켜져 있을 때 캡처 빈도는 slow_lock_log_l1_stack_interval_ms로 추가 속도 제한됩니다.
도입 버전: v3.3.16, v3.4.5, v3.5.1

`slow_lock_log_l1_stack_interval_ms`

기본값: 30000
타입: Long
단위: 밀리초
변경 가능: 예
설명: slow-lock 로그 이벤트 간 스택트레이스 캡처의 최소 간격입니다. slow_lock_print_stack이 true일 때만 적용됩니다. 스로틀 범위는 계층에 따라 다릅니다. LockManager.logSlowLockTrace에서는 전역(모든 rid에 걸친 정적 게이트 하나), QueryableReentrantReadWriteLock.getLockInfoToJson에서는 인스턴스별(각 lock 객체가 자체 게이트를 가짐)입니다. 스위치가 켜져 있어도 마지막 캡처 후 이 간격이 지나지 않았다면 "stack" 필드가 "throttled" 마커로 대체되거나(LockManager 경로) 생략되고(QueryableReentrantReadWriteLock 경로), 외부 이벤트 게이트(slow_lock_log_l2_info_interval_ms)가 통과시켜 준다면 rid, owners, waiters, queryIds, timings 같은 경고 로그의 나머지는 계속 기록됩니다. 0(또는 음수)으로 설정하면 속도 제한이 해제되고 이전처럼 모든 slow-lock 이벤트에서 스택이 캡처됩니다. Thread.getStackTrace는 JVM 세이프포인트를 유발하는데, slow-lock 이벤트가 잦은 대규모 클러스터에서는 비용이 커질 수 있습니다. 이 게이트는 진단 로그 자체를 막지 않고 그 비용을 상한으로 묶어 둡니다.
도입 버전: v4.1

`slow_lock_max_waiter_count_to_log`

기본값: 30
타입: Int
단위: -
변경 가능: 예
설명: 하나의 slow-lock 로그 이벤트에 직렬화될 waiter 엔트리의 최대 개수입니다. LockManager.logSlowLockTrace의 "waiter" 배열과, 레거시 db-lock 경로 및 RoutineLoadJob의 잡별 락이 소비하는 QueryableReentrantReadWriteLock.getLockInfoToJson의 "queuedReaders" / "queuedWriters" 배열 양쪽에 적용됩니다. 실제 waiter 수가 이 상한을 넘으면 처음 N개의 waiter는 개별적으로 나열되고 나머지는 배열에 덧붙이는 하나의 트레일러 엔트리 {"omitted": "remain M waiters omitted"}로 요약됩니다. 개수 진단을 잃지 않으면서 극단적 경합에서 Gson 직렬화 비용과 로그 줄 크기를 한계 묶어 둡니다. 0(또는 음수)으로 설정하면 상한이 해제되어 모든 waiter가 직렬화됩니다.
도입 버전: v4.1

`slow_lock_log_l3_brief_interval_ms`

기본값: 1000
타입: Long
단위: 밀리초
변경 가능: 예
설명: L3 slow-lock 로그 티어의 최소 간격입니다. L3는 더 풍부한 티어(L1은 slow_lock_log_l1_stack_interval_ms, L2는 slow_lock_log_l2_info_interval_ms)가 스로틀될 때 기록되는 일반 텍스트 경고 한 줄(JSON도 스택도 없음)이며, 세 티어 중 가장 느슨합니다. 요약 줄은 이 간격당 최대 한 번 기록됩니다. L3 게이트가 아직 닫혀 있는 동안 도착한 slow-lock 이벤트는 억제됩니다(기록 없음). 이벤트마다 로그 한 줄을 보장하지는 않으며, 지속적 경합 중 최악의 침묵 구간을 한 brief 간격으로 한계 묶어 둡니다. 다른 두 값보다 작게 조정하세요: slow_lock_log_l3_brief_interval_ms < slow_lock_log_l2_info_interval_ms < slow_lock_log_l1_stack_interval_ms. 0(또는 음수)으로 설정하면 요약 줄이 스로틀되지 않아 그 외 스로틀된 모든 이벤트가 한 줄을 남깁니다(예측 가능하지만 스톰 상황에서는 초당 여러 줄이 될 수 있음). 다른 slow-lock 스로틀과 같은 범위 규칙을 따릅니다(LockManager 전역, QueryableReentrantReadWriteLock 인스턴스별).
도입 버전: v4.1

`slow_lock_threshold_ms`

기본값: 3000L
타입: long
단위: 밀리초
변경 가능: 예
설명: 락 동작이나 점유 중인 락을 "slow"로 분류하는 데 쓰는 임계값(밀리초)입니다. 락의 대기 시간이나 점유 시간이 이 값을 초과하면 StarRocks는 (문맥에 따라) 진단 로그를 기록하고, 스택트레이스나 waiter/owner 정보를 포함하며, LockManager에서는 이 지연 이후 교착 상태 감지를 시작합니다. LockUtils(slow-lock 로깅), QueryableReentrantReadWriteLock(느린 리더 필터링), LockManager(교착 상태 감지 지연과 slow-lock 트레이스), LockChecker(주기적 slow-lock 감지) 및 기타 호출자(예: DiskAndTabletLoadReBalancer 로깅)가 사용합니다. 값을 낮추면 감지 민감도와 로깅/진단 오버헤드가 커지고, 0 또는 음수로 설정하면 초기 대기 기반 교착 상태 감지 지연 동작이 비활성화됩니다. slow_lock_log_l2_info_interval_ms, slow_lock_print_stack, slow_lock_stack_trace_reserve_levels와 함께 조정하세요.
도입 버전: 3.2.0

`sys_log_delete_age`

기본값: 7d
타입: String
단위: -
변경 가능: 아니요
설명: 시스템 로그 파일의 보존 기간입니다. 기본값 7d는 각 시스템 로그 파일을 7일간 보관할 수 있다는 뜻이며, StarRocks는 각 시스템 로그 파일을 검사해 7일 전에 생성된 파일을 삭제합니다.
도입 버전: -

`sys_log_dir`

기본값: StarRocksFE.STARROCKS_HOME_DIR + "/log"
타입: String
단위: -
변경 가능: 아니요
설명: 시스템 로그 파일을 저장하는 디렉터리입니다.
도입 버전: -

`sys_log_enable_compress`

기본값: false
타입: boolean
단위: -
변경 가능: 아니요
설명: 이 항목을 true로 설정하면 시스템이 순환된 시스템 로그 파일 이름에 ".gz" 접미사를 덧붙여서 Log4j가 gzip 압축된 순환 FE 시스템 로그(예: fe.log.*)를 만들도록 합니다. 이 값은 Log4j 구성 생성 중에(Log4jConfig.initLogging / generateActiveLog4jXmlConfig) 읽히며 RollingFile filePattern에 쓰이는 sys_file_postfix 속성을 제어합니다. 이 기능을 켜면 보존 로그의 디스크 사용이 줄지만 롤오버 중 CPU와 I/O가 늘고 로그 파일 이름이 바뀌므로, 로그를 읽는 도구나 스크립트가 .gz 파일을 처리할 수 있어야 합니다. 감사 로그는 압축에 별도 구성(audit_log_enable_compress)을 사용한다는 점에 유의하세요.
도입 버전: v3.2.12

`sys_log_format`

기본값: "plaintext"
타입: String
단위: -
변경 가능: 아니요
설명: FE 로그에 사용할 Log4j 레이아웃을 선택합니다. 유효한 값: "plaintext"(기본값)와 "json". 값은 대소문자를 구분하지 않습니다. "plaintext"는 사람이 읽을 수 있는 타임스탬프, 레벨, 스레드, class.method :line 과 WARN/ERROR의 스택트레이스를 갖춘 PatternLayout을 구성합니다. "json"은 JsonTemplateLayout을 구성해 로그 수집기(ELK, Splunk)에 적합한 구조화된 JSON 이벤트(UTC 타임스탬프, 레벨, 스레드 id/name, 소스 파일/메서드/라인, 메시지, 예외 stackTrace)를 내보냅니다. JSON 출력은 최대 문자열 길이에 대해 sys_log_json_max_string_length와 sys_log_json_profile_max_string_length를 따릅니다.
도입 버전: v3.2.10

`sys_log_json_max_string_length`

기본값: 1048576
타입: Int
단위: Bytes
변경 가능: 아니요
설명: JSON 형식 시스템 로그에 사용되는 JsonTemplateLayout의 "maxStringLength" 값을 설정합니다. sys_log_format이 "json"일 때 문자열 필드(예: "message"와 문자열화된 예외 스택트레이스)의 길이가 이 한계를 넘으면 잘립니다. 이 값은 Log4jConfig.generateActiveLog4jXmlConfig()에서 생성된 Log4j XML에 주입되며 default, warning, audit, dump, bigquery 레이아웃에 적용됩니다. 프로파일 레이아웃은 별도 구성(sys_log_json_profile_max_string_length)을 사용합니다. 값을 낮추면 로그 크기가 줄지만 유용한 정보가 잘릴 수 있습니다.
도입 버전: 3.2.11

`sys_log_json_profile_max_string_length`

기본값: 104857600 (100 MB)
타입: Int
단위: Bytes
변경 가능: 아니요
설명: sys_log_format이 "json"일 때 프로파일(및 관련 feature) 로그 애플렌더의 JsonTemplateLayout maxStringLength를 설정합니다. JSON 형식 프로파일 로그의 문자열 필드 값은 이 바이트 길이로 잘리고, 문자열이 아닌 필드는 영향을 받지 않습니다. 이 항목은 Log4jConfig의 JsonTemplateLayout maxStringLength에 적용되며 plaintext 로깅을 쓸 때는 무시됩니다. 필요한 전체 메시지가 담길 만큼 크게 유지하되, 값이 커질수록 로그 크기와 I/O가 늘어난다는 점에 유의하세요.
도입 버전: v3.2.11

`sys_log_level`

기본값: INFO
타입: String
단위: -
변경 가능: 아니요
설명: 시스템 로그 엔트리가 분류되는 심각도 레벨입니다. 유효한 값: INFO, WARN, ERROR, FATAL.
도입 버전: -

`sys_log_roll_interval`

기본값: DAY
타입: String
단위: -
변경 가능: 아니요
설명: StarRocks가 시스템 로그 엔트리를 순환하는 시간 간격입니다. 유효한 값은 DAY와 HOUR입니다.
- 이 파라미터를 DAY로 설정하면 시스템 로그 파일 이름에 yyyyMMdd 형식의 접미사가 붙습니다.
- 이 파라미터를 HOUR로 설정하면 시스템 로그 파일 이름에 yyyyMMddHH 형식의 접미사가 붙습니다.
도입 버전: -

`sys_log_roll_num`

기본값: 10
타입: Int
단위: -
변경 가능: 아니요
설명: sys_log_roll_interval 파라미터가 지정하는 각 보존 기간 내에서 유지할 수 있는 시스템 로그 파일의 최대 개수입니다.
도입 버전: -

`sys_log_to_console`

기본값: false (단, 환경 변수 SYS_LOG_TO_CONSOLE이 "1"로 설정된 경우는 예외)
타입: Boolean
단위: -
변경 가능: 아니요
설명: 이 항목을 true로 설정하면 시스템이 파일 기반 애플렌더 대신 모든 로그를 콘솔(ConsoleErr 애플렌더)로 보내도록 Log4j를 구성합니다. 이 값은 활성 Log4j XML 구성을 생성할 때 읽히며(루트 로거와 모듈별 로거 애플렌더 선택에 영향) 프로세스 시작 시 SYS_LOG_TO_CONSOLE 환경 변수에서 값을 가져옵니다. 런타임에 바꿔도 효과가 없습니다. 이 구성은 로그 파일 쓰기보다 stdout/stderr 수집을 선호하는 컨테이너화된 환경이나 CI 환경에서 자주 쓰입니다.
도입 버전: v3.2.0

`sys_log_verbose_modules`

기본값: 빈 문자열
타입: String[]
단위: -
변경 가능: 아니요
설명: StarRocks가 시스템 로그를 생성하는 모듈입니다. 이 파라미터를 org.apache.starrocks.catalog로 설정하면 StarRocks가 catalog 모듈에 대해서만 시스템 로그를 생성합니다. 모듈 이름은 쉼표(,)와 공백으로 구분합니다.
도입 버전: -

`sys_log_warn_modules`

기본값: (없음)
타입: String[]
단위: -
변경 가능: 아니요
설명: 시작 시 시스템이 WARN 레벨 로거로 구성하고 경고 애플렌더(SysWF, 즉 fe.warn.log 파일)로 라우팅할 로거 이름이나 패키지 접두사 목록입니다. 항목은 생성된 Log4j 구성에 삽입되어(org.apache.kafka, org.apache.hudi, org.apache.hadoop.io.compress 같은 내장 경고 모듈과 나란히) <Logger name="... " level="WARN"><AppenderRef ref="SysWF"/></Logger> 같은 로거 엘리먼트를 만듭니다. 완전한 패키지·클래스 접두사(예: "com.example.lib")를 권장합니다. 일반 로그로 흘러가는 noisy한 INFO/DEBUG 출력을 억제하고 경고를 별도로 수집할 수 있습니다.
도입 버전: v3.2.13

서버 (Server)

enable_auth_check

기본값: true
타입: Boolean
단위: -
변경 가능: 아니요
설명: 인증 검사(authentication check) 기능을 활성화할지 지정합니다. 유효한 값: TRUE와 FALSE. TRUE는 이 기능을 켜고, FALSE는 끕니다.
도입 버전: -

`brpc_idle_wait_max_time`

기본값: 10000
타입: Int
단위: ms
변경 가능: 아니요
설명: bRPC 클라이언트가 idle 상태로 대기할 수 있는 최대 시간입니다.
도입 버전: -

`brpc_inner_reuse_pool`

기본값: true
타입: boolean
단위: -
변경 가능: 아니요
설명: 기반 BRPC 클라이언트가 연결/채널에 내부 공유 재사용 풀을 사용할지 제어합니다. StarRocks는 BrpcProxy에서 RpcClientOptions를 구성할 때 brpc_inner_reuse_pool을 읽습니다(rpcOptions.setInnerResuePool(...) 경유). 켜면(true) RPC 클라이언트가 내부 풀을 재사용해 호출별 연결 생성을 줄이고, FE-to-BE / LakeService RPC의 연결 교체 churn, 메모리, 파일 디스크립터 사용을 낮춥니다. 끄면(false) 더 분리된 풀을 여러 개 만들 수 있어(동시성 격리는 높아지지만 리소스 사용이 늘어남) 이 값을 바꾸려면 프로세스 재시작이 필요합니다.
도입 버전: v3.3.11, v3.4.1, v3.5.0

`brpc_min_evictable_idle_time_ms`

기본값: 120000
타입: Int
단위: 밀리초
변경 가능: 아니요
설명: idle 상태의 BRPC 연결이 축출 대상이 되기 전까지 연결 풀에 머물러야 하는 시간(밀리초)입니다. BrpcProxy가 사용하는 RpcClientOptions에 적용됩니다(RpcClientOptions.setMinEvictableIdleTime 경유). 값을 올리면 idle 연결을 더 오래 유지해 재연결 churn이 줄고, 내리면 쓰이지 않는 소켓을 더 빨리 회수해 리소스 사용이 줄어듭니다. 연결 재사용, 풀 성장, 축출 동작의 균형을 맞추려면 brpc_connection_pool_size와 brpc_idle_wait_max_time과 함께 조정하세요.
도입 버전: v3.3.11, v3.4.1, v3.5.0

`brpc_reuse_addr`

기본값: true
타입: Boolean
단위: -
변경 가능: 아니요
설명: true이면 StarRocks가 brpc RpcClient가 만드는 클라이언트 소켓에 로컬 주소 재사용을 허용하는 소켓 옵션을 설정합니다(RpcClientOptions.setReuseAddress 경유). 켜면 바인드 실패가 줄고 소켓을 닫은 뒤 로컬 포트를 더 빨리 재바인딩할 수 있어 높은 빈도의 연결 churn이나 빠른 재시작에 유용합니다. false이면 주소/포트 재사용이 꺼져 의도치 않은 포트 공유 가능성은 줄지만 일시적 바인드 오류가 늘어날 수 있습니다. 이 옵션은 클라이언트 소켓을 얼마나 빨리 재바인딩하고 재사용할 수 있는지에 영향을 주므로 brpc_connection_pool_size와 brpc_short_connection이 구성한 연결 동작과 상호작용합니다.
도입 버전: v3.3.11, v3.4.1, v3.5.0

`brpc_connection_pool_retry_wait_time_ms`

기본값: 10
타입: Int
단위: ms
변경 가능: 예
설명: bRPC 연결 풀 예외가 발생했을 때(예: TCP 핸드셰이크 중 SYN 패킷 손실) 재시도 전에 기다리는 시간입니다. ChannelPool.getChannel()이 NoSuchElementException을 던지면(직접 또는 RuntimeException으로 감싸져) 재시도 로직이 이 시간만큼 잠자고 재연결을 시도합니다.
도입 버전: -

`cluster_name`

기본값: StarRocks Cluster
타입: String
단위: -
변경 가능: 아니요
설명: FE가 속한 StarRocks 클러스터의 이름입니다. 클러스터 이름은 웹 페이지의 Title로 표시됩니다.
도입 버전: -

`dns_cache_ttl_seconds`

기본값: 60
타입: Int
단위: 초
변경 가능: 아니요
설명: 성공한 DNS 조회에 대한 DNS 캐시 TTL(Time-To-Live, 초)입니다. 이 값은 JVM이 성공한 DNS 조회를 얼마나 캐시할지 제어하는 Java 보안 속성 networkaddress.cache.ttl을 설정합니다. -1로 설정하면 시스템이 정보를 항상 캐시하고, 0이면 캐싱을 끕니다. Kubernetes 배포처럼 IP 주소가 자주 바뀌는 환경이나 동적 DNS를 사용할 때 특히 유용합니다.
도입 버전: v3.5.11, v4.0.4

`enable_http_async_handler`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: 시스템이 HTTP 요청을 비동기로 처리하도록 허용할지 여부입니다. 이 기능이 켜져 있으면 Netty 워커 스레드가 받은 HTTP 요청이 HTTP 서버를 블로킹하지 않도록 별도의 스레드 풀에 제출되어 서비스 로직을 처리합니다. 끄면 Netty 워커가 서비스 로직을 직접 처리합니다.
도입 버전: 4.0.0

`enable_http_validate_headers`

기본값: false
타입: Boolean
단위: -
변경 가능: 아니요
설명: Netty의 HttpServerCodec이 엄격한 HTTP 헤더 검증을 수행할지 제어합니다. 이 값은 HttpServer에서 HTTP 파이프라인이 초기화될 때 HttpServerCodec에 전달됩니다(UseLocations 참조). 최신 netty 버전이 더 엄격한 헤더 규칙을 강제하므로(https://github.com/netty/netty/pull/12760) 하위 호환을 위해 기본값은 false입니다. true로 설정하면 RFC를 준수하는 헤더 검사를 강제할 수 있으며, 이러면 레거시 클라이언트나 프록시가 보낸 형식이 틀리거나 규격에 맞지 않는 요청이 거부될 수 있습니다. 변경 사항을 적용하려면 HTTP 서버 재시작이 필요합니다.
도입 버전: v3.3.0, v3.4.0, v3.5.0

`enable_https`

기본값: false
타입: Boolean
단위: -
변경 가능: 아니요
설명: FE 노드에서 HTTP 서버와 함께 HTTPS 서버를 활성화할지 여부입니다.
도입 버전: v4.0

`frontend_address`

기본값: 0.0.0.0
타입: String
단위: -
변경 가능: 아니요
설명: FE 노드의 IP 주소입니다.
도입 버전: -

`http_async_threads_num`

기본값: 4096
타입: Int
단위: -
변경 가능: 예
설명: 비동기 HTTP 요청 처리를 위한 스레드 풀의 크기입니다. 별칭은 max_http_sql_service_task_threads_num입니다.
도입 버전: 4.0.0

`http_backlog_num`

기본값: 1024
타입: Int
단위: -
변경 가능: 아니요
설명: FE 노드의 HTTP 서버가 유지하는 백로그(backlog) 큐의 길이입니다.
도입 버전: -

`http_max_chunk_size`

기본값: 8192
타입: Int
단위: Bytes
변경 가능: 아니요
설명: FE HTTP 서버에서 Netty의 HttpServerCodec이 처리하는 단일 HTTP 청크의 최대 허용 크기(바이트)를 설정합니다. HttpServerCodec의 세 번째 인자로 전달되며 청크 전송이나 스트리밍 요청/응답 중 청크 길이를 제한합니다. 들어오는 청크가 이 값을 넘으면 Netty가 frame-too-large 오류(예: TooLongFrameException)를 일으키고 요청이 거부될 수 있습니다. 정당한 대형 청크 업로드를 지원하려면 늘리고, 메모리 압박과 DoS 공격 표면을 줄이려면 작게 유지하세요. 이 설정은 http_max_initial_line_length, http_max_header_size, enable_http_validate_headers와 함께 사용됩니다.
도입 버전: v3.2.0

`http_max_header_size`

기본값: 32768
타입: Int
단위: Bytes
변경 가능: 아니요
설명: Netty의 HttpServerCodec이 파싱하는 HTTP 요청 헤더 블록의 최대 허용 크기(바이트)입니다. StarRocks가 이 값을 HttpServerCodec에 전달하며(Config.http_max_header_size), 들어오는 요청의 헤더(이름과 값을 합쳐)가 이 한계를 넘으면 코덱이 요청을 거부하고(디코더 예외) 연결/요청이 실패합니다. 클라이언트가 정당하게 매우 큰 헤더(큰 쿠키나 많은 커스텀 헤더)를 보낼 때만 늘리세요. 값이 커지면 연결당 메모리 사용이 늘어납니다. http_max_initial_line_length와 http_max_chunk_size와 함께 조정하세요. 변경 시 FE 재시작이 필요합니다.
도입 버전: v3.2.0

`http_max_initial_line_length`

기본값: 4096
타입: Int
단위: Bytes
변경 가능: 아니요
설명: HttpServer에서 쓰이는 Netty HttpServerCodec이 받아들이는 HTTP 초기 요청 줄(메서드 + 요청 대상 + HTTP 버전)의 최대 허용 길이(바이트)를 설정합니다. 이 값은 Netty 디코더에 전달되며 초기 줄이 이보다 긴 요청은 거부됩니다(TooLongFrameException). 매우 긴 요청 URI를 지원해야 할 때만 늘리세요. 값이 커지면 메모리 사용이 늘고 잘못된 요청/요청 남용에 대한 노출이 커질 수 있습니다. http_max_header_size와 http_max_chunk_size와 함께 조정하세요.
도입 버전: v3.2.0

`http_port`

기본값: 8030
타입: Int
단위: -
변경 가능: 아니요
설명: FE 노드의 HTTP 서버가 수신 대기하는 포트입니다.
도입 버전: -

`enable_http_auth`

기본값: false
타입: Boolean
단위: -
변경 가능: 아니요
도입 버전: v4.2.0
설명: true이면 대부분의 외부 FE HTTP 엔드포인트가 HTTP Basic Auth를 요구합니다. 자격 증명은 AuthenticationHandler.authenticate()를 통해 사용자 스토어로 검증되므로 LDAP / security-integration 로그인이 MySQL 프로토콜과 같은 방식으로 HTTP 경로에서 동작합니다. 다음은 예외입니다:
- 공개 프로브 / 관측: /api/bootstrap, /api/oauth2.
- 핸들러 내부에서 IP 화이트리스트 또는 토큰 게이트가 걸린 피어-FE / 컨트롤 플레인 경로: /image, /check, /journal_id, /info, /role, /dump, /dump_starmgr, /service_id, /static, /api/_meta_replay_state, /api/get_small_file.
권한이 있는 엔드포인트는 추가로 호출자의 세션에서 활성화된 SYSTEM 레벨 RBAC 권한(OPERATE 또는 NODE)을 요구합니다. 권한을 부여한 역할이 사용자의 기본 역할이 아니라면 SET DEFAULT ROLE <roles> TO <user>;를 실행하거나 전역 변수 activate_all_roles_on_login=true를 설정해 로그인 시 역할이 활성화되도록 하세요. LDAP / security-integration 그룹 → 역할 매핑은 자동으로 활성화됩니다.

`http_web_page_display_hardware`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: true이면 HTTP 인덱스 페이지(/index)에 oshi 라이브러리로 채워지는 하드웨어 정보 섹션(CPU, 메모리, 프로세스, 디스크, 파일시스템, 네트워크 등)이 포함됩니다. oshi는 시스템 유틸리티를 호출하거나 시스템 파일을 간접적으로 읽을 수 있고(예: getent passwd 같은 명령 실행 가능), 민감한 시스템 데이터가 노출될 수 있습니다. 더 엄격한 보안이 필요하거나 호스트에서 그런 간접 명령 실행을 피하고 싶다면 이 구성을 false로 설정해 웹 UI의 하드웨어 상세 수집·표시를 비활성화하세요.
도입 버전: v3.2.0

`http_worker_threads_num`

기본값: 0
타입: Int
단위: -
변경 가능: 아니요
설명: HTTP 서버가 HTTP 요청을 처리하는 데 쓰는 워커 스레드 수입니다. 음수나 0이면 스레드 수는 CPU 코어 수의 두 배가 됩니다.
도입 버전: v2.5.18, v3.0.10, v3.1.7, v3.2.2

`https_port`

기본값: 8443
타입: Int
단위: -
변경 가능: 아니요
설명: FE 노드의 HTTPS 서버가 수신 대기하는 포트입니다.
도입 버전: v4.0

`max_mysql_service_task_threads_num`

기본값: 4096
타입: Int
단위: -
변경 가능: 아니요
설명: FE 노드의 MySQL 서버가 작업을 처리하기 위해 실행할 수 있는 최대 스레드 수입니다.
도입 버전: -

`max_task_runs_threads_num`

기본값: 512
타입: Int
단위: 스레드
변경 가능: 아니요
설명: task-run 실행기 스레드 풀의 최대 스레드 수를 제어합니다. 이 값은 동시 task-run 실행의 상한이며, 늘리면 병렬성이 높아지는 대신 CPU·메모리·네트워크 사용이 늘어나고, 줄이면 task-run 백로그와 지연이 커질 수 있습니다. 예상되는 동시 예약 작업과 가용 시스템 리소스에 맞춰 조정하세요.
도입 버전: v3.2.0

`memory_tracker_enable`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: FE 메모리 트래커 서브시스템을 활성화합니다. memory_tracker_enable이 true이면 MemoryUsageTracker가 주기적으로 등록된 메타데이터 모듈을 스캔해 메모리 내 MemoryUsageTracker.MEMORY_USAGE 맵을 갱신하고, 총계를 로그에 남기며, MetricRepo가 메트릭 출력에 메모리 사용량과 객체 수 게이지를 노출하게 합니다. 샘플링 간격은 memory_tracker_interval_seconds로 제어합니다. 이 기능은 메모리 소비의 모니터링과 디버깅에 도움이 되지만 CPU와 I/O 오버헤드, 추가 메트릭 카디널리티를 유발합니다.
도입 버전: v3.2.4

`memory_tracker_interval_seconds`

기본값: 60
타입: Int
단위: 초
변경 가능: 예
설명: FE MemoryUsageTracker 데몬이 FE 프로세스와 등록된 MemoryTrackable 모듈의 메모리 사용량을 폴링·기록하는 간격(초)입니다. memory_tracker_enable이 true이면 트래커가 이 주기로 실행되어 MEMORY_USAGE를 갱신하고 JVM과 추적 모듈 사용량의 집계를 로그에 남깁니다.
도입 버전: v3.2.4

`mysql_nio_backlog_num`

기본값: 1024
타입: Int
단위: -
변경 가능: 아니요
설명: FE 노드의 MySQL 서버가 유지하는 백로그 큐의 길이입니다.
도입 버전: -

`mysql_send_packet_timeout_ms`

기본값: 60000
타입: Long
단위: 밀리초
변경 가능: 예
설명: MySQL 프로토콜 채널의 패킷별 쓰기 타임아웃입니다. 결과 행을 보낼 때 FE 워커가 느린 클라이언트의 TCP recv 버퍼가 비워지기를 기다릴 수 있는 시간을 한계 묶습니다. 이 상한이 없으면 워커가 Selector.select()에서 무기한 블로킹되어 쿼리를 KILL QUERY로 종료할 수 없게 됩니다. 0으로 설정하면 비활성화됩니다(레거시 무한 대기).
도입 버전: v4.1

`mysql_server_version`

기본값: 8.0.33
타입: String
단위: -
변경 가능: 예
설명: 클라이언트에 반환되는 MySQL 서버 버전입니다. 이 파라미터를 수정하면 다음 상황에서 버전 정보가 영향을 받습니다:
1. select version();
2. 핸드셰이크 패킷 버전
3. 전역 변수 version의 값 (show variables like 'version';)
도입 버전: -

`mysql_service_io_threads_num`

기본값: 4
타입: Int
단위: -
변경 가능: 아니요
설명: FE 노드의 MySQL 서버가 I/O 이벤트를 처리하기 위해 실행할 수 있는 최대 스레드 수입니다.
도입 버전: -

`mysql_service_kill_after_disconnect`

기본값: true
타입: Boolean
단위: -
변경 가능: 아니요
설명: MySQL TCP 연결 종료가 감지되었을 때(읽기에서 EOF) 서버가 세션을 처리하는 방식을 제어합니다. true이면 서버가 해당 연결의 실행 중인 쿼리를 즉시 종료하고 즉시 정리를 수행합니다. false이면 연결이 끊겨도 실행 중인 쿼리를 종료하지 않고 대기 중인 요청 작업이 없을 때만 정리를 수행하므로, 클라이언트가 끊긴 뒤에도 장시간 실행되는 쿼리가 계속될 수 있습니다. 참고: TCP keep-alive를 암시하는 짧은 주석과 달리, 이 파라미터는 연결 끊김 이후의 종료 동작만 다룹니다. 고아(orphaned) 쿼리를 종료할지(신뢰할 수 없거나 로드밸런서 뒤의 클라이언트에서는 권장) 끝까지 실행할지에 따라 설정하세요.
도입 버전: -

`mysql_service_nio_enable_keep_alive`

기본값: true
타입: Boolean
단위: -
변경 가능: 아니요
설명: MySQL 연결에 TCP Keep-Alive를 활성화합니다. 로드밸런서 뒤에서 오래 유휴인 연결에 유용합니다.
도입 버전: -

`net_use_ipv6_when_priority_networks_empty`

기본값: false
타입: Boolean
단위: -
변경 가능: 아니요
설명: priority_networks가 지정되지 않았을 때 IPv6 주소를 우선 사용할지 제어하는 불리언 값입니다. true이면 노드를 호스팅하는 서버가 IPv4와 IPv6 주소를 모두 갖고 priority_networks가 지정되지 않은 경우 시스템이 IPv6 주소를 우선 사용하도록 허용합니다.
도입 버전: v3.3.0

`priority_networks`

기본값: 빈 문자열
타입: String
단위: -
변경 가능: 아니요
설명: 여러 IP 주소를 가진 서버의 선택 전략을 선언합니다. 이 파라미터가 지정한 목록에 최대 하나의 IP 주소만 일치해야 한다는 점에 유의하세요. 값은 CIDR 표기법(예: 10.10.10.0/24) 엔트리를 세미콜론(;)으로 구분한 목록입니다. 어떤 IP 주소도 목록의 엔트리와 일치하지 않으면 서버의 가용 IP가 무작위로 선택됩니다. v3.3.0부터 StarRocks는 IPv6 기반 배포를 지원합니다. 서버가 IPv4와 IPv6 주소를 모두 갖고 이 파라미터가 지정되지 않으면 시스템은 기본적으로 IPv4 주소를 사용합니다. 이 동작은 net_use_ipv6_when_priority_networks_empty를 true로 설정해 바꿀 수 있습니다.
도입 버전: -

`proc_profile_cpu_enable`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: 이 항목을 true로 설정하면 백그라운드 ProcProfileCollector가 AsyncProfiler로 CPU 프로파일을 수집해 sys_log_dir/proc_profile 아래 HTML 보고서를 기록합니다. 각 수집 실행은 proc_profile_collect_time_s로 설정된 기간 동안 CPU 스택을 기록하고 Java 스택 깊이로 proc_profile_jstack_depth를 사용합니다. 생성된 프로파일은 압축되며 오래된 파일은 proc_profile_file_retained_days와 proc_profile_file_retained_size_bytes에 따라 정리됩니다. AsyncProfiler는 네이티브 라이브러리(libasyncProfiler.so)가 필요하며, /tmp의 noexec 문제를 피하려고 one.profiler.extractPath가 STARROCKS_HOME_DIR/bin으로 설정됩니다.
도입 버전: v3.2.12

`qe_max_connection`

기본값: 4096
타입: Int
단위: -
변경 가능: 아니요
설명: 모든 사용자가 FE 노드에 맺을 수 있는 최대 연결 수입니다. v3.1.12와 v3.2.7부터 기본값이 1024에서 4096으로 바뀌었습니다.
도입 버전: -

`query_port`

기본값: 9030
타입: Int
단위: -
변경 가능: 아니요
설명: FE 노드의 MySQL 서버가 수신 대기하는 포트입니다.
도입 버전: -

`rpc_port`

기본값: 9020
타입: Int
단위: -
변경 가능: 아니요
설명: FE 노드의 Thrift 서버가 수신 대기하는 포트입니다.
도입 버전: -

`slow_lock_stack_trace_reserve_levels`

기본값: 15
타입: Int
단위: -
변경 가능: 예
설명: StarRocks가 느리거나 점유 중인 락의 락 디버그 정보를 덤프할 때 캡처하고 기록할 스택트레이스 프레임 수를 제어합니다. 이 값은 QueryableReentrantReadWriteLock이 배타 락 소유자, 현재 스레드, 가장 오래된/공유 리더에 대한 JSON을 만들 때 LogUtil.getStackTraceToJsonArray에 전달됩니다. 값을 늘리면 slow-lock이나 교착 상태 문제 진단에 더 많은 문맥을 제공하는 대신 JSON 페이로드가 커지고 스택 캡처의 CPU/메모리가 약간 늘어나고, 줄이면 오버헤드가 줄어듭니다. 참고: 이 상한은 QueryableReentrantReadWriteLock의 스택 덤프 경로에만 적용되며, LockManager의 slow-lock 경로는 전체 스택 깊이를 캡처하고 이 값의 영향을 받지 않습니다. 느린 락만 로깅할 때 리더 엔트리는 slow_lock_threshold_ms로 걸러낼 수 있습니다.
도입 버전: v3.4.0, v3.5.0

`ssl_cipher_blacklist`

기본값: 빈 문자열
타입: String
단위: -
변경 가능: 아니요
설명: IANA 이름으로 SSL 암호 스위트를 블랙리스트에 넣는 정규식 지원 쉼표 구분 목록입니다. 화이트리스트와 블랙리스트가 모두 설정되면 블랙리스트가 우선합니다.
도입 버전: v4.0

`ssl_cipher_whitelist`

기본값: 빈 문자열
타입: String
단위: -
변경 가능: 아니요
설명: IANA 이름으로 SSL 암호 스위트를 화이트리스트에 넣는 정규식 지원 쉼표 구분 목록입니다. 화이트리스트와 블랙리스트가 모두 설정되면 블랙리스트가 우선합니다.
도입 버전: v4.0

`task_runs_concurrency`

기본값: 4
타입: Int
단위: -
변경 가능: 예
설명: 동시 실행 중인 TaskRun 인스턴스의 전역 한도입니다. 현재 실행 개수가 task_runs_concurrency 이상이면 TaskRunScheduler가 새 실행의 스케줄링을 중단하므로 이 값이 스케줄러 전체의 병렬 TaskRun 실행을 상한으로 묶습니다. MVPCTRefreshPartitioner가 TaskRun별 파티션 리프레시 세분도를 계산하는 데도 사용됩니다. 값을 늘리면 병렬성과 리소스 사용이 늘어나고, 줄이면 동시성이 낮아지고 실행당 파티션 리프레시가 커집니다. 스케줄링을 의도적으로 끄려는 게 아니라면 0이나 음수로 두지 마세요. 0(또는 음수)은 TaskRunScheduler가 새 TaskRun을 스케줄하지 못하게 만듭니다.
도입 버전: v3.2.0

`task_runs_queue_length`

기본값: 500
타입: Int
단위: -
변경 가능: 예
설명: 대기 큐에 유지할 pending TaskRun 항목의 최대 개수를 한계 묶습니다. 유효한 pending TaskRun 개수가 task_runs_queue_length 이상이면 TaskRunManager가 새 제출을 거부하며, 병합/수락된 TaskRun이 추가되기 전에 같은 한도가 다시 확인됩니다. 메모리와 스케줄링 백로그의 균형을 맞추려면 값을 조정하세요. 큰 버스트 워크로드에서는 거부를 피하려고 더 크게, 메모리를 한계 묶고 pending 백로그를 줄이려면 더 작게 설정하세요.
도입 버전: v3.2.0

`thrift_backlog_num`

기본값: 1024
타입: Int
단위: -
변경 가능: 아니요
설명: FE 노드의 Thrift 서버가 유지하는 백로그 큐의 길이입니다.
도입 버전: -

`thrift_client_timeout_ms`

기본값: 5000
타입: Int
단위: 밀리초
변경 가능: 아니요
설명: idle 상태의 클라이언트 연결이 타임아웃되기까지의 시간입니다.
도입 버전: -

`thrift_rpc_max_body_size`

기본값: -1
타입: Int
단위: Bytes
변경 가능: 아니요
설명: 서버의 Thrift 프로토콜을 구성할 때 허용되는 Thrift RPC 메시지 본문의 최대 크기(바이트)를 제어합니다(ThriftServer에서 TBinaryProtocol.Factory에 전달). -1이면 한계가 꺼집니다(무제한). 양수를 설정하면 상한이 강제되어 이보다 큰 메시지가 Thrift 계층에서 거부되며, 메모리 사용을 한계 묶고 과대 요청이나 DoS 위험을 완화하는 데 도움이 됩니다. 정당한 요청이 거부되지 않도록 예상 페이로드(대형 구조체나 배치 데이터)에 맞는 크기로 설정하세요.
도입 버전: v3.2.0

`thrift_server_max_worker_threads`

기본값: 4096
타입: Int
단위: -
변경 가능: 예
설명: FE 노드의 Thrift 서버가 지원하는 최대 워커 스레드 수입니다.
도입 버전: -

`thrift_server_queue_size`

기본값: 4096
타입: Int
단위: -
변경 가능: 아니요
설명: 모든 thrift_server_max_worker_threads 워커가 바쁠 때 워커 스레드를 기다릴 수 있는 연결의 개수입니다. 이 값은 대기 큐가 담을 수 있는 양을 한계 묶을 뿐, 실제로 처리할 양을 뜻하지 않습니다. 큐가 가득 찬 뒤 도착한 연결은 재시도 없이 즉시 닫히고, 큐에서 thrift_server_queue_timeout_ms보다 오래 기다린 연결은 워커가 도달하기 전에 처리되지 않고 닫힙니다. 두 경우는 각각 starrocks_fe_thrift_server_rejected_connections_total과 starrocks_fe_thrift_server_expired_connections_total로 별도 집계됩니다.
도입 버전: -

`thrift_server_queue_timeout_ms`

기본값: 0
타입: Long
단위: ms
변경 가능: 예
설명: 워커 스레드가 가져가기 전까지 연결이 Thrift 서버 대기 큐에서 기다릴 수 있는 최대 시간입니다. 이보다 오래 기다린 연결은 호출자가 이미 포기했고 처리하더라도 여전히 기다리는 누군가의 일을 뺏는 것에 불과하다는 가정 아래, 처리되지 않고 닫힙니다. 이 검사가 활성화되면 큐가 아무리 깊어져도 버스트 이후 큐가 비워지는 데 걸리는 시간에도 상한이 걸립니다.

기본값인 0은 검사를 비활성화합니다. 즉, queued된 모든 연결이 얼마나 오래 기다렸든 처리됩니다. 이 가정이 모든 호출자에 들어맞지 않고, queued된 연결이 서버가 읽을 수 있는 마감시간을 갖지 않기 때문에 기본값은 꺼져 있습니다. 호출자가 실제로 쓰는 마감시간은 네 자릿수 범위에 걸쳐 있습니다. 일반 FE 내부 RPC는 thrift_rpc_timeout_ms(10초) 후에 포기하지만, 팔로워에서 리더로 전달된 구문은 세션의 실행 타임아웃에 thrift_rpc_timeout_ms를 더한 만큼(기본 query_timeout 기준 약 310초, 기본 insert_timeout 기준 약 4시간) 기다리고, BE stream-load와 트랜잭션 커밋 RPC는 stream_load_thrift_rpc_timeout_ms(60초)와 로드 자체 timeout_second의 4분의 1 중 더 큰 값만큼 기다립니다. query_timeout, insert_timeout, timeout_second가 모두 사용자가 설정할 수 있고 상한이 없으므로 모든 클러스터에 안전한 고정 값은 없습니다. 회복을 빠르게 하려고 짧게 잡은 타임아웃이, 바로 그 포화 상황에서 클라이언트가 아직 기다리는 전달된 구문을 끊을 수 있습니다.

클러스터별로, 그 클러스터의 클라이언트가 의지하는 가장 큰 마감시간보다 큰 값으로 활성화하세요. 해당 클러스터의 query_timeout과 insert_timeout에서 값을 유도하면 됩니다. 각 드롭은 starrocks_fe_thrift_server_expired_connections_total에 집계되고 속도 제한된 WARN이 피어 이름과 함께 보고합니다. starrocks_fe_thrift_server_queue_wait_ms는 검사 활성화 여부와 관계없이 큐 대기를 보고하므로, 활성화 전에 이 값을 정하는 데 활용하세요.
도입 버전: v4.2.0

메타데이터와 클러스터 관리 (Metadata and cluster management)

`alter_max_worker_queue_size`

기본값: 4096
타입: Int
단위: Tasks
변경 가능: 아니요
설명: alter 서브시스템이 사용하는 내부 워커 스레드 풀 큐의 용량을 제어합니다. AlterHandler에서 alter_max_worker_threads와 함께 ThreadPoolManager.newDaemonCacheThreadPool에 전달됩니다. 대기 중인 alter 작업 수가 alter_max_worker_queue_size를 넘으면 새 제출이 거부되고 RejectedExecutionException이 던져질 수 있습니다(AlterHandler.handleFinishAlterTask 참조). 동시 alter 작업에 허용할 백로그의 양과 메모리 사용의 균형을 맞추려면 이 값을 조정하세요.
도입 버전: v3.2.0

`alter_max_worker_threads`

기본값: 4
타입: Int
단위: 스레드
변경 가능: 아니요
설명: AlterHandler 스레드 풀의 최대 워커 스레드 수를 설정합니다. AlterHandler가 이 값으로 실행기를 만들어 alter 관련 작업을 실행하고 마무리합니다(예: handleFinishAlterTask를 통해 AlterReplicaTask 제출). 이 값은 alter 작업의 동시 실행을 상한으로 묶습니다. 늘리면 병렬성과 리소스 사용이 늘어나고, 줄이면 동시 alter가 제한되어 병목이 될 수 있습니다. 실행기는 alter_max_worker_queue_size와 함께 만들어지며, 핸들러 스케줄링은 alter_scheduler_interval_millisecond를 사용합니다.
도입 버전: v3.2.0

`automated_cluster_snapshot_interval_seconds`

기본값: 600
타입: Int
단위: 초
변경 가능: 예
설명: Automated Cluster Snapshot 작업이 트리거되는 간격입니다.
도입 버전: v3.4.2

`background_refresh_metadata_interval_millis`

기본값: 600000
타입: Int
단위: 밀리초
변경 가능: 예
설명: 연속된 두 번의 Hive 메타데이터 캐시 리프레시 사이의 간격입니다.
도입 버전: v2.5.5

`background_refresh_metadata_time_secs_since_last_access_secs`

기본값: 3600 * 24
타입: Long
단위: 초
변경 가능: 예
설명: Hive 메타데이터 캐시 리프레시 작업의 만료 시간입니다. 접근된 적 있는 Hive catalog에 대해 지정된 시간보다 오래 접근되지 않았으면 StarRocks가 캐시된 메타데이터의 리프레시를 중단합니다. 접근된 적 없는 Hive catalog에 대해서는 캐시된 메타데이터를 리프레시하지 않습니다.
도입 버전: v2.5.5

`bdbje_cleaner_threads`

기본값: 1
타입: Int
단위: -
변경 가능: 아니요
설명: StarRocks 저널이 사용하는 Berkeley DB Java Edition(JE) 환경의 백그라운드 클리너 스레드 수입니다. 이 값은 BDBEnvironment.initConfigs에서 환경 초기화 중 읽혀 Config.bdbje_cleaner_threads로 EnvironmentConfig.CLEANER_THREADS에 적용됩니다. JE 로그 정리와 공간 회수의 병렬성을 제어하며, 늘리면 정리가 빨라지는 대신 포그라운드 작업과의 추가 CPU·I/O 간섭이 생길 수 있습니다. 변경 사항은 BDB 환경이 (재)초기화될 때만 적용되므로 새 값을 적용하려면 FE 재시작이 필요합니다.
도입 버전: v3.2.0

`bdbje_heartbeat_timeout_second`

기본값: 30
타입: Int
단위: 초
변경 가능: 아니요
설명: StarRocks 클러스터에서 리더, 팔로워, 옵저버 FE 사이의 하트비트가 타임아웃되기까지의 시간입니다.
도입 버전: -

`bdbje_lock_timeout_second`

기본값: 1
타입: Int
단위: 초
변경 가능: 아니요
설명: BDB JE 기반 FE에서 락이 타임아웃되기까지의 시간입니다.
도입 버전: -

`bdbje_replay_cost_percent`

기본값: 150
타입: Int
단위: Percent
변경 가능: 아니요
설명: BDB JE 로그에서 트랜잭션을 리플레이하는 상대 비용을 네트워크 복원으로 같은 데이터를 얻는 비용과 비교한 백분율로 설정합니다. 이 값은 기반 JE 복제 파라미터 REPLAY_COST_PERCENT에 전달되며, 일반적으로 리플레이가 네트워크 복원보다 비싸다는 뜻의 >100입니다. 잠재적 리플레이를 위해 정리된 로그 파일을 보존할지 결정할 때 시스템은 리플레이 비용×로그 크기를 네트워크 복원 비용과 비교하고, 네트워크 복원이 더 효율적이라고 판단되면 파일을 제거합니다. 0이면 이 비교 기반 보존이 비활성화됩니다. REP_STREAM_TIMEOUT 내의 복제본에 필요한 로그 파일이나 활성 복제에 필요한 로그 파일은 항상 보존됩니다.
도입 버전: v3.2.0

`bdbje_replica_ack_timeout_second`

기본값: 10
타입: Int
단위: 초
변경 가능: 아니요
설명: 리더 FE에서 팔로워 FE들로 메타데이터를 기록할 때, 리더 FE가 지정된 수의 팔로워 FE로부터 ACK 메시지를 기다릴 수 있는 최대 시간입니다. 단위: 초. 대량의 메타데이터가 기록되는 중이라면 팔로워 FE가 ACK 메시지를 리더에 돌려주기까지 오래 걸려 ACK 타임아웃이 일어날 수 있습니다. 이런 상황에서는 메타데이터 쓰기가 실패하고 FE 프로세스가 종료됩니다. 이런 상황을 예방하려면 이 파라미터 값을 늘리기를 권장합니다.
도입 버전: -

`bdbje_reserved_disk_size`

기본값: 512 * 1024 * 1024 (536870912)
타입: Long
단위: Bytes
변경 가능: 아니요
설명: Berkeley DB JE가 "보호되지 않는"(삭제 가능한) 로그/데이터 파일로 예약할 바이트 수를 한계 묶습니다. StarRocks가 BDBEnvironment에서 이 값을 EnvironmentConfig.RESERVED_DISK로 JE에 전달하며, JE의 내장 기본값은 0(무제한)입니다. StarRocks 기본값(512 MiB)은 JE가 안전한 구식 파일 정리를 할 수 있게 하면서 과도한 디스크 예약을 막습니다. 디스크가 부족한 시스템에서 조정하세요. 줄이면 JE가 더 많은 파일을 더 빨리 회수하고, 늘리면 JE가 더 많은 예약 공간을 유지합니다. 변경 사항을 적용하려면 프로세스 재시작이 필요합니다.
도입 버전: v3.2.0

`bdbje_reset_election_group`

기본값: false
타입: String
단위: -
변경 가능: 아니요
설명: BDBJE 복제 그룹을 리셋할지 여부입니다. 이 파라미터를 TRUE로 설정하면 FE가 BDBJE 복제 그룹을 리셋하고(즉, 모든 electable FE 노드의 정보를 제거하고) 리더 FE로 시작합니다. 리셋 후 이 FE가 클러스터의 유일한 멤버가 되고, 다른 FE는 ALTER SYSTEM ADD/DROP FOLLOWER/OBSERVER 'xxx'로 이 클러스터에 재가입할 수 있습니다. 대부분의 팔로워 FE 데이터가 손상되어 리더 FE를 선출할 수 없을 때만 이 설정을 사용하세요. reset_election_group은 metadata_failure_recovery를 대체합니다.
도입 버전: -

`black_host_connect_failures_within_time`

기본값: 5
타입: Int
단위: -
변경 가능: 예
설명: 블랙리스트에 올라간 BE 노드에 허용되는 연결 실패 임계값입니다. BE 노드가 자동으로 BE 블랙리스트에 추가되면 StarRocks가 연결성을 평가해 BE 블랙리스트에서 제거할 수 있는지 판단합니다. black_host_history_sec 내에서 블랙리스트에 올라간 BE 노드의 연결 실패 수가 black_host_connect_failures_within_time이 설정한 임계값보다 적을 때만 BE 블랙리스트에서 제거될 수 있습니다.
도입 버전: v3.3.0

`black_host_history_sec`

기본값: 2 * 60
타입: Int
단위: 초
변경 가능: 예
설명: BE 블랙리스트에 있는 BE 노드의 과거 연결 실패 이력을 유지하는 기간입니다. BE 노드가 자동으로 BE 블랙리스트에 추가되면 StarRocks가 연결성을 평가해 BE 블랙리스트에서 제거할 수 있는지 판단합니다. black_host_history_sec 내에서 블랙리스트에 올라간 BE 노드의 연결 실패 수가 black_host_connect_failures_within_time이 설정한 임계값보다 적을 때만 BE 블랙리스트에서 제거될 수 있습니다.
도입 버전: v3.3.0

`brpc_connection_pool_size`

기본값: 16
타입: Int
단위: Connections
변경 가능: 아니요
설명: FE의 BrpcProxy가 엔드포인트별로 사용하는 풀링된 BRPC 연결의 최대 개수입니다. 이 값은 setMaxTotoal과 setMaxIdleSize로 RpcClientOptions에 적용되며, 각 요청이 풀에서 연결을 빌려야 하므로 동시에 나가는 BRPC 요청 수를 직접 한계 묶습니다. 높은 동시성 시나리오에서는 요청 큐잉을 피하려고 이 값을 늘리세요. 늘리면 소켓과 메모리 사용이 늘고 원격 서버 부하도 커질 수 있습니다. 조정할 때는 brpc_idle_wait_max_time, brpc_short_connection, brpc_inner_reuse_pool, brpc_reuse_addr, brpc_min_evictable_idle_time_ms 같은 관련 설정을 함께 고려하세요. 이 값 변경은 핫 리로드가 불가능하며 재시작이 필요합니다.
도입 버전: v3.2.0

`brpc_short_connection`

기본값: false
타입: boolean
단위: -
변경 가능: 아니요
설명: 기반 brpc RpcClient가 단기(short-lived) 연결을 사용할지 제어합니다. 켜면(true) RpcClientOptions.setShortConnection이 설정되고 요청이 완료된 뒤 연결이 닫혀 장기 소켓 수가 줄어드는 대신 연결 설정 오버헤드와 지연이 늘어납니다. 끄면(false, 기본값) 영속 연결과 연결 풀링이 사용됩니다. 이 옵션은 연결 풀 동작에 영향을 주므로 brpc_connection_pool_size, brpc_idle_wait_max_time, brpc_min_evictable_idle_time_ms, brpc_reuse_addr, brpc_inner_reuse_pool과 함께 고려하세요. 일반적인 고처리량 배포에서는 꺼 두고, 소켓 수명을 제한하거나 네트워크 정책이 단기 연결을 요구할 때만 켜세요.
도입 버전: v3.3.11, v3.4.1, v3.5.0

`catalog_try_lock_timeout_ms`

기본값: 5000
타입: Long
단위: 밀리초
변경 가능: 예
설명: 전역 락을 획득하는 타임아웃 시간입니다.
도입 버전: -

`checkpoint_only_on_leader`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: true이면 CheckpointController가 체크포인트 워커로 리더 FE만 선택하고, false이면 컨트롤러가 어떤 FE든 선택할 수 있으며 힙 사용률이 낮은 노드를 선호합니다. false일 때 워커는 최근 실패 시각과 heapUsedPercent 순으로 정렬됩니다(리더가 선택되지 않도록 무한대 사용률로 취급). 클러스터 스냅샷 메타데이터가 필요한 작업에 대해서는 이 플래그와 무관하게 컨트롤러가 이미 리더 선택을 강제합니다. true로 켜면 체크포인트 작업이 리더에 집중되어(단순하지만 리더의 CPU/메모리와 네트워크 부하가 늘어남) false로 두면 체크포인트 부하가 부하가 덜한 FE들에 분산됩니다. 이 설정은 워커 선택에 영향을 주며 checkpoint_timeout_seconds 같은 타임아웃과 thrift_rpc_timeout_ms 같은 RPC 설정과 상호작용합니다.
도입 버전: v3.4.0, v3.5.0

`checkpoint_timeout_seconds`

기본값: 24 * 3600
타입: Long
단위: 초
변경 가능: 예
설명: 리더의 CheckpointController가 체크포인트 워커가 체크포인트를 완료하기를 기다리는 최대 시간(초)입니다. 컨트롤러가 이 값을 나노초로 변환해 워커 결과 큐를 폴링하며, 이 타임아웃 내에 성공 완료를 받지 못하면 체크포인트는 실패로 간주되고 createImage가 실패를 반환합니다. 값을 늘리면 오래 걸리는 체크포인트를 수용하지만 실패 감지와 이후 이미지 전파가 늦어지고, 줄이면 페일오버/재시도가 빨라지지만 느린 워커에서 오탐 타임아웃이 생길 수 있습니다. 이 설정은 체크포인트 생성 중 CheckpointController의 대기 기간만 제어하며 워커의 내부 체크포인팅 동작은 바꾸지 않습니다.
도입 버전: v3.4.0, v3.5.0

`db_used_data_quota_update_interval_secs`

기본값: 300
타입: Int
단위: 초
변경 가능: 예
설명: 데이터베이스 사용 데이터 쿼터가 갱신되는 간격입니다. StarRocks가 모든 데이터베이스의 사용 데이터 쿼터를 주기적으로 갱신해 저장소 소비를 추적합니다. 이 값은 쿼터 강제와 메트릭 수집에 사용됩니다. 과도한 시스템 부하를 막으려고 허용되는 최소 간격은 30초이며, 30보다 작은 값은 거부됩니다.
도입 버전: -

`drop_backend_after_decommission`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: BE가 decommission된 뒤 BE를 삭제할지 여부입니다. TRUE는 decommission 직후 BE를 삭제하고, FALSE는 decommission 후 BE를 삭제하지 않습니다.
도입 버전: -

`edit_log_port`

기본값: 9010
타입: Int
단위: -
변경 가능: 아니요
설명: 클러스터에서 Leader, Follower, Observer FE 사이 통신에 사용되는 포트입니다.
도입 버전: -

`edit_log_roll_num`

기본값: 50000
타입: Int
단위: -
변경 가능: 예
설명: 이 로그 엔트리들을 위한 로그 파일이 생성되기 전까지 기록할 수 있는 메타데이터 로그 엔트리의 최대 개수입니다. 이 파라미터는 로그 파일의 크기를 제어하는 데 사용되며, 새 로그 파일은 BDBJE 데이터베이스에 기록됩니다.
도입 버전: -

`edit_log_type`

기본값: BDB
타입: String
단위: -
변경 가능: 아니요
설명: 생성할 수 있는 edit log의 유형입니다. 값은 BDB로 설정하세요.
도입 버전: -

`enable_background_refresh_connector_metadata`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: 주기적인 Hive 메타데이터 캐시 리프레시를 활성화할지 여부입니다. 활성화하면 StarRocks가 Hive 클러스터의 metastore(Hive Metastore 또는 AWS Glue)를 폴링해 자주 접근하는 Hive catalog의 캐시된 메타데이터를 리프레시하여 데이터 변화를 인지합니다. true는 Hive 메타데이터 캐시 리프레시를 켜고, false는 끕니다.
도입 버전: v2.5.5

`refresh_other_fe_dispatch_executor_thread_num`

기본값: 4
타입: Integer
단위: -
변경 가능: 예
설명: 비동기 "refresh other FE" 작업을 위한 FE 전역 디스패치 실행기의 스레드 수입니다. 이 스레드들은 커넥터 쓰기 경로에서 백그라운드 리프레시 작업을 스케줄링할 뿐, 피어 FE로 리프레시 RPC를 직접 보내지 않습니다. 재시작 없이 실행 중인 FE에 변경 사항이 적용됩니다.
도입 버전: -

`refresh_other_fe_rpc_executor_thread_num`

기본값: 4
타입: Integer
단위: -
변경 가능: 예
설명: "refresh other FE" 팬아웃을 위한 FE 전역 RPC 실행기의 스레드 수입니다. 이 실행기는 동기·비동기 외부 테이블 리프레시 흐름 모두에 대해 피어 FE로 보내는 동시 리프레시 RPC 수를 한계 묶습니다. 재시작 없이 실행 중인 FE에 변경 사항이 적용됩니다.
도입 버전: -

`enable_collect_query_detail_info`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: 쿼리의 프로파일을 수집할지 여부입니다. 이 파라미터를 TRUE로 설정하면 시스템이 쿼리의 프로파일을 수집하고, FALSE로 설정하면 수집하지 않습니다.
도입 버전: -

`enable_create_partial_partition_in_batch`

기본값: false
타입: boolean
단위: -
변경 가능: 예
설명: 이 항목이 false(기본값)이면 StarRocks가 배치로 생성된 range 파티션이 표준 시간 단위 경계에 정렬되도록 강제합니다. 정렬되지 않은 range는 구멍 생성을 피하려고 거부됩니다. 이 항목을 true로 설정하면 정렬 검사가 비활성화되어 배치로 부분적(비표준) 파티션을 만들 수 있으며, 이는 갭이나 잘못 정렬된 파티션 range를 만들어 낼 수 있습니다. 부분 배치 파티션이 정말 필요하고 그에 따른 위험을 감수할 때만 true로 설정하세요.
도입 버전: v3.2.0

`enable_internal_sql`

기본값: true
타입: Boolean
단위: -
변경 가능: 아니요
설명: 이 항목을 true로 설정하면 내부 컴포넌트(예: SimpleExecutor)가 실행한 내부 SQL 구문이 보존되어 내부 감사나 로그 메시지에 기록되고(enable_sql_desensitize_in_log가 설정되어 있으면 추가 비식별화 가능), false로 설정하면 내부 SQL 텍스트가 억제됩니다. 즉 포맷 코드(SimpleExecutor.formatSQL)가 "?"를 반환하고 실제 구문이 내부 감사나 로그 메시지로 나가지 않습니다. 이 구성은 내부 구문의 실행 의미론을 바꾸지 않으며, 프라이버시나 보안을 위해 내부 SQL의 로깅과 가시성만 제어합니다.
도입 버전: -

`enable_legacy_compatibility_for_replication`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: 복제를 위한 레거시 호환성(Legacy Compatibility for Replication)을 활성화할지 여부입니다. StarRocks는 구버전과 신버전 사이에서 다르게 동작할 수 있어 클러스터 간 데이터 마이그레이션 중 문제를 일으킬 수 있습니다. 따라서 데이터 마이그레이션 전에 대상 클러스터에서 레거시 호환성을 활성화하고, 마이그레이션이 완료된 뒤에는 비활성화해야 합니다. true는 이 모드를 켭니다.
도입 버전: v3.1.10, v3.2.6

`enable_show_materialized_views_include_all_task_runs`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: SHOW MATERIALIZED VIEWS 명령에 TaskRuns가 어떻게 반환되는지 제어합니다. 이 항목이 false이면 StarRocks가 작업별 가장 최신 TaskRun만 반환합니다(하위 호환을 위한 레거시 동작). true(기본값)이면 TaskManager가 같은 시작 TaskRun ID를 공유하는 경우에 한해서만(예: 같은 작업에 속하는 경우) 같은 작업의 추가 TaskRuns를 포함할 수 있어, 무관한 중복 실행이 보이지 않게 하면서 한 작업에 묶인 여러 상태를 보여줄 수 있습니다. 단일 실행 출력으로 되돌리거나 디버깅·모니터링을 위해 다중 실행 작업 이력을 드러내려면 이 항목을 false로 설정하세요.
도입 버전: v3.3.0, v3.4.0, v3.5.0

`enable_statistics_collect_profile`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: 통계 쿼리에 대한 프로파일을 생성할지 여부입니다. 이 항목을 true로 설정하면 StarRocks가 시스템 통계에 대한 쿼리의 쿼리 프로파일을 생성하도록 허용할 수 있습니다.
도입 버전: v3.1.5

`enable_table_name_case_insensitive`

기본값: false
타입: Boolean
단위: -
변경 가능: 아니요
설명: catalog 이름, 데이터베이스 이름, 테이블 이름, 뷰 이름, materialized view 이름에 대소문자 구분 없는 처리를 활성화할지 여부입니다. 기본적으로 이 기능은 꺼져 있고 이런 이름은 대소문자를 구분합니다. 활성화하면 StarRocks가 이런 이름을 소문자로 저장하고 쿼리와 쓰기(DDL/DML) 처리 양쪽에서 모든 이름을 강제로 소문자로 변환합니다. 이 기능은 클러스터를 생성할 때만 활성화할 수 있습니다. 특별하고 명확히 이해된 이유가 없다면 꺼 두기를 강하게 권장합니다. 이유는 다음과 같습니다:
- 외부 테이블과 외부 catalog를 사용 불가로 만들 수 있습니다. 외부 catalog 서비스마다 명명과 대소문자 구분 규칙이 다릅니다. 외부 스키마, 데이터베이스, 테이블 이름이 이미 소문자가 아니라면 StarRocks가 커넥터에 전달하기 전에 SQL에서 이름을 소문자로 바꾼 뒤 소스에 존재하지 않는 이름을 조회하므로 쿼리가 "not found" 오류로 실패합니다.
- 클러스터 생성 후에는 바꿀 수 없습니다. 클러스터가 시작된 뒤에는 어떤 방법으로도 값을 수정할 수 없고, 수정을 시도하면 오류가 발생하며, 클러스터를 처음 시작했을 때의 값과 일치하지 않으면 FE가 시작에 실패합니다.
- 접근하려는 모든 외부 데이터 소스의 이름을 포함해 모든 객체 이름이 이미 소문자임을 확신하는 새 클러스터에서만 이 기능을 활성화하세요.
도입 버전: v4.0

`enable_task_history_archive`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: 활성화하면 완료된 task-run 레코드가 영속적인 task-run 이력 테이블로 아카이브되고 edit log에 기록되어, 조회(예: lookupHistory, lookupHistoryByTaskNames, lookupLastJobOfTasks)에 아카이브된 결과가 포함됩니다. 아카이빙은 FE 리더가 수행하며 단위 테스트 중에는 건너뜁니다(FeConstants.runningUnitTest). 활성화하면 인메모리 만료와 강제 GC 경로가 우회되어(removeExpiredRuns와 forceGC에서 코드가 조기 반환) 보존/축출이 task_runs_ttl_second와 task_runs_max_history_number 대신 영속 아카이브가 담당합니다. 비활성화하면 이력이 메모리에 머물고 이 구성들로 정리됩니다.
도입 버전: v3.3.1, v3.4.0, v3.5.0

`enable_task_run_fe_evaluation`

기본값: true
타입: Boolean
단위: -
변경 가능: 예
설명: 활성화하면 FE가 TaskRunsSystemTable.supportFeEvaluation에서 시스템 테이블 task_runs에 대해 로컬 평가를 수행합니다. FE 측 평가는 컬럼과 상수를 비교하는 conjunctive equality 술어에만 허용되며 QUERY_ID와 TASK_NAME 컬럼으로 한정됩니다. 켜면 더 넓은 스캔이나 추가 원격 처리를 피해 표적 조회의 성능이 좋아집니다. 끄면 플래너가 task_runs에 대한 FE 평가를 건너뛰게 되어 술어 프루닝이 줄고 그 필터의 쿼리 지연에 영향을 줄 수 있습니다.
도입 버전: v3.3.13, v3.4.3, v3.5.0

`heartbeat_mgr_blocking_queue_size`

기본값: 1024
타입: Int
단위: -
변경 가능: 아니요
설명: Heartbeat Manager가 실행하는 하트비트 작업을 저장하는 블로킹 큐의 크기입니다.
도입 버전: -

`heartbeat_mgr_threads_num`

기본값: 8
타입: Int
단위: -
변경 가능: 아니요
설명: Heartbeat Manager가 하트비트 작업을 실행하기 위해 실행할 수 있는 스레드 수입니다.
도입 버전: -

`ignore_materialized_view_error`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: FE가 materialized view 오류로 생긴 메타데이터 예외를 무시할지 여부입니다. materialized view 오류로 생긴 메타데이터 예외 때문에 FE가 시작에 실패한다면, 이 파라미터를 true로 설정해 FE가 예외를 무시하도록 허용할 수 있습니다.
도입 버전: v2.5.10

`ignore_meta_check`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: 리더가 아닌 FE가 리더 FE의 메타데이터 갭을 무시할지 여부입니다. 값이 TRUE이면 리더가 아닌 FE가 리더 FE의 메타데이터 갭을 무시하고 데이터 읽기 서비스를 계속 제공합니다. 이 파라미터는 리더 FE를 오래 중단해도 데이터 읽기 서비스가 계속되도록 보장합니다. 값이 FALSE이면 리더가 아닌 FE가 리더 FE의 메타데이터 갭을 무시하지 않고 데이터 읽기 서비스를 중단합니다.
도입 버전: -

`ignore_task_run_history_replay_error`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: StarRocks가 information_schema.task_runs의 TaskRun 이력 행을 역직렬화할 때, 손상되거나 잘못된 JSON 행은 보통 역직렬화가 경고를 기록하고 RuntimeException을 던지게 만듭니다. 이 항목을 true로 설정하면 시스템이 역직렬화 오류를 잡아 잘못된 레코드를 건너뛰고 쿼리를 실패시키는 대신 나머지 행을 계속 처리합니다. 이렇게 하면 information_schema.task_runs 쿼리가 _statistics_.task_run_history 테이블의 잘못된 엔트리에 관용적이 됩니다. 켜면 명시적 오류 대신 손상된 이력 레코드가 조용히 버려진다는 점(잠재적 데이터 손실)에 유의하세요.
도입 버전: v3.3.3, v3.4.0, v3.5.0

`lock_checker_interval_second`

기본값: 30
타입: long
단위: 초
변경 가능: 예
설명: LockChecker FE 데몬("deadlock-checker"라는 이름)의 실행 간격(초)입니다. 이 데몬은 교착 상태 감지와 slow-lock 스캔을 수행하며, 설정된 값은 밀리초 타이머를 설정하려고 1000이 곱해집니다. 값을 줄이면 감지 지연이 짧아지지만 스케줄링과 CPU 오버헤드가 늘어나고, 늘리면 오버헤드가 줄지만 감지와 slow-lock 보고가 늦어집니다. 데몬이 실행마다 간격을 재설정하므로 변경 사항은 런타임에 적용됩니다. 이 설정은 교착 상태 검사를 켜는 lock_checker_enable_deadlock_check와 slow lock의 기준을 정의하는 slow_lock_threshold_ms와 상호작용합니다.
도입 버전: v3.2.0

`lock_manager_lock_table_num`

기본값: 256
타입: Int
단위: -
변경 가능: 아니요
설명: Lock Manager가 메타데이터 락을 샤딩하는 해시 버킷, 즉 lock table의 개수입니다. 각 리소스는 리소스 ID로 하나의 버킷에 매핑되고 각 버킷은 자체 뮤텍스로 보호되므로, 값을 크게 하면 무관한 리소스를 다루는 락 사용자 사이의 경합이 줄어드는 대신 메모리가 조금 늘어납니다. 이 값은 Lock Manager가 생성될 때 한 번 읽히므로 변경 사항은 FE 재시작 후에만 적용됩니다. 기본값은 v4.1.0, v4.0.1, v3.5.8부터 32에서 256으로 바뀌었습니다.
도입 버전: v3.3.0

`master_sync_policy`

기본값: SYNC
타입: String
단위: -
변경 가능: 아니요
설명: 리더 FE가 디스크에 로그를 플러시하는 정책입니다. 이 파라미터는 현재 FE가 리더 FE일 때만 유효합니다. 유효한 값:
- SYNC: 트랜잭션이 커밋될 때 로그 엔트리가 생성되고 동시에 디스크로 플러시됩니다.
- NO_SYNC: 트랜잭션이 커밋될 때 로그 엔트리의 생성과 플러시가 동시에 일어나지 않습니다.
- WRITE_NO_SYNC: 트랜잭션이 커밋될 때 로그 엔트리가 동시에 생성되지만 디스크로 플러시되지는 않습니다.
팔로워 FE를 하나만 배포했다면 이 파라미터를 SYNC로 설정하기를 권장합니다. 팔로워 FE를 셋 이상 배포했다면 이 파라미터와 replica_sync_policy를 모두 WRITE_NO_SYNC로 설정하기를 권장합니다.
도입 버전: -

`max_bdbje_clock_delta_ms`

기본값: 5000
타입: Long
단위: 밀리초
변경 가능: 아니요
설명: StarRocks 클러스터에서 리더 FE와 팔로워 또는 옵저버 FE 사이에 허용되는 최대 클록 오프셋입니다.
도입 버전: -

`meta_delay_toleration_second`

기본값: 300
타입: Int
단위: 초
변경 가능: 예
설명: 팔로워와 옵저버 FE의 메타데이터가 리더 FE의 메타데이터보다 뒤처질 수 있는 최대 기간입니다. 단위: 초. 이 기간을 초과하면 리더가 아닌 FE가 서비스 제공을 중단합니다.
도입 버전: -

`meta_freshness_check_interval_ms`

기본값: 1000
타입: Long
단위: 밀리초
변경 가능: 예
설명: Follower 또는 Observer FE가 meta_delay_toleration_second로 정의된 기준에 따라 자신의 메타데이터가 아직 읽기를 제공할 만큼 신선한지 다시 평가하는 간격입니다. [10, 5000] 범위를 벗어난 값은 클램프됩니다. 이 검사는 메타데이터 리플레이 스레드가 아니라 전용 스레드에서 실행되므로, 단일 저널 엔트리를 적용하는 데 오래 걸리는 동안(예: 리플레이 작업이 데이터베이스 락을 기다리는 동안)에도 노드가 오래된 메타데이터로 서비스를 중단할 수 있습니다.
도입 버전: v4.2

`metadata_replay_stuck_warn_threshold_second`

기본값: 30
타입: Long
단위: 초
변경 가능: 예
설명: 이 기간보다 오래 적용 중인 메타데이터 저널 엔트리는 fe.log에 stuck replay로 보고되며, 리플레이 스레드의 스택이 함께 남어 메타데이터 리플레이를 막는 원인을 찾을 수 있습니다. 이 항목을 0으로 설정하면 보고가 비활성화됩니다.
도입 버전: v4.2

`meta_dir`

기본값: StarRocksFE.STARROCKS_HOME_DIR + "/meta"
타입: String
단위: -
변경 가능: 아니요
설명: 메타데이터를 저장하는 디렉터리입니다.
도입 버전: -

`metadata_ignore_unknown_operation_type`

기본값: false
타입: Boolean
단위: -
변경 가능: 예
설명: 알 수 없는 로그 ID를 무시할지 여부입니다. FE를 롤백하면 구버전 FE가 일부 로그 ID를 인식하지 못할 수 있습니다. 값이 TRUE이면 FE가 알 수 없는 로그 ID를 무시하고, FALSE이면 FE가 종료됩니다.
도입 버전: -

`profile_info_format`

기본값: default
타입: String
단위: -
변경 가능: 예
설명: 시스템이 출력하는 Profile의 형식입니다. 유효한 값: default와 json. default로 설정하면 Profile이 기본 형식이 되고, json으로 설정하면 시스템이 JSON 형식으로 Profile을 출력합니다.
도입 버전: v2.5

`replica_ack_policy`

기본값: SIMPLE_MAJORITY
타입: String
단위: -
변경 가능: 아니요
설명: 로그 엔트리가 유효하다고 간주되는 정책입니다. 기본값 SIMPLE_MAJORITY는 대다수의 팔로워 FE가 ACK 메시지를 반환하면 로그 엔트리가 유효하다고 간주한다는 뜻입니다.
도입 버전: -

`replica_sync_policy`

기본값: SYNC
타입: String
단위: -
변경 가능: 아니요
설명: 팔로워 FE가 디스크에 로그를 플러시하는 정책입니다. 이 파라미터는 현재 FE가 팔로워 FE일 때만 유효합니다. 유효한 값:
- SYNC: 트랜잭션이 커밋될 때 로그 엔트리가 생성되고 동시에 디스크로 플러시됩니다.
- NO_SYNC: 트랜잭션이 커밋될 때 로그 엔트리의 생성과 플러시가 동시에 일어나지 않습니다.
- WRITE_NO_SYNC: 트랜잭션이 커밋될 때 로그 엔트리가 동시에 생성되지만 디스크로 플러시되지는 않습니다.
도입 버전: -

`start_with_incomplete_meta`

기본값: false
타입: boolean
단위: -
변경 가능: 아니요
설명: true이면 이미지 데이터가 존재하지만 Berkeley DB JE(BDB) 로그 파일이 없거나 손상된 경우에도 FE가 시작을 허용합니다. MetaHelper.checkMetaDir()가 이 플래그로 해당 BDB 로그 없이 이미지에서 시작하는 것을 막는 안전 검사를 우회하는데, 이렇게 시작하면 오래되거나 일관성 없는 메타데이터가 생길 수 있으므로 긴급 복구에만 사용해야 합니다. RestoreClusterSnapshotMgr는 클러스터 스냅샷 복원 중에 일시적으로 이 플래그를 true로 설정했다가 되돌리며, 그 컴포넌트는 복원 중 bdbje_reset_election_group도 함께 토글합니다. 정상 운영에서는 켜지 마세요. BDB 데이터가 손상되어 복구할 때나 이미지 기반 스냅샷을 명시적으로 복원할 때만 켜세요.
도입 버전: v3.2.0

`table_keeper_interval_second`

기본값: 30
타입: Int
단위: 초
변경 가능: 예
설명: TableKeeper 데몬의 실행 간격(초)입니다. TableKeeperDaemon이 이 값(1000을 곱해)으로 내부 타이머를 설정하고, 이력 테이블이 존재하는지 확인하고, 테이블 속성(복제 수)을 바로잡고, 파티션 TTL을 갱신하는 keeper 작업을 주기적으로 실행합니다. 데몬은 리더 노드에서만 작업을 수행하며 table_keeper_interval_second가 바뀌면 setInterval로 런타임 간격을 갱신합니다. 스케줄링 빈도와 부하를 줄이려면 늘리고, 없거나 오래된 이력 테이블에 더 빨리 반응하려면 줄이세요.
도입 버전: v3.3.1, v3.4.0, v3.5.0

`task_runs_ttl_second`

기본값: 7 * 24 * 3600
타입: Int
단위: 초
변경 가능: 예
설명: task run 이력의 time-to-live(TTL)를 제어합니다. 값을 낮추면 이력 보존이 짧아지고 메모리/디스크 사용이 줄어들고, 높이면 이력을 더 오래 유지하는 대신 리소스 사용이 늘어납니다. 예측 가능한 보존과 저장 동작을 위해 task_runs_max_history_number, enable_task_history_archive와 함께 조정하세요.
도입 버전: v3.2.0

`task_ttl_second`

기본값: 24 * 3600
타입: Int
단위: 초
변경 가능: 예
설명: 작업(task)의 time-to-live(TTL)입니다. 수동 작업(스케줄이 설정되지 않은 경우)에 대해 TaskBuilder가 이 값으로 작업의 expireTime을 계산합니다(expireTime = now + task_ttl_second * 1000L). TaskRun도 실행의 타임아웃을 계산할 때 이 값을 상한으로 사용하며, 실제 실행 타임아웃은 min(task_runs_timeout_second, task_runs_ttl_second, task_ttl_second)입니다. 이 값을 조정하면 수동으로 만든 작업이 유효한 기간이 바뀌고, 간접적으로 task run의 최대 허용 실행 시간을 한계 묶을 수 있습니다.
도입 버전: v3.2.0

`thrift_rpc_retry_times`

기본값: 3
타입: Int
단위: -
변경 가능: 예
설명: Thrift RPC 호출이 시도할 총 횟수를 제어합니다. 이 값은 ThriftRPCRequestExecutor(와 NodeMgr, VariableMgr 같은 호출자)가 재시도의 루프 횟수로 사용합니다. 즉, 3이면 초기 시도를 포함해 최대 세 번까지 시도할 수 있습니다. TTransportException이 발생하면 실행기가 연결을 다시 열고 이 횟수까지 재시도하며, 원인이 SocketTimeoutException이거나 재열기가 실패하면 재시도하지 않습니다. 각 시도는 thrift_rpc_timeout_ms가 설정한 시도별 타임아웃의 영향을 받습니다. 값을 늘리면 일시적 연결 실패에 대한 복원력이 좋아지지만 전체 RPC 지연과 리소스 사용이 늘어날 수 있습니다.
도입 버전: v3.2.0

`thrift_rpc_strict_mode`

기본값: true
타입: Boolean
단위: -
변경 가능: 아니요
설명: Thrift 서버가 사용하는 TBinaryProtocol의 "strict read" 모드를 제어합니다. 이 값은 Thrift 서버 스택에서 org.apache.thrift.protocol.TBinaryProtocol.Factory의 첫 번째 인자로 전달되며 들어오는 Thrift 메시지의 파싱과 검증 방식에 영향을 줍니다. true(기본값)이면 서버가 엄격한 Thrift 인코딩/버전 검사를 강제하고 설정된 thrift_rpc_max_body_size 한계를 따르며, false이면 서버가 비엄격(레거시/관대) 메시지 형식을 받아들여 구형 클라이언트와의 호환성은 좋아지지만 일부 프로토콜 검증을 우회할 수 있습니다. 변경 가능하지 않고 상호운용성과 파싱 안전성에 영향을 주므로 실행 중인 클러스터에서 바꿀 때 주의하세요.
도입 버전: v3.2.0

`thrift_rpc_timeout_ms`

기본값: 10000
타입: Int
단위: 밀리초
변경 가능: 예
설명: Thrift RPC 호출의 기본 네트워크/소켓 타임아웃으로 쓰이는 시간(밀리초)입니다. ThriftConnectionPool에서(프론트엔드 풀과 백엔드 풀이 사용) Thrift 클라이언트를 만들 때 TSocket에 전달되며, ConfigBase, LeaderOpExecutor, GlobalStateMgr, NodeMgr, VariableMgr, CheckpointWorker 같은 곳에서 RPC 호출 타임아웃을 계산할 때 작업의 실행 타임아웃에도 더해집니다(예: ExecTimeout*1000 + thrift_rpc_timeout_ms). 값을 늘리면 RPC 호출이 더 긴 네트워크나 원격 처리 지연을 견디고, 줄이면 느린 네트워크에서 더 빨리 페일오버됩니다. 이 값을 바꾸면 Thrift RPC를 수행하는 FE 코드 경로 전반의 연결 생성과 요청 마감시간에 영향을 줍니다.
도입 버전: v3.2.0

`txn_latency_metric_report_groups`

기본값: 빈 문자열
타입: String
단위: -
변경 가능: 예
설명: 보고할 트랜잭션 지연 메트릭 그룹의 쉼표 구분 목록입니다. 로드 유형은 모니터링을 위해 논리 그룹으로 분류됩니다. 그룹이 활성화되면 그 이름이 트랜잭션 메트릭에 'type' 레이블로 추가됩니다. 유효한 값: stream_load, routine_load, broker_load, insert, compaction(shared-data 클러스터에서만 사용 가능). 예: "stream_load,routine_load".
도입 버전: v4.0

`txn_rollback_limit`

기본값: 100
타입: Int
단위: -
변경 가능: 아니요
설명: 롤백할 수 있는 트랜잭션의 최대 개수입니다.
도입 버전: -

더 알아보기 (Learn more)

ADMIN SHOW CONFIG — 파라미터별 IsMutable 여부 확인 방법과 반환 필드의 상세 설명을 볼 수 있습니다.
ADMIN SET FRONTEND CONFIG — 동적 파라미터를 SQL로 바꾸는 방법을 다룹니다. 재시작 후에는 fe.conf 값으로 복원되므로 영구 변경은 fe.conf 수정을 권장합니다.
llms.txt — StarRocks 문서 전체의 마크다운 인덱스로, 다른 FE/BE 구성 문서를 찾아볼 때 유용합니다.
이 페이지 외에도 같은 디렉터리의 다른 FE 파라미터 페이지에서 로깅·서버·메타데이터 외 영역(예: 쿼리 실행기, 로드, 스토리지)의 구성 항목을 확인할 수 있습니다.