Question 1

Content-Length와 Transfer-Encoding: chunked가 모두 전송되어 Envoy/Istio 뒤에서 Typesense follower-to-leader 쓰기가 502로 실패하는 문제를 어떻게 해결하나요?

Accepted Answer

이 문제는 Typesense v26.0부터 v30.2까지 영향을 미칩니다. `src/http_client.cpp`에서 팔로워-리더 포워딩은 `Content-Length`를 수동으로 추가하는 반면, libcurl은 `CURLOPT_POSTFIELDSIZE` 없이 `CURLOPT_POST`와 함께 `CURLOPT_READFUNCTION`을 사용하므로 libcurl이 `Transfer-Encoding: chunked`도 추가하게 됩니다. RFC 7230은 두 헤더의 동시 사용을 금지하므로, Envoy/Istio, nginx 또는 HAProxy와 같이 엄격한 프록시는 요청을 HTTP 400으로 거부하며, 이는 클라이언트에게 502로 나타납니다.

영구 수정: 수동 `content-length` 헤더 추가를 제거하고 요청 본문 크기를 명시적으로 설정하여 libcurl이 `Content-Length`만 생성하도록 합니다:

```cpp
// Remove the manual header append, e.g.:
// std::string content_length_header =
//     "content-length: " + std::to_string(req_res->req->_req->content_length);
// chunk = curl_slist_append(chunk, content_length_header.c_str());

// Add:
curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE,
                 (long)req_res->req->_req->content_length);
```

패치를 적용한 후 Typesense를 다시 빌드하십시오.

Istio/Envoy 임시 해결 방법: 팔로워-리더 트래픽에 사용되는 내부 headless Service를 TCP로 구성하여 Envoy가 HTTP 검사를 건너뛰도록 합니다:

```yaml
apiVersion: v1
kind: Service
metadata:
  name: typesense-headless
spec:
  clusterIP: None
  ports:
    - name: tcp-typesense
      port: 8108
      targetPort: 8108
      appProtocol: tcp
```

Service 변경 사항을 적용하고 Typesense 파드를 재시작하거나 롤아웃하십시오. 현재 리더로 쓰기를 직접 전송하는 방법도 포워딩 경로를 피할 수 있지만, 엄격한 HTTP 프록시를 통해 안정적으로 팔로워 쓰기를 수행하려면 코드 패치 또는 TCP 우회가 필요합니다.

Question 2

async_reference alias JOIN 사용 시 재시작 후 Typesense 오류 "Failed to join ... No reference field found" 해결 방법

Accepted Answer

Typesense를 v31.0.rc6 이상으로 업그레이드하세요. 이 릴리스는 시작 시 참조 컬렉션이 별칭이 지정된 대상 컬렉션보다 먼저 로드될 때 발생하는 별칭 기반 `async_reference` JOIN 해석 문제를 수정합니다.

Docker를 사용하는 경우 다음과 같이 이미지를 업데이트하세요:

```bash
docker pull typesense/typesense:31.0.rc6
```

그런 다음 Typesense를 다시 시작하고 실패했던 `filter_by` JOIN 쿼리를 다시 실행하세요:

```text
filter_by=$bookings(x:=`11`)
```

이 문제는 별칭 스왑이 없어도 재시작에 영향을 미치며, `--num-collections-parallel-load=1` 옵션을 사용한 v30.2에서 재현되었습니다.

Question 3

Typesense와 Cloudflare Workers AI 스트리밍에서 'type must be string, but is null' 오류를 수정하는 방법은?

Accepted Answer

이 오류는 Typesense v30.1에서 Cloudflare Workers AI를 대화형 검색에 사용할 때 발생합니다. Cloudflare의 최종 SSE 청크에 "response": null이 포함되어 JSON 타입 오류가 발생합니다. 이 문제가 수정된 Typesense 버전(아마 v30.2+)으로 업그레이드하세요. 해결 방법으로, conversation_model.cpp 파일 978번 줄에서 response 필드에 접근하기 전에 null 체크를 추가하세요: if (chunk["response"].is_null()) continue;. 이렇게 하면 사용량 전용 청크를 건너뛰고 스트리밍 응답이 올바르게 처리됩니다.

Question 4

DNS 이름을 사용하여 클러스터를 재시작할 때 발생하는 Typesense Raft "Unable to resolve host" 및 "Fail to parse nodes" 오류를 해결하는 방법

Accepted Answer

영향을 받는 Typesense v30.x 릴리스에서는 `--nodes`의 모든 피어 항목이 시작 또는 피어 새로 고침 중에 확인(resolve)되어야 합니다. DNS 레코드가 하나라도 누락된 경우(예: 중지된 컨테이너나 삭제된 Kubernetes Pod가 다시 등록되지 않은 경우) 시작이 실패하거나 리더가 `Check failed: !entry->peers->empty()` 오류와 함께 중단될 수 있습니다.

신뢰할 수 있는 해결 방법은 nodes 파일에서 DNS 이름 대신 안정적인 원시 IP 주소를 사용하는 것입니다:

10.0.0.1:8107:8108,10.0.0.2:8107:8108,10.0.0.3:8107:8108

단계:
1. 영향을 받는 Typesense 노드를 중지합니다.
2. `--nodes`에 전달되는 파일에서 DNS 기반 항목을 각 노드의 접근 가능한 IP로 교체합니다.
3. `--peering-address`를 해당 노드 자체의 접근 가능한 IP로 설정된 상태로 유지합니다.
4. 노드를 다시 시작하고 Raft 쿼럼이 복원되었는지 확인합니다.

AWS CloudMap, Docker DNS 또는 Kubernetes headless Service를 사용하는 경우, 영향을 받는 버전에서 노드를 시작하기 전에 모든 피어 DNS 레코드가 존재하는지 확인하세요. 업스트림 수정 사항에는 DNS 재시도 추가, DNS 장애 중 persisted-state 노드의 재시작 허용, DNS 확인 실패 시 피어 업데이트 건너뛰기가 포함되어 있습니다. 이러한 수정 사항이 포함된 릴리스가 제공되면 해당 릴리스로 업그레이드하세요.

typesense

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트