이 페이지에서는 Sync와 관련된 몇 가지 일반적인 문제와 디버그를 위한 단계를 설명합니다:
PKIX 예외 및 기타 SSLHandshakeException은 에이전트가 올바른 인증서를 가지고 있지 않아 소스와 인증할 수 없을 때 발생합니다. 올바른 인증서가 설치되어 있는지 확인하려면 Data Connection 및 인증서 가이드를 따르십시오.
sync가 Response 421 received. Server closed connection 오류로 실패하면 지원되지 않는 SSL 프로토콜/포트 조합으로 연결할 수도 있습니다. 예를 들어, 옛날에 사용되지 않는 표준인 991 포트를 통한 암시적 FTPS가 있습니다. 이 경우 명시적 SSL을 사용하는 21 포트가 선호됩니다.
sync가 FTP/S sync인 경우, 출구 프록시 로드 밸런서를 사용하지 않는지 확인하십시오. FTP는 상태가 있는 프로토콜이므로 로드 밸런서를 사용하면 연속적인 요청이 동일한 IP에서 생성되지 않아 sync가 실패할 수 있습니다.
로드 밸런싱의 성격상 실패는 결정론적이지 않으며, 로드 밸런싱 프록시가 있음에도 불구하고 sync 및 미리보기가 때때로 성공할 수 있습니다.
sync 또는 탐색이 com.amazonaws.services.s3.model.AmazonS3Exception:Forbidden (Service: Amazon S3; Status Code: 403; Error Code: 403 Forbidden; Request ID: null; S3 Extended Request ID: null) 오류로 실패하는 경우 이 명령이 출구 프록시를 통해 오류가 발생했다는 것을 의미합니다. 이 오류가 발생하면 다음 시나리오 중 어느 것이 적용되는지 확인해야 합니다:
S3 소스 proxyConfiguration 블록에 추가하십시오:
Copied!1 2 3 4host: <배포 게이트웨이 또는 출구 NLB의 주소> port: 8888 protocol: http nonProxyHosts: <버킷>.s3.<지역>.amazonaws.com,s3.<지역>.amazonaws.com,s3-<지역>.amazonaws.com
예: 모든 VPC 버킷을 화이트리스트에 추가하려면 다음과 같은 구성 추가가 필요합니다:
Copied!1 2 3 4 5 6clientConfiguration: proxyConfiguration: host: <color>-egress-proxy.palantirfoundry.com port: 8888 protocol: http nonProxyHosts: *.s3.<지역>.amazonaws.com, s3.<지역>.amazonaws.com, s3-<지역>.amazonaws.com
소스 시스템에 대해 실행된 정확한 쿼리를 보려면 _data-ingestion.log를 참조하십시오.
sync가 점진적 sync인 경우, 단조롭게 증가하는 열(예: 타임스탬프 또는 ID)과 이 열에 대한 초기 값을 제공해야 합니다.
증분 열을 선택하면 sync 구성 페이지의 SQL 쿼리에 ? 연산자를 추가해야 합니다(여기서 ?는 'incremental' 값으로 대체되며 단 하나의 ?만 사용할 수 있습니다). 예를 들어, SELECT * FROM table WHERE id > ?.
동기화된 데이터 세트에서 행이 누락된 것으로 생각되거나 이전에 동기화된 행이 제대로 업데이트되지 않은 경우 다음 사항을 확인하십시오:
ID를 단조롭게 증가하는 열로 사용하고 있고 마지막 sync에서 동기화된 마지막 ID 값이 10이었다면, ID가 5인 행을 추가하면 해당 ID가 5인 행은 동기화되지 않습니다.기존 행이 재동기화된 것으로 생각되는 경우 다음 사항을 확인하십시오:
LONG 또는 STRING(ISO-8601 형식)으로 캐스팅해야 합니다.증분 sync에서 NullPointerException이 발생하면 SQL 쿼리가 데이터베이스에서 증분 열에 널 값을 포함하도록 하는 행을 검색하는 것을 나타낼 수 있습니다.
SELECT * FROM table WHERE col > ? OR timestamp > 1에서 col은 sync에 사용되는 증분 열입니다. OR의 사용으로 쿼리가 col이 널이 아닌 값만 포함하도록 보장하지 않습니다. col에 대해 동기화된 널 값이 있는 행이 있다면, Data Connection이 sync의 증분 상태를 업데이트하려고 시도할 때 sync가 실패하게 됩니다. 이는 현재 상태가 동기화된 널 값과 비교되어 오류가 발생하기 때문입니다.(col > ? OR timestamp > 1) AND col IS NOT NULL과 같은 쿼리를 다시 작성하여 오류를 방지할 수 있습니다.sync에 사용할 증분 열을 변경하려면 새 sync를 생성하는 것이 좋습니다.
에이전트 호스트에서 <bootvisor-directory>/var/data/processes 디렉토리로 이동하여 ls -lrt를 실행하여 최근에 생성된 bootstrapper~<uuid> 디렉토리를 찾습니다.
/var/log/로 이동합니다.magritte-agent-output.log의 내용을 검토하십시오.OutOfMemory Exception 오류가 표시되면 에이전트가 할당된 작업을 처리할 수 없습니다.
정지된 sync의 일반적인 원인과 관련 수정 사항은 다음과 같습니다:
모든 sync: 가져오기 단계 중 정지
sync가 가져오기 단계 동안 정지되면 소스가 사용 가능하고 운영 중인지 확인하십시오:
JDBC sync: 가져오기 단계 중 정지
sync가 가져오기 단계를 완료하는 데 예상보다 시간이 오래 걸리는 경우 에이전트가 많은 수의 네트워크 및 데이터베이스 호출을 수행하고 있을 수 있습니다. sync 중 네트워크 및 데이터베이스 호출 수를 조정하려면 Fetch Size 매개변수를 조정할 수 있습니다:
Fetch Size 매개변수는 소스 구성의 "고급 옵션" 섹션에 있으며 각 데이터베이스 라운드 트립에 대한 주어진 쿼리의 가져올 행 수를 정의합니다. 따라서:
Fetch Size 매개변수를 줄이면 데이터베이스에 대한 호출 당 반환되는 행 수가 줄어들고 더 많은 호출이 필요합니다. 그러나 이렇게 하면 에이전트가 더 적은 메모리를 사용하게 되므로 주어진 시간에 에이전트의 힙에 저장되는 행 수가 줄어듭니다.Fetch Size 매개변수를 늘리면 데이터베이스에 대한 호출 당 반환되는 행 수가 늘어나고 더 적은 호출이 필요합니다. 그러나 이렇게 하면 에이전트가 더 많은 메모리를 사용하게 되므로 주어진 시간에 에이전트의 힙에 저장되는 행 수가 증가합니다.Fetch Size: 500으로 시작하여 조정하는 것이 좋습니다.JDBC sync: 업로드 단계 중 정지
sync가 파일 업로드하는 데 시간이 오래 걸리거나 업로드 단계에서 실패하는 경우 네트워크 링크를 과부하 시킬 수 있습니다. 이 경우 Max file size 매개변수를 조정하는 것이 좋습니다:
Max file size 매개변수는 소스 구성의 "고급 옵션" 섹션에 있으며 Foundry에 업로드되는 결과 파일의 최대 크기(바이트 또는 행)를 정의합니다. 따라서:
Max file size 매개변수를 줄이면 더 작은 파일이 더 자주 업로드되어 네트워크에 압력이 증가하지만 파일 업로드가 실패하면 다시 업로드하는 비용이 줄어듭니다.Max file size 매개변수를 늘리면 총 대역폭이 줄어들지만 이러한 업로드가 실패할 가능성이 더 높아집니다.Max file size: 120mb를 추천합니다.FTP / SFTP / Directory / sync: 가져오기 단계 중 정지
파일 기반 sync가 가져오기 단계 동안 정지되는 가장 일반적인 원인은 에이전트가 큰 파일 시스템을 크롤링하기 때문입니다.
파일 시스템을 크롤하는 sync는 파일 시스템을 두 번 완전히 크롤합니다(다른 구성이 지정되지 않은 경우). 이는 sync가 현재 작성 중이거나 어떤 방식으로든 변경된 파일을 업로드하지 않도록 보장하기 위한 것입니다.
REQUEST_ENTITY_TOO_LARGE 오류로 실패한 경우대용량 파일을 다운로드, 처리, 업로드하는 것은 오류가 발생하기 쉽고 느립니다. REQUEST_ENTITY_TOO_LARGE 서비스 예외는 개별 파일이 에이전트의 업로드 대상에 대해 구성된 최대 크기를 초과할 때 발생합니다. data-proxy 업로드 전략의 경우 기본값은 100GB로 설정됩니다.
제한을 무시하는 것은 권장되지 않습니다. 가능하면 이 데이터를 더 작은 파일 모음으로 액세스하는 방법을 찾으십시오. 그러나 일시적인 해결 방법으로 이 제한을 무시하려는 경우 다음 단계를 사용하십시오:
Data Connection에서 에이전트로 이동하여 고급 구성 탭을 선택합니다.
"에이전트" 탭을 선택합니다.
대상 블록 아래에 다음을 포함하여 제한을 150GB로 늘립니다:
Copied!1 2 3uploadStrategy: type: data-proxy maximumUploadedFileSizeBytes: 161061273600
BadPaddingException 오류로 실패한 경우BadPaddingException 예외는 에이전트 내에 저장된 소스 자격 증명 암호화 키가 예상된 것이 아니기 때문에 발생합니다. 이는 일반적으로 에이전트 관리자가 수동으로 업그레이드되지만 이전 /var/data 디렉토리가 새 설치 위치로 복사되지 않을 때 발생합니다.
이 문제를 해결하는 가장 쉬운 방법은 영향을 받는 에이전트를 사용하는 각 소스의 자격 증명을 다시 입력하는 것입니다.
JDBC 소스에서 행을 동기화하고 그 행에 타임스탬프 열이 포함되어 있는 경우 해당 타임스탬프 열은 Foundry에서 긴 열로 캐스팅됩니다. 이 동작은 하위 호환성 문제로 인해 존재합니다.
이러한 열의 데이터 유형을 수정하려면 이러한 정리 작업을 수행하는 데 Python Transform 환경을 사용하는 것이 좋습니다. 다음은 열 "mytimestamp"을 다시 타임스탬프 형식으로 캐스팅하는 예제 코드 스니펫입니다:
Copied!1 2# 데이터프레임(df)의 "mytimestamp" 열을 1000으로 나눈 후 타임스탬프 형식으로 변환하여 업데이트합니다. df = df.withColumn("mytimestamp", (F.col("mytimestamp") / 1000).cast("timestamp"))