@Rocky starrocks cluster 4.1.1 버젼의 shared data 모드로 k8s 환경에 fe / cn 구성으로 활용 중입니다 fe는 3개로 구성되어있으며 (leader fe 는 fe-2) cluster snapshot 을 활성화 하여 10분마다 cluster snapshot 정보를 s3 에 latest 정보를 보관하고 있습니다 log 확인 중 다음 에러가 발생하면서 cluster snapshot 이 실패 하고 있는데 확인 가능한가요? • finish checkpoint successfully, journalId : 2429034 • Server returned HTTP response code : 400 for URL : http://{cluster name}-fe-0.svc8083/image?version=2429034&subdir=&image_format_version=v2

References • administration/cluster_snapshot.md • faq/shared_data_faq.md • deployment/shared_data/s3.md

@Rocky fe-1, fe-2 에서 cluster snapshot 생성할 때는 정상처리되고 cluster_shapshot_job 에서도 finished 되지만 fe-0 에서서 cluster snapshot 생성할때 fail 이 발생합니다

StarRocks 4.1.1 버전의 Shared Data 모드에서 Cluster Snapshot 작업 중 발생하는 HTTP 400(Bad Request) 에러는, 이미지 동기화 또는 스냅샷 생성을 위한 URL 요청 형식이 잘못되었을 때 주로 발생합니다. 제공해주신 로그와 에러 메시지를 분석한 결과, 가장 유력한 원인과 확인 사항은 다음과 같습니다. 1. URL 구성 오류 (Extra Colon) 에러 메시지에 포함된 URL을 자세히 보시면 포트 번호 뒤에 불필요한 콜론(

:

)이 포함되어 있습니다. * 문제가 된 URL:

http://...-fe-0.svc:8083:/image?version=...

* 정상적인 URL:

http://...-fe-0.svc:8083/image?version=...

`8083:/image`와 같이 포트와 경로 사이에 콜론이 한 번 더 들어간 형태는 유효하지 않은 URL이므로, FE의 HTTP 서버(Netty/Jetty)가 이를 처리하지 못하고 *400 Bad Request*를 반환하게 됩니다. 2. 왜 fe-0에서만 발생하는가?

fe-1

, `fe-2`는 정상이고 `fe-0`에서만 실패한다면, *`fe-0`의 메타데이터 정보*나 *설정 파일(

fe.conf

)*에 오류가 있을 가능성이 높습니다. * FE 메타데이터 확인: Leader FE(fe-2)에서 아래 명령어를 실행하여 `fe-0`의 HTTP 포트가 어떻게 등록되어 있는지 확인하십시오.

sql
    SHOW FRONTENDS;

HttpPort

컬럼에

8083:

처럼 뒤에 콜론이 붙어 있지는 않은지 확인이 필요합니다. * fe.conf 설정 확인:

fe-0

노드의

fe.conf

파일 내

http_port

설정을 확인하십시오.

properties
    # 잘못된 예
    http_port = 8083:
    # 올바른 예
    http_port = 8083

* 환경 변수 확인 (K8s): Helm 차트나 K8s Manifest에서 `FE_HTTP_PORT`와 같은 환경 변수를 전달할 때 실수로 콜론이 포함되었는지 점검하십시오. 3. Cluster Snapshot 관련 특이점 StarRocks 4.1.x 버전에서 Cluster Snapshot은 메타데이터 체크포인트가 완료된 직후 실행됩니다. 로그에서

finish checkpoint successfully, journalId : 2429034

이후 실패하는 것으로 보아, `fe-0`이 로컬 체크포인트를 마치고 이 이미지를 S3로 업로드하거나 Leader가 이를 가져오려 할 때, 잘못된 주소 형식으로 요청을 보내고 있는 상황입니다. 조치 방법 권장 1.

SHOW FRONTENDS;

결과에서 `fe-0`의 포트 정보를 확인합니다. 2. 정보가 잘못되어 있다면, 해당 노드를

ALTER SYSTEM DROP FRONTEND

후 올바른 포트로 다시

ADD FRONTEND

하거나,

fe.conf

수정 후 재시작하여 메타데이터가 갱신되는지 확인합니다. 3. URL의

subdir=

파라미터가 비어 있는 점도 눈에 띄는데, 이는 4.1.1 버전의 기본 동작일 수 있으나 만약 포트 문제가 해결된 후에도 400 에러가 지속된다면, 스냅샷 저장 경로(

storage volume

) 관련 권한이나 설정도 함께 점검해 보시기 바랍니다. 만약 위 설정들에 문제가 없음에도 URL 생성 로직 자체에서 콜론이 추가되는 현상이 발생한다면, 이는 4.1.1 버전의 특정 조건 하에서의 버그일 가능성이 있으므로 공식 GitHub Issue나 커뮤니티에 제보가 필요할 수 있습니다. References • administration/management/FE_configuration.md • faq/Deploy_faq.md • administration/Meta_recovery.md

@Rocky fe-0 cluster snapshot 에러는 아래 내용도 확인 됨 • checkpoint failed for FE iamge: {cluster name}-fe-0.{cluster svc name}.{cluster namespace name}.svc.cluster.local_9010_1781243762027 • push image.24292540 from subdir [] to other nodes. totally 1nodes, push succedd 0 nodes • Server returned HTTP response code : 400 for URL http://{cluster name}-fe-0.{cluster svc name}.{cluster namespace name}.svc.cluster.local:8030/put?version=24292540&port=8030&subdir=&for_global_state=true&image_format_version=v2

StarRocks 4.1.1 Shared Data 환경에서

fe-0

노드에서만 Cluster Snapshot(또는 메타데이터 체크포인트 동기화)이 HTTP 400 에러로 실패하는 현상은, 주로 *해당 노드의 설정 정보가 다른 노드들과 불일치*하거나 *URL 생성 시 잘못된 파라미터가 전달*될 때 발생합니다. 제공해주신 두 가지 로그(포트 8083과 8030 사례)를 종합해 볼 때, 다음의 원인들을 점검해 보시기 바랍니다. 1. 포트 설정 및 URL 형식 오류 (가장 유력) 첫 번째 로그에서 포트 번호 뒤에 콜론이 붙은 주소(

8083:/image

)가 확인되었습니다. * 원인:

fe.conf

내의

http_port

설정값 뒤에 공백이나 특수문자(콜론 등)가 포함되어 있거나, K8s 환경 변수 주입 시 오타가 발생했을 가능성이 매우 높습니다. * 결과: HTTP 요청 시 `8083:/...`와 같은 잘못된 형식의 URL이 생성되어 수신 측 FE가 *400 Bad Request*를 반환합니다. 2. FE 메타데이터 등록 정보 불일치

fe-0

노드가 클러스터에 등록될 때 사용된 정보가 실제와 다를 수 있습니다. Leader FE(

fe-2

)에서 아래 명령을 실행하여 `fe-0`의 정보를 확인하십시오.

sql
SHOW FRONTENDS;

* `fe-0`의 *HttpPort*가 다른 노드(

fe-1

,

fe-2

)와 동일하게

8030

또는 `8083`으로 정확히 찍혀 있는지 확인하십시오. * 만약 `fe-0`만 포트가 다르거나 뒤에 이상한 문자가 붙어 있다면, 해당 FE를 삭제 후 다시 추가해야 할 수 있습니다. 3.

subdir

파라미터와 Shared Data 모드의 특성 로그에서

subdir=

값이 비어 있고 `for_global_state=true`가 포함되어 있습니다. * Shared Data 모드에서는 체크포인트 이미지가 로컬뿐만 아니라 S3(객체 스토리지)에도 업로드되어야 합니다. * `fe-0`이 로컬 체크포인트에는 성공(

finish checkpoint successfully

)했지만, 이를 Leader에게 알리거나 이미지를 전송하는 과정에서 *`fe-0`이 인식하는 자신의 호스트명/포트 정보*가 Leader(

fe-2

)가 가진 정보와 충돌하면 400 에러가 발생할 수 있습니다. * 확인 사항: `fe-0`의 `fe.conf`에서

priority_networks

설정이 K8s Pod IP 대역과 일치하는지, 그리고 `fe-0`이 자신의 주소를 `fe-0.svc...`로 정확히 인식하고 있는지 확인하십시오. 4. 로컬 디렉토리 권한 및 상태

checkpoint failed for FE image: ...fe-0..._9010_...

로그는 `fe-0`이 이미지를 생성하거나 관리하는 과정에서 내부적인 ID 불일치를 겪고 있음을 시사합니다. *

fe-0

Pod의

meta/image

디렉토리에 쓰기 권한이 충분한지, 혹은 디스크가 가득 차지 않았는지 확인하십시오. (체크포인트 성공 로그가 있으나, 이후 push 과정에서 임시 파일을 다루는 중 실패할 수 있습니다.) 권장 조치 단계 1. 설정 점검:

fe-0

Pod 내부의 `fe.conf`에서

http_port

설정에 오타(콜론 등)가 없는지 확인합니다. 2. 메타데이터 정정:

SHOW FRONTENDS;

결과가 비정상이라면:

sql
    ALTER SYSTEM DROP FRONTEND "fe-0_IP:9010";
    -- 이후 fe-0 Pod을 재시작하여 (또는 수동으로) 다시 JOIN 시킵니다.

3. 로그 상세 확인: `fe-0`뿐만 아니라 Leader인 `fe-2`의 `fe.log`에서 `fe-0`으로부터 오는 요청을 왜 400으로 거절했는지에 대한 상세 사유(예:

Invalid parameter

,

Node name mismatch

등)가 있는지 확인하십시오. 특히 포트 뒤의 콜론(

:

) 문제는 전형적인 설정 오류이므로, K8s Manifest의 환경 변수 부분을 먼저 집중적으로 살펴보시는 것을 추천드립니다. References • administration/management/FE_configuration.md • administration/cluster_snapshot.md • faq/shared_data_faq.md • administration/Meta_recovery.md • deployment/shared_data/s3.md • faq/Deploy_faq.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • administration/cluster_snapshot.md • administration/management/FE_configuration.md References • administration/cluster_snapshot.md • administration/management/FE_configuration.md

@Rocky fe(frontend) 는 3개로 구성되어있으며 fe-0 follower fe-1 follower fe-2 leader 로 활성화 되어있으며 show frontends 로 조회시 위와 같이 role (follower) 및 alive (true) 정상으로 조회 되지만 fe-2 에서 curl -i fe-0/journal_id 를 호출하면 400 bad request 로 확인되는 상황임 • java.io.IOException: Server returned HTTP response code: 400… • ERROR Exception whtn pushing image file…fe-0 에서 실패함 • [MetaBaseAction.isFromVAlidFe():111] request is not from valid FE . client : fe-0 ip…

StarRocks 4.1.1 Shared Data 환경에서 `SHOW FRONTENDS`는 정상(Alive: true)이지만, 특정 FE(

fe-0

)에서만 HTTP 400 에러와 함께

request is not from valid FE

로그가 발생하는 것은 *메타데이터 동기화 계층(BDBJE)은 연결되었으나, HTTP 통신 계층에서 보안/식별을 위한 IP 검증이 실패*했음을 의미합니다. 제공해주신 로그(

[MetaBaseAction.isFromValidFe():111]

)를 바탕으로 한 구체적인 원인과 해결 방법은 다음과 같습니다. 1. 원인 분석:

isFromValidFe

검증 실패 StarRocks FE는 체크포인트 이미지 전송이나

journal_id

확인 같은 내부 HTTP 요청을 받을 때, 요청을 보낸 클라이언트의 IP가 *현재 클러스터에 등록된 FE 목록에 포함되어 있는지*를 확인합니다. * 현상: `fe-2`(Leader)가 `fe-0`에게 요청을 보냈으나, `fe-0`은 `fe-2`가 보낸 패킷의 소스 IP를 "신뢰할 수 있는 FE의 IP"로 인식하지 못해 *400 Bad Request*를 반환합니다. * K8s 환경의 특이점: K8s 네트워크 환경(Service Mesh, CNI 설정 등)에 따라 Pod 간 통신 시 *Source IP가 실제 Pod IP가 아닌 Node IP나 ClusterIP로 변환(SNAT)*되는 경우 이 검증이 실패할 수 있습니다. 2. 점검 및 해결 방법 ① 실시간 IP 일치 여부 확인 `fe-0`의 로그에 찍힌

client : <IP>

주소와 `SHOW FRONTENDS`의 결과를 직접 비교하십시오. *

fe-0

로그에서 거부된 클라이언트 IP가 `fe-2`의 실제 Pod IP와 일치하는지 확인합니다. * 만약 로그에 찍힌 IP가 `fe-2`의 Pod IP가 아닌 다른 주소(예: K8s 노드 IP)라면, 네트워크 설정에서 Source IP 보존(Source IP Preservation) 설정이 필요하거나

fe.conf

설정을 조정해야 합니다. ②

priority_networks

설정 확인 (필수) K8s 환경에서 각 Pod은 여러 네트워크 인터페이스를 가질 수 있습니다. 모든 FE의 `fe.conf`에 Pod 네트워크 대역이 정확히 명시되어 있는지 확인하십시오.

properties
# 예: Pod 대역이 10.244.0.0/16 인 경우
priority_networks = 10.244.0.0/16

이 설정이 없으면 FE가 클러스터에 등록할 때 잘못된 IP를 사용하거나, 요청 시 다른 인터페이스를 사용하여 검증에 실패할 수 있습니다. ③ FQDN 모드 사용 여부 만약 StarRocks를 FQDN 모드로 운영 중이라면, 모든 FE가 IP가 아닌 도메인 이름(

fe-0.starrocks.svc...

)으로 통신하도록 설정되어야 합니다. 한 노드만 IP로 통신하려고 하면 이 검증 로직에서 차단될 수 있습니다. ④ 보안 토큰 확인 Shared Data 모드에서는 FE 간 통신 시 토큰을 사용합니다. `fe-0`이 다른 노드들과 다른 `image_dir`이나 `meta_dir`을 참조하고 있어 토큰 정보가 불일치할 가능성이 있는지 확인하십시오. (주로 수동으로 meta 디렉토리를 복사했거나 초기화했을 때 발생) 3. 임시 해결 및 테스트 문제가 지속된다면 `fe-0`의 상태를 완전히 초기화한 후 재조인시키는 것이 가장 빠를 수 있습니다. 1. Leader(

fe-2

)에서 `fe-0`을 클러스터에서 제거:

ALTER SYSTEM DROP FRONTEND "fe-0_IP:9010";

2.

fe-0

Pod의 *로컬 메타데이터 디렉토리를 삭제*하고 Pod 재시작 (K8s라면 PV/PVC 확인). 3. Leader를 Helper로 지정하여 `fe-0`이 다시 Join 하도록 유도. 요약하자면: `fe-0`이 인식하고 있는 "정상 FE 리스트(IP)"와 실제 `fe-2`가 보내는 패킷의 "소스 IP"가 일치하지 않는 것이 핵심입니다. *`fe-0` 로그에 찍힌

client : IP

주소가

SHOW FRONTENDS

상의

fe-2

IP와 정확히 같은지*를 최우선으로 확인해 보시기 바랍니다. References • administration/Meta_recovery.md • administration/management/FE_configuration.md • administration/cluster_snapshot.md • faq/shared_data_faq.md • deployment/shared_data/s3.md • faq/Deploy_faq.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • administration/cluster_snapshot.md • administration/management/FE_configuration.md References • administration/Meta_recovery.md

@Rocky show frontends 쿼리로는 ip정보 대신 fqdn 만 확인되는데요 더 확인할수 있는 내용을 알려줘

`SHOW FRONTENDS`에서 FQDN만 보인다면, StarRocks 내부적으로 *FQDN 모드(

enable_fqdn_mode=true

)*가 활성화되어 운영 중인 상태입니다. 하지만 내부 보안 검증 로직인 `isFromValidFe()`는 여전히 네트워크 패킷의 *실제 소스 IP*를 기준으로 체크하기 때문에 불일치가 발생할 수 있습니다. 더 자세한 정보를 확인하고 문제를 해결하기 위해 다음 항목들을 점검해 보시기 바랍니다. 1.

fe-0

로그에서 거절된 클라이언트의 실제 IP 확인 가장 중요한 데이터는 `fe-0`의 로그에 찍힌 "client : <IP>" 부분입니다. * 확인 방법: `fe-0`의 `fe.log`에서

request is not from valid FE

에러 바로 뒤에 나오는 IP 주소를 메모하십시오. * 분석: 이 IP가 `fe-2`(Leader)의 실제 Pod IP가 맞는지 확인해야 합니다. 만약 이 IP가 *K8s 서비스 IP(ClusterIP)*나 *노드 IP*라면, K8s 네트워크 설정(예: LoadBalancer 소스 IP 보존 미설정 또는 Sidecar 프록시) 때문에 패킷의 소스 IP가 변조되어 `fe-0`이 이를 외부 공격으로 간주하고 거절하는 것입니다. 2. FE가 인식하는 각 노드의 IP 정보 확인 (내부 쿼리)

SHOW FRONTENDS

외에 시스템 내부적으로 FE들이 서로를 어떤 IP로 매핑하고 있는지 확인하기 위해 아래 쿼리를 사용해 보십시오.

sql
-- FE 간의 메타데이터 동기화 상태 및 상세 네트워크 정보를 더 볼 수 있습니다.
SELECT * FROM information_schema.frontends;

(버전에 따라

information_schema

대신 `SHOW FRONTENDS`의 결과와 동일할 수 있으나, 시스템 변수 중 `priority_networks`가 각 노드에서 어떻게 해석되었는지 비교가 필요합니다.) 3.

fe-0

포드 내부에서 DNS 해석 및 라우팅 테스트

fe-0

노드에 접속하여 `fe-2`가 어떤 IP로 인식되는지 확인합니다.

bash
# fe-0 Pod 내부에서 실행
nslookup <fe-2의 FQDN>
ping <fe-2의 FQDN>

여기서 반환되는 IP와 위 1번에서 로그에 찍힌 IP가 일치해야 합니다. 4. `fe.conf`의 핵심 설정 확인 모든 FE 노드에서 다음 설정들이 일치하는지 확인하십시오. *

priority_networks

: 이 설정이 Pod IP 대역(예:

10.244.0.0/16

)으로 정확히 지정되어 있지 않으면, FE가 여러 네트워크 인터페이스 중 잘못된 IP를 클러스터 식별용으로 선택할 수 있습니다. *

enable_fqdn_mode

: 모든 FE가 `true`여야 합니다. 5. 해결 방안 (K8s 환경인 경우) 만약 로그의 IP가 실제 Pod IP와 다르다면(예: 프록시 IP로 찍히는 경우),

fe-0

입장에서 해당 IP는 "등록되지 않은 FE"이므로 400 에러를 냅니다. * 해결책 A: K8s Service 설정에서

externalTrafficPolicy: Local

등을 확인하거나, 네트워크 정책에서 FE Pod 간의 직접 통신(Direct Pod IP Communication)이 허용되는지 확인합니다. * 해결책 B: 만약 특정 노드(

fe-0

)의 메타데이터가 꼬인 상태라면, `fe-0`을 클러스터에서 제거(DROP)한 후

meta/

디렉토리를 완전히 비우고 다시 `follower`로 추가(JOIN)하여 새롭게 이미지를 동기화받도록 하는 것이 가장 확실한 방법입니다. 요약:

fe-0

로그에 찍힌

client : IP

주소가 무엇인지 찾으시고, 그 IP가

fe-2

Pod의 실제 IP와 일치하는지 비교하는 것이 문제 해결의 시작입니다. References • administration/cluster_snapshot.md • faq/Others.md

@Rocky 하나더 확인된 사항이 있는데요 fe/meta/image/v2 와 fe/meta/image/stamgr 의 있는 정보가 fe-0 만 다르고, fe-1/fe-2는 같음 fe-0 (follower) v2/image.26739114 starmgr/image.8231657 fe-1 (follower) fe-2 (leader) v2/image.26752488 starmgr/image.8231794 이런 경우 대응 방법

확인하신 결과는 *`fe-0` 노드의 메타데이터가 최신 상태를 따라가지 못하고 뒤처져 있는 상태(Stale)*임을 명확히 보여줍니다. `fe-1`과 `fe-2`는 서로 일치하지만, `fe-0`만 과거의 이미지 번호(

26739114

vs

26752488

)를 가지고 있습니다. 앞서 발생한 HTTP 400(isFromValidFe) 에러 때문에 `fe-0`이 Leader로부터 최신 체크포인트 이미지를 다운로드하지 못해 동기화가 중단된 것입니다. 이 경우 가장 빠르고 확실한 대응 방법은 *`fe-0`의 메타데이터를 초기화하고 Leader로부터 다시 전체 동기화를 받는 것*입니다. 대응 절차 (Recommended) K8s 환경임을 가정하여 아래 순서로 진행해 주십시오. 1. 클러스터에서

fe-0

제거 Leader 노드(

fe-2

)에 접속하여 `fe-0`을 FE 목록에서 삭제합니다. (FQDN 모드이므로 등록된 FQDN 주소를 사용하십시오.)

sql
-- Leader(fe-2)에서 실행
-- FQDN 확인: SHOW FRONTENDS;
ALTER SYSTEM DROP FRONTEND "fe-0.{svc_name}.{namespace}.svc.cluster.local:9010";

2.

fe-0

메타데이터 디렉토리 초기화

fe-0

Pod의 데이터를 완전히 삭제해야 합니다. * K8s의 경우:

fe-0

Pod을 중지(Scale down)한 후, 해당 Pod이 사용하던 *Persistent Volume(PV) 내의

meta

디렉토리 내용물을 모두 삭제*합니다. * 만약 `emptyDir`을 사용 중이라면 Pod을 재시작하는 것만으로 초기화되지만, 데이터 보존을 위해 보통 PV를 사용하므로 수동 삭제가 필요할 수 있습니다. * 주의:

meta/

디렉토리 전체를 비우되,

fe.conf

설정 파일은 유지해야 합니다. 3. `fe-0`을 클러스터에 재추가 (Helper 모드로 시작)

fe-0

Pod을 다시 시작할 때, Leader(

fe-2

)를 Helper로 지정하여 실행해야 합니다. * StarRocks Operator를 사용 중이라면 자동으로 Join을 시도할 것입니다. * 수동 관리 중이라면 시작 스크립트에

--helper fe-2.{svc_name}.{namespace}.svc.cluster.local:9010

옵션이 포함되어야 합니다. 4. Leader에서

fe-0

다시 승인

sql
-- Leader(fe-2)에서 실행
ALTER SYSTEM ADD FOLLOWER "fe-0.{svc_name}.{namespace}.svc.cluster.local:9010";

왜 이 방법이 필요한가요? 1. 이미지 격차: 현재 `fe-0`은 Leader와 만 개 이상의 Journal ID 차이가 납니다. 이 정도 차이는 증분 동기화(Incremental)가 아닌 전체 이미지 다운로드(Snapshot)가 필요한 수준입니다. 2. 통신 오류 해결: 메타데이터를 초기화하고 새로 Join하면, FE 간의 식별 정보(Token 등)가 새롭게 갱신되어 기존의 HTTP 400(isFromValidFe) 에러가 해결되는 경우가 많습니다. 주의사항 * 네트워크 재확인: 만약 재초기화 후에도 여전히

isFromValidFe

에러와 함께 400 에러가 발생한다면, 이전 답변에서 언급한

priority_networks

설정이 K8s Pod IP 대역과 일치하는지 반드시 확인해야 합니다. (IP 불일치가 해결되지 않으면 다시 이미지를 못 받아와서 똑같이 뒤처지게 됩니다.) * 백업: 작업 전 `fe-0`의

meta

디렉토리를 별도 위치에 백업(복사)해 두는 것을 권장합니다. (비록 Follower 노드이지만 안전을 위해) 이 과정을 거치면 `fe-0`의

v2/image.xxxx

번호가 `fe-2`와 동일하게 업데이트되면서 정상화될 것입니다. References • administration/Meta_recovery.md • administration/management/FE_configuration.md • administration/cluster_snapshot.md • faq/shared_data_faq.md • administration/Meta_recovery.md • administration/management/FE_configuration.md • administration/cluster_snapshot.md • faq/shared_data_faq.md • administration/management/FE_configuration.md • administration/cluster_snapshot.md • faq/shared_data_faq.md • administration/Meta_recovery.md • deployment/shared_data/s3.md • faq/Deploy_faq.md • administration/management/BE_configuration.md • administration/management/FE_configuration.md • administration/cluster_snapshot.md • administration/management/FE_configuration.md • administration/cluster_snapshot.md