Question 1

대용량 파일(>10GB)을 SeaweedFS mount에 복사할 때 왜 손상되나요?

Accepted Answer

이는 SeaweedFS에서 10GB 이상의 파일을 처리할 때 발생하는 chunk size 제한과 관련된 알려진 문제입니다. 마운트 옵션을 사용하여 더 큰 chunk size를 설정하세요: 20~100GB 파일의 경우 `weed mount -chunkSizeLimitMB=8`, 100~200GB 파일의 경우 `-chunkSizeLimitMB=16`을 사용합니다. 이렇게 하면 0으로 채워진 블록과 MD5 불일치를 유발하는 내부 블록 정렬 오류를 방지할 수 있습니다.

Question 2

filer.backup이 연결되었을 때 SeaweedFS filer가 CPU 코어 하나를 모두 소비하는 이유는 무엇이며, 이를 어떻게 해결할 수 있나요?

Accepted Answer

이것은 filer의 `SubscribeMetadata` 루프에 있는 버그입니다(issue #11635, #11644에서 수정됨). `weed filer.backup` 클라이언트가 시작 위치가 로컬 filer에 영속화된 메타데이터 로그의 끝을 넘어선 체크포인트에서 재개될 때(쓰기가 적은 클러스터에서 흔함), filer는 새로운 쓰기가 발생할 때까지 멈추지 않고 영속화된 로그를 계속 다시 읽으며 연결당 약 1개의 CPU 코어를 소모합니다.

우회 방법(해당 issue에서 확인됨):
1. 사용 중인 filer를 통해 구독된 경로 밖(예: `/buckets` 밖)에 아무 파일이나 씁니다. 이렇게 하면 로그 커서가 앞으로 이동하고, 다음 로그 플러시 후 1분 이내에 CPU가 ~1100m에서 ~10m로 떨어집니다.
2. 임의의 filer를 선택하는 headless 서비스 대신, 영속화된 로그에 재개 위치 이후의 항목이 있는 filer를 가리키도록 `filer.backup`을 설정합니다.

영구적인 수정: PR #11644가 포함된 SeaweedFS 릴리스로 업그레이드하세요. 이 PR은 깨어날 때마다 다시 나열하는 대신 실제 변경 사항(로컬 플러시, 피어 워터마크 이동, 커서 이동)이 있을 때만 디스크 읽기 패스를 실행하도록 제한합니다.

Question 3

두 클러스터가 서로 다른 jwt.filer_signing 키를 사용할 때 weed filer.sync가 프록시된 청크에서 401 Unauthorized 오류로 실패하는 이유는 무엇인가요?

Accepted Answer

SeaweedFS 4.47 및 이전 버전에서 `weed filer.sync`는 TLS에만 `-a.security`/`-b.security`를 사용했으며, 프록시된 청크 읽기/쓰기(`?proxyChunkId=`)의 JWT 서명은 프로세스 전역 `security.toml`(`jwt.filer_signing.key` / `jwt.filer_signing.read.key`)에서 가져왔습니다. 클러스터별 키를 사용하면 한쪽에서 항상 401이 반환됩니다.

해결 방법: PR #11645가 포함된 빌드로 업그레이드하세요(4.47 이후인 10월 8일에 머지됨). 이 빌드는 `security.LoadFilerJwtFromFile`을 통해 각 측의 보안 파일에서 `jwt.filer_signing.*`을 로드하고, 측별 `security.FilerJwtProvider`를 `FilerSource`와 `FilerSink`(`UploadOption.FilerJwt`)에 전달하며, `ResolveChunkManifestWithFilerJwt`를 통해 매니페스트 청크까지 처리하고, 설정되지 않은 경우 전역 키로 폴백합니다. 그런 다음 예를 들어 다음과 같이 실행하세요:

`weed filer.sync -a A:8888 -b B:8888 -a.security a.toml -b.security b.toml -a.filerProxy -b.filerProxy -isActivePassive`

4.47 및 이전 버전에서의 우회 방법: 두 클러스터에 동일한 `jwt.filer_signing` 키를 부여하고, 이를 filer.sync 프로세스의 전역 `security.toml`에 배치하세요.

Question 4

volume.tier.compact를 실행한 후 SeaweedFS 볼륨이 Read/Write 상태로 변경되고 복제본이 동기화되지 않는 이유는 무엇인가요?

Accepted Answer

이는 `volume.tier.compact`에서 확인된 버그이며, PR #11783(머지됨)에서 수정되었습니다. 해당 수정 사항이 포함된 빌드로 SeaweedFS를 업그레이드하세요.

근본 원인: (1) compact 명령은 Unmount + Mount를 통해 원격 객체를 다운로드했으며, 재마운트된 복제본은 형제 복제본들이 읽기 전용 상태로 유지되는 동안 완전히 쓰기 가능한 상태(ReadOnly=false)로 로드되었습니다. 이로 인해 마스터가 새로운 쓰기를 해당 복제본 하나로만 라우팅하게 되어 데이터 불일치가 발생했습니다. (2) Compact는 실행된 복제본만 재작성했습니다 — 형제 복제본들은 이전에 공유된 원격 객체를 가리키는 `.idx`/`.vif` 메타데이터를 그대로 유지했고, compact가 이 원격 객체를 삭제하면서 형제 복제본들에는 오래된(stale) 메타데이터만 남게 되었습니다.

이 수정은 전체 compact+resync 주기 동안 모든 복제본을 읽기 전용으로 고정하고, 업데이트된 `.idx`/`.vif`를 모든 형제 복제본에 재동기화하여 클라우드 티어링된 볼륨이 일관되게 읽기 전용 상태를 유지하도록 합니다(S3가 부분 쓰기를 지원하지 않으므로 필수적임).

Question 5

SQL filer 스토어를 사용할 때 prefix에 언더스코어가 포함되면 SeaweedFS S3 ListObjects가 잘못된 결과를 반환하고 느리게 실행되는 이유는 무엇인가요?

Accepted Answer

SQL filer 스토어(mysql, mysql2, postgres, postgres2, sqlite)는 ListObjects prefix를 이스케이프하지 않은 상태로 `weed/filer/abstract_sql/abstract_sql_store.go`(~405번째 줄)의 SQL `LIKE` 절에 전달하므로, prefix 내의 `_`와 `%`가 와일드카드로 동작합니다. 이로 인해 `(dirhash, name)` 기본 키 범위 스캔이 넓어지고 인덱스가 없는 `directory` 컬럼에 대한 행 조회가 강제되어, 잘못된 매칭과 약 40배 느린 쿼리가 모두 발생합니다. 수정 방법: `%`를 추가하기 전에 prefix에서 `\`, `%`, `_`를 이스케이프하고, MySQL/OceanBase와 Postgres에서 동작이 동일하도록 명시적인 `ESCAPE '\'` 절을 추가하십시오:
```go
escapedPrefix := strings.NewReplacer(
    `\`, `\`,
    `%`, `\%`,
    `_`, `\_`,
).Replace(prefix)
// bind escapedPrefix+"%" to the LIKE parameter
```
동일한 버그가 있는 `ForceBinaryCollation`(`BINARY name`) 코드 경로에도 같은 이스케이핑을 적용하십시오. 패치될 때까지의 우회 방법: prefix를 문자 그대로 비교하며 영향을 받지 않는 비SQL filer 백엔드(leveldb, rocksdb, redis)를 사용하십시오.

SeaweedFS

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트