TiDB Cloud Lake FAQ¶
계정 및 Lake DSN¶
TiDB Cloud 계정이 없으면 어떻게 하나요?¶
TiDB Cloud 등록으로 이동합니다. 등록 및 첫 인증을 완료하면 시스템이 TiDB Cloud Lake로 진입하고 Connect가 열립니다. LakeSQL DSN을 복사한 후 Guance으로 돌아가서 구성을 계속합니다.
Connect 또는 Lake DSN을 찾을 수 없습니다¶
- 현재 TiDB Cloud Lake에 진입했는지 확인합니다.
- Lake 페이지에서 Connect를 엽니다.
- 연결 예제에서 LakeSQL을 선택하고 Python, Golang 등 다른 예제는 복사하지 마십시오.
- DSN에 Database와
warehouse매개변수가 모두 포함되어 있는지 확인합니다.
전체 단계는 TiDB Cloud 등록 및 Lake DSN 가져오기를 참조하세요.
Lake DSN 형식이 잘못되었거나 Database, Warehouse를 구문 분석할 수 없습니다¶
Connect 페이지에서 전체 DSN을 다시 복사하고 그 내용을 수동으로 삭제하거나 변경하지 마십시오. 형식은 다음과 같아야 합니다.
비밀번호에 특수 문자가 포함된 경우 TiDB Cloud Lake 페이지에서 생성된 DSN을 우선 사용하고, 수동으로 연결하여 인코딩 오류가 발생하지 않도록 하십시오.
연결 및 인증¶
인증 실패 메시지가 표시됩니다¶
가능한 원인으로는 SQL 사용자 또는 비밀번호 오류, 비밀번호 업데이트, 사용자 비활성화 등이 있습니다. TiDB Cloud Lake에서 계정 상태를 확인하고 DSN을 다시 가져온 후 Guance의 구성을 업데이트하세요.
TiDB Cloud Lake에 연결할 수 없다는 메시지가 표시됩니다¶
다음을 순서대로 확인하세요.
- DSN의 Endpoint와 Port가 완전한지 확인합니다.
- 대상 Warehouse를 사용할 수 있는지 확인합니다.
- TiDB Cloud Lake 서비스가 정상인지 확인합니다.
- 네트워크 정책에서 Guance 서비스가 Lake에 액세스할 수 있도록 허용하는지 확인합니다.
- 나중에 연결 테스트를 다시 실행하여 일시적인 네트워크 또는 Warehouse 사용 불가를 배제합니다.
비밀번호 변경 후 해야 할 일은 무엇인가요?¶
Lake DSN을 다시 복사하고, 이전 비밀번호를 사용하는 모든 외부 데이터 소스와 데이터 전송 규칙을 각각 업데이트해야 합니다. 두 기능은 설정을 독립적으로 저장하므로 자동으로 동기화되어 업데이트되지 않습니다.
외부 데이터 소스 및 쿼리¶
연결은 성공했지만 쿼리 시 권한이 없다고 표시됩니다¶
연결 성공은 DSN과 기본 연결이 유효함을 의미할 뿐입니다. SQL 사용자에게 대상 Database, Schema 및 Table에 대한 읽기 전용 쿼리 권한이 있는지 확인하고, 현재 Guance 멤버가 해당 외부 데이터 소스를 사용할 권한이 있는지 확인하세요.
쿼리 데이터 소스 목록에 Lake 데이터 소스가 표시되지 않습니다¶
다음을 확인하세요.
- 데이터 소스가 저장되었고 삭제되지 않았습니다.
- 현재 멤버에게 해당 데이터 소스 사용 권한이 있습니다.
- 현재 페이지가 외부 데이터 소스 쿼리를 지원합니다.
- 필터 또는 검색 조건이 데이터 소스를 숨기지 않았습니다.
쓰기 SQL이 실행되지 않는 이유는 무엇인가요?¶
Lake 데이터를 보호하기 위해 외부 데이터 소스 쿼리는 단일 읽기 전용 SELECT, WITH ... SELECT 또는 EXPLAIN만 지원합니다. 쓰기, 삭제, DDL, 트랜잭션 및 다중 문은 서버에서 거부됩니다. 관측 데이터를 써야 하는 경우 TiDB Cloud Lake로 데이터 전송을 사용하세요.
쿼리 시간 초과 또는 반환 개수가 제한을 초과합니다¶
단일 쿼리는 기본적으로 60초 후 시간 초과되며 최대 10,000행을 반환합니다. 시간 범위를 좁히고, WHERE 조건을 추가하고, 스캔 테이블을 줄이거나 LIMIT을 추가하세요.
데이터 전송¶
연결 테스트는 성공했는데 대상 테이블이 생성되지 않은 이유는 무엇인가요?¶
연결 테스트는 Lake DSN, Database, Warehouse, 대상 테이블 존재 여부, 관련 쓰기 또는 테이블 생성 권한을 확인하고 해당 검사 결과를 제공하지만 테이블을 생성하지는 않습니다. 대상 테이블이 없는 경우 시스템은 규칙 생성 완료 시 현재 전송 데이터 유형의 관리형 구조에 따라 테이블 생성 작업을 수행합니다.
연결 테스트 또는 규칙 완료 시 쓰기 또는 테이블 생성 권한이 없다고 표시됩니다¶
- 대상 테이블이 이미 존재하는 경우: SQL 사용자에게 대상 테이블 쓰기 권한이 필요합니다.
- 대상 테이블이 없는 경우: SQL 사용자에게 대상 Database에 테이블을 생성할 권한도 필요합니다.
권한을 조정한 후 연결을 다시 테스트한 다음 규칙 생성을 완료합니다.
대상 테이블의 쓰기 권한이나 테이블 구조 검사가 실패하거나 시스템이 대상 테이블 생성을 실패하더라도 규칙은 계속 활성화되며 규칙 목록에 【！】 표시가 나타납니다. 표시에 따라 권한, 테이블 구조 또는 테이블 생성 문제를 해결하여 후속 배치가 대상 테이블에 쓸 수 있도록 하세요.
대상 테이블 구조가 호환되지 않는다고 표시됩니다¶
기존 대상 테이블은 현재 전송 데이터 유형의 시스템 관리형 구조와 호환되어야 합니다. 새 테이블 이름을 사용하여 시스템이 규칙 생성 완료 시 자동으로 생성하도록 하는 것이 좋습니다. 기존 테이블을 사용해야 하는 경우 오류 메시지에 따라 테이블 구조를 먼저 조정하세요.
규칙이 활성화되었지만 일시적으로 데이터를 조회할 수 없습니다¶
데이터 전송은 선택한 데이터 대기 시간에 따라 Parquet Batch를封存하여 Lake에 로드하므로 실시간으로 개별적으로 쓰지 않습니다. 다음을 확인하세요.
- 규칙의 데이터 유형 및 필터 조건과 일치하는 데이터가 있는지 확인합니다.
- 선택한 15분, 30분 또는 1시간 대기 시간이 경과했는지 확인합니다.
- 규칙 및 로드 배치에 실패가 표시되는지 확인합니다.
- 쿼리에 사용된 Database 및 Target Table이 규칙과 일치하는지 확인합니다.
Bucket, 스토리지 경로 또는 IAM 자격 증명을 입력할 필요가 없는 이유는 무엇인가요?¶
TiDB Cloud Lake 전송은 Guance가 관리하는 중간 스토리지와 객체 경로를 사용합니다. 사용자는 Lake DSN과 Target Table만 제공하면 됩니다. Bucket, 객체 경로 및 중간 액세스 자격 증명은 시스템이 유지 관리합니다.
보안 문제 해결¶
문제 제출 시 제공할 수 있는 정보는 무엇인가요?¶
다음을 제공할 수 있습니다.
- 데이터 소스 이름 또는 전송 규칙 이름
- 비식별화된 Endpoint, Database, Warehouse 및 Target Table
- 실패 시간, 오류 코드 및 페이지 오류 정보
- SQL 지문 또는 민감 조건을 제거한 쿼리 구조
전체 Lake DSN, SQL 사용자 비밀번호, 내부 Bucket, 임시 자격 증명 또는 민감 데이터가 포함된 전체 쿼리 결과는 제공하지 마세요.