문제 진단

런타임 중에 스트림에 오류가 발생할 수 있습니다.

  • 소스 데이터베이스의 잘못된 비밀번호와 같은 일부 오류는 복구할 수 있으므로 수정할 수 있으며 스트림이 자동으로 재개됩니다.
  • 오류는 지원되지 않는 데이터 유형이 포함된 이벤트와 같은 단일 객체에 영향을 줄 수 있습니다. Datastream이 소스 데이터베이스에 연결할 수 없는 등의 다른 오류는 여러 객체 또는 전체 스트림에 영향을 줄 수 있습니다.
  • 오류에 따라 Datastream UI의 스트림 또는 스트림 세부정보 페이지에서 정보가 제공됩니다. Datastream의 API를 사용하여 오류에 대한 정보를 가져올 수도 있습니다.

오류 문제를 해결하려면 스트림으로 이동하여 오류를 확인하고 오류 메시지에 설명된 단계를 따릅니다.

이 페이지에는 구성, 연결, Oracle, MySQL 오류에 대한 정보와 오류 문제 해결 단계가 포함되어 있습니다.

구성 및 연결 오류

오류 문제 해결 단계
소스 데이터베이스 연결 실패(일반)

여기에는 다양한 이유가 있을 수 있습니다. 이 오류를 해결하려면 다음 작업을 수행합니다.

  1. 소스 데이터베이스가 작동 및 연결 가능한 상태인지 확인합니다.
  2. 스트림 또는 연결 프로필 페이지에서 소스 연결 프로필로 이동합니다.
  3. 연결 프로필 연결 정보가 올바른지 확인합니다.
  4. 사용자 이름과 비밀번호가 일치하는지 확인합니다.
  5. 데이터베이스에 사용자 이름이 존재하고 필요한 권한이 있는지 확인합니다.
  6. 연결 프로필 페이지에서 변경한 내용을 저장합니다.

스트림이 자동으로 재개됩니다.
소스 데이터베이스 연결 실패(IP 허용 목록) 선택한 연결 방법이 IP 허용 목록이지만 Datastream의 발신 IP 주소 중 하나 이상이 소스 데이터베이스에 올바르게 추가되지 않은 경우 이러한 오류가 발생할 수 있습니다. 소스 데이터베이스 서버가 이러한 IP 주소의 연결을 수락할 수 있도록 Datastream 연결 프로필에 표시된 발신 IP 주소가 네트워크 방화벽에 구성되어 있는지 확인합니다. 문제가 해결되면 스트림이 자동으로 재개됩니다.
소스 데이터베이스 연결 실패(SSH 터널 전달) 이 오류는 정방향 SSH 터널에 문제가 있을 때 발생할 수 있습니다. 터널 상태를 확인합니다. 터널이 중지된 경우 터널을 시작해야 합니다. 문제가 해결되면 스트림이 자동으로 재개됩니다.
Datastream이 정방향 SSH 터널을 통해 배스천 호스트에 연결할 수 없음 소스 연결 프로필에 정방향 SSH 터널 구성이 올바르게 구성되어 있고 SSH 터널 서버에 포트가 열려 있는지 확인하세요.
잘못된 인증서로 인한 소스 데이터베이스 연결 실패 이 문제는 소스 연결 프로필을 정의할 때 제공된 인증서에 문제가 있으면 발생할 수 있습니다. 연결 프로필 페이지로 이동한 후 지정된 연결 프로필을 선택합니다. 인증서가 올바르게 설정되었는지 확인하세요. 변경 후 연결 프로필을 저장하면 스트림이 자동으로 재개됩니다.
비공개 연결을 사용한 소스 데이터베이스 연결 실패
  1. 시작하기 전에에 표시된 모든 기본 요건을 완료했는지 확인합니다.

  2. 비공개 연결 구성 만들기가 있는지 확인한 후, 데이터베이스의 내부 IP 주소가 포함된 경로가 VPC 네트워크 피어링 페이지의 내보낸 경로 탭에 표시됩니다.

    이를 확인하려면 VPC 네트워크 피어링 페이지로 이동한 다음 추가된 피어링(이름은 peering-[UUID])을 검색합니다. 내보낸 경로 탭에서 경로를 찾을 수 있습니다. 이 경로가 없으면 수동으로 경로를 추가합니다.

  3. Datastream은 동적 피어링 경로와 겹치는지 확인하지 않습니다. 동적 경로와 겹치는 서브넷을 제공하면 연결 문제가 발생할 수 있습니다. 따라서 동적 경로의 일부인 서브넷은 사용하지 않는 것이 좋습니다.
  4. Datastream IP 주소 범위의 커스텀 경로가 올바르게 공지되었는지 확인합니다. 커스텀 경로가 누락된 경우 커스텀 공지 경로를 참조하세요.
  5. 소스 데이터베이스에 연결하는 데 문제가 계속 발생하면 리버스 프록시 설정을 참조하세요.
연결 정책 STATIC_SERVICE_IP_CONNECTIVITY는 조직 정책인 constraints/datastream.disablePublicConnectivity가 사용 설정된 상태에서 허용되지 않습니다.

만들려는 연결 프로필에 공개 IP 허용 목록 또는 정방향 SSH 터널 네트워크 연결 방법을 선택했습니다. 하지만 Datastream에 공개 연결 방법 차단 조직 정책이 사용 설정되었기 때문에 연결 프로필에 공개 연결 방법을 선택할 수 없습니다.

이 문제를 해결하려면 비공개 VPC 피어링 네트워크 연결 방법을 선택하거나 조직 정책을 사용 중지하세요.

조직 정책을 중지하려면 다음 안내를 따르세요.

  1. Google Cloud 콘솔의 조직 정책 페이지로 이동합니다.
  2. Datastream - 공개 연결 방법 차단 조직 정책을 선택합니다.

  3. 수정을 클릭합니다.

  4. 페이지의 적용 대상 섹션에서 맞춤설정을 선택합니다.

  5. 시행 섹션에서 사용 안함을 선택합니다.

  6. 저장을 클릭합니다.
  7. 만들려는 Oracle 연결 프로필로 돌아가서 만들기를 클릭합니다.
스트림의 소스 데이터베이스를 구성할 때 포함할 객체 목록에서 전송할 테이블 및 스키마를 찾을 수 없음

이 문제는 데이터베이스에 수천 개의 테이블과 스키마가 있는 경우에 발생할 수 있습니다. 이 중 일부가 Google Cloud 콘솔에서 스트림의 소스를 구성할 때 가져올 객체 목록에 포함되지 않을 수 있습니다. 포함할 객체 선택 섹션에서 특정 스키마 및 테이블을 선택하는 대신 커스텀을 선택합니다. 객체 일치 조건 필드에서 Datastream이 전송할 스키마 및 테이블을 입력합니다.
포함할 객체 메뉴를 사용하여 스트림에 여러 테이블을 추가했습니다. 하지만 스트림 세부정보의 객체 탭을 보면 일부 테이블이 누락된 것을 확인할 수 있습니다. Datastream이 변경사항을 인식하고 스트림에 테이블을 자동으로 포함할 수 있도록 이러한 각 테이블에 대해 하나 이상의 CDC 업데이트가 있는지 확인합니다.
Google Cloud 콘솔에서 포함할 객체 메뉴를 사용할 때 객체 목록을 로드할 수 없음 이 문제는 데이터베이스에 5,000개가 넘는 스키마와 테이블이 있는 경우에 발생할 수 있습니다. 다른 방법을 사용하여 포함할 객체를 지정하거나 Datastream API를 사용합니다. 자세한 내용은 소스 데이터베이스 구성을 참조하세요.
이벤트가 스트리밍 중에 삭제되고 대상에서 복제되지 않음

스트리밍 중에 Datastream에서 지원되지 않는 이벤트가 삭제될 수 있습니다. 문제를 해결하기 위해 다음 작업을 수행할 수 있습니다.

  • 전체 테이블의 백필을 수동으로 트리거합니다. 삭제된 이벤트가 UPSERT 이벤트인 경우에만 작동합니다. 삭제된 이벤트에 DELETE 이벤트가 포함된 경우 백필을 수행하기 전에 BigQuery에서 테이블을 잘라야 합니다.

    백필을 수행하는 방법은 백필 시작을 참조하세요.

  • Google 지원팀에 문의하여 부분 백필을 수행하도록 요청합니다. SQL WHERE 절로 삭제된 이벤트를 식별할 수 있고 이벤트가 DELETE 이벤트가 아닌 경우에만 가능합니다.
  • 삭제된 이벤트 수가 적거나 삭제된 이벤트가 중요하지 않은 경우 문제를 무시합니다.

Oracle 오류

오류 문제 해결 단계
소스 데이터베이스에서 추가 로깅이 잘못 구성됨

소스 데이터베이스에서 추가 로깅 구성이 올바르지 않으면 진행 중인 변경 데이터 캡처(CDC) 데이터를 가져오는 중에 오류가 발생할 수 있습니다. 추가 로깅이 올바르게 구성되었는지 확인합니다. 특히 소스에서 대상으로 스트리밍되는 데이터베이스 테이블에 대해 보조 로깅이 설정되었는지 확인합니다. 스트림이 자동으로 재개됩니다.
로그 위치가 손실되어 복제를 재개할 수 없음 이 오류는 복제 프로세스가 장시간 일시중지되어 로그 위치가 손실될 때 발생할 수 있습니다. 로그 보관 기간에 근접한 기간 동안 스트림을 일시중지하면 안 됩니다. 스트림을 다시 만듭니다.
로그 파일이 일부 또는 전부 누락됨

로그 파일이 삭제되었을 수 있습니다. 최소 순환 기간을 지정하여 유지하지 않는 한 Oracle에서는 로그 파일을 최대한 빨리 삭제합니다. Oracle 서버에서 로그 파일을 보관할 기간을 설정합니다. 예를 들어 CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;를 사용하여 로그 파일을 4일 이상 유지합니다.

RDS 배포의 경우 exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',96);을 사용합니다.
포함 목록이 제외 목록에 포함됨 포함 목록이 제외 목록에 완전히 포함되기 때문에 Datastream이 소스에서 가져올 객체 목록이 비어 있습니다. 객체 선택을 수정한 다음 다시 시도하세요.
Oracle 데이터베이스의 로깅 모드가 ARCHIVELOG로 설정되지 않음 로깅 모드를 변경한 다음 다시 시도하세요.
Datastream이 ORA-00942: table or view does not exist 오류 메시지를 반환하지만 모든 것이 올바르게 구성되었습니다. Oracle 서버에서 캐싱한 결과일 수 있습니다. 데이터베이스 사용자를 다시 만들면 캐싱 문제가 해결됩니다.
스트림이 이미 실행 중이면 Oracle 소스에 대한 변경사항이 대상에 반영되지 않습니다. LogMiner를 CDC 방법으로 사용하는 경우 Datastream은 보관처리된 재실행 로그 파일에서 읽습니다. 이 경우 로그가 보관처리되기 전에는 소스에 대한 변경사항이 대상에 반영되지 않습니다. 대상의 변경사항을 보려면 CDC 메서드를 바이너리 로그 리더로 변경하거나 로그 보관처리 정책을 변경하거나 로그 전환을 수동으로 적용합니다. 자세한 내용은 Oracle 데이터베이스 재실행 로그 파일 작업을 참조하세요.
Oracle CDC 구성 유효성 검사에 실패했습니다. 소스 데이터베이스가 구성되지 않은 CDC 메서드를 선택했습니다. 다른 방법을 선택하거나 CDC 메서드의 구성을 완료하세요. 자세한 내용은 소스 Oracle 데이터베이스 구성을 참고하세요.
예기치 않은 내부 오류 발생 자세한 내용은 Google 지원팀에 문의하세요.

MySQL 오류

오류 문제 해결 단계
바이너리 로그가 소스 데이터베이스에서 잘못 구성됨

소스 데이터베이스에서 바이너리 로그 구성이 잘못된 경우 지속적인 MySQL 스트림에서 이러한 오류가 발생할 수 있습니다. 이 오류를 해결하려면 다음 작업을 수행합니다.

  1. 바이너리 로그가 올바르게 구성되었는지 확인합니다.
  2. MySQL 데이터베이스의 바이너리 로그 형식이 ROW로 설정되었는지 확인합니다.
  3. 스트림을 다시 시작합니다.
바이너리 로그 위치가 손실되어 복제를 재개할 수 없음 이 오류는 복제 프로세스가 장시간 일시중지되어 바이너리 로그 위치가 손실될 때 발생할 수 있습니다. 바이너리 로그 보관 기간에 근접한 기간 동안 스트림을 일시중지하면 안 됩니다. 스트림을 다시 만듭니다.
소스 데이터베이스 및 대상 버전이 호환되지 않아 스트림을 실행할 수 없음

소스 데이터베이스가 버전 지원 매트릭스를 준수하지 않는 경우에 이러한 오류가 발생할 수 있습니다. 이 오류를 해결하려면 다음 작업을 수행합니다.

  1. 소스 데이터베이스가 매트릭스를 준수하는지 확인합니다.
  2. 업데이트된 소스 데이터베이스로 스트림을 다시 만듭니다.
AWS RDS MySQL 소스 바이너리 로그가 일부 또는 전부 누락됨 바이너리 로그가 삭제되었을 수 있습니다. 최소 순환 기간을 지정하여 유지하지 않는 한 AWS RDS에서는 로그 파일을 최대한 빨리 삭제합니다. 소스 AWS RDS MySQL 인스턴스에서 바이너리 로그를 보관해야 할 기간을 시간 단위로 설정합니다. 예를 들어 mysql.rds_set_configuration('binlog retention hours', 168);을 사용하여 바이너리 로그를 7일 이상 유지합니다.
포함 목록이 제외 목록에 포함됨 포함 목록이 제외 목록에 완전히 포함되기 때문에 Datastream이 소스에서 가져올 객체 목록이 비어 있습니다. 객체 선택을 수정한 다음 다시 시도하세요.
Datastream에서 MySQL 데이터베이스를 복제할 수 없음 Datastream에 데이터베이스를 복제할 수 있는 권한이 있는지 확인합니다.
MySQL 소스의 연결 프로필을 만들 때 암호화 유형 메뉴에서 PEM으로 인코딩된 여러 SSL 인증서가 허용되지 않음 Datastream은 MySQL 연결 프로필에서 SSL 인증서 체인을 지원하지 않습니다. 단일 x509 PEM 인코딩 인증서만 지원됩니다.
MySQL 소스에서 스트리밍할 때 지연 시간이 김

소스 데이터베이스에서 읽을 수 있는 Datastream 기능을 향상시키세요.

  • 소스 데이터베이스의 최대 바이너리 로그(binlog) 파일 크기를 줄입니다. 크기를 줄이면 바이너리 로그 파일 수가 증가합니다.
  • 바이너리 로그 파일이 여러 개 있는 경우 스트림의 최대 동시 실행 CDC 태스크 수를 그에 따라 설정합니다. 바이너리 로그 파일이 여러 개 있으면 Datastream이 maxConcurrentCdcTasks 필드에 설정된 수까지 소스 데이터베이스 이벤트를 동시에 읽을 수 있습니다.
MySQL CDC 구성 유효성 검사에 실패했습니다. 선택한 CDC 메서드에 맞게 소스 데이터베이스가 구성되지 않았습니다. 다른 방법을 선택하거나 CDC 메서드의 구성을 완료하세요. 자세한 내용은 소스 MySQL 데이터베이스 구성을 참고하세요.
예기치 않은 내부 오류 발생 자세한 내용은 Google 지원팀에 문의하세요.

PostgreSQL 오류

오류 문제 해결 단계
소스 데이터베이스에서 논리적 디코딩이 잘못 구성됨

논리 디코딩이 올바르게 구성되었는지 확인합니다. 소스 PostgreSQL 데이터베이스 구성을 참조하세요.
복제 슬롯이 존재하지 않음 데이터베이스에 복제 슬롯이 존재하지 않으면 진행 중인 변경 데이터 캡처(CDC) 데이터를 가져오는 중에 오류가 발생할 수 있습니다. 복제 슬롯이 올바르게 구성되었는지 확인합니다. 소스 PostgreSQL 데이터베이스 구성을 참조하세요.
복제 슬롯이 잘못된 플러그인으로 구성됨 이 오류는 복제 슬롯이 pgoutput 외의 플러그인으로 구성된 경우 발생할 수 있습니다. 복제 슬롯이 올바르게 구성되었는지 확인합니다. 자세한 내용은 소스 PostgreSQL 데이터베이스를 참조하세요.
복제 슬롯이 다른 프로세스에서 활성화됨 이 오류는 다른 프로세스에서 복제 슬롯을 사용 중일 때 발생할 수 있습니다. 복제 슬롯은 한 번에 프로세스 하나에서만 사용할 수 있습니다. Datastream을 제외한 다른 프로세스에서 동일한 복제 슬롯을 사용하지 않는지 확인합니다.
게시가 올바르게 구성되지 않음 이 오류는 게시가 스트림 구성에 포함된 테이블을 노출하도록 구성되지 않은 경우에 발생할 수 있습니다. 게시가 올바르게 구성되었는지 확인합니다. 스트림의 소스 데이터베이스에 대한 정보 구성을 참조하세요.
게시가 존재하지 않음 이 오류는 데이터베이스에 게시가 존재하지 않으면 발생할 수 있습니다. 게시가 올바르게 구성되었는지 확인합니다. 소스 PostgreSQL 데이터베이스 구성을 참조하세요.
WAL 파일이 손실되어 복제를 재개할 수 없음 이 오류는 복제 프로세스가 장시간 일시중지되어 WAL 파일이 손실될 때 발생할 수 있습니다. WAL 파일 보관 기간에 근접한 기간 동안 스트림을 일시중지하면 안 됩니다. 스트림을 다시 만듭니다.
포함 목록이 제외 목록에 포함됨 포함 목록이 제외 목록에 완전히 포함되기 때문에 Datastream이 소스에서 가져올 객체 목록이 비어 있습니다. 객체 선택을 수정한 다음 다시 시도하세요.
Datastream에서 PostgreSQL 스키마를 복제할 수 없음 Datastream에 스키마 복제 권한이 있는지 확인합니다.
소스 데이터베이스에서 트랜잭션이 크면 데이터 복제 및 동기화에 문제가 발생합니다. 소스 데이터베이스에서 상당한 개수의 레코드를 삽입, 업데이트, 삭제하면 해당 이벤트로 복제 슬롯이 오버로드될 수 있습니다. Datastream이 이러한 이벤트를 읽고 처리하려면 시간이 필요합니다. PostgreSQL 복제 슬롯은 단일 스레드로 구성되기 때문에 다른 테이블의 데이터 변경사항을 포함하여 복제 슬롯의 기타 변경사항 처리는 Datastream이 복제 슬롯의 모든 변경사항을 따라잡을 때까지 지연됩니다.
소스 데이터베이스에서 트랜잭션이 크면 CDC 처리량이 낮아집니다. Datastream은 PostgreSQL에서 멀티 스레드 CDC를 지원하지 않습니다. 이 제한을 극복하고 CDC 처리량을 늘리려면 각각 자체 게시 및 복제 슬롯을 사용해서 소스를 여러 스트림으로 분할할 수 있습니다. 예를 들어 데이터베이스에서 가장 큰 테이블에 대해 하나의 스트림을 만들고 다른 모든 테이블에 대해 스트림을 하나 더 만들거나 최고 우선순위 테이블에 하나의 스트림을 만들고 나머지 테이블에 대해 스트림을 하나 더 만들 수 있습니다. 사용 사례가 달라질 수 있으므로 특정 CDC 시나리오에서 가장 적합한 것을 고려해야 합니다. 게시 만들기에 대한 자세한 내용은 소스 PostgreSQL 데이터베이스 구성을 참조하세요.
지원되지 않는 이벤트가 이유 코드와 함께 삭제됨: BIGQUERY_TOO_MANY_PRIMARY_KEYS. 테이블의 PostgreSQL 복제본 ID가 FULL로 설정된 경우 Datastream은 이 테이블의 모든 열을 기본 키로 취급합니다. 테이블에 열이 16개 넘게 있으면 BigQuery CDC 제한을 위반하며 오류를 일으킵니다. 이 문제를 해결하려면 다음 단계를 수행합니다.
  1. 복제본 ID를 DEFAULT로 변경합니다. 
    ALTER TABLE TABLE_NAME REPLICA IDENTITY DEFAULT
     TABLE_NAME을 복제본 ID를 변경하려는 테이블의 이름으로 바꿉니다.
  2. 포함할 스트림의 객체 목록에서 테이블을 삭제합니다. 자세한 내용은 소스 데이터베이스에 대한 구성 정보 수정을 참조하세요.
  3. BigQuery에서 테이블을 삭제합니다. 자세한 내용은 테이블 삭제를 참조하세요.
  4. Datastream에서 소스 구성을 수정하여 스트림에 다시 테이블을 추가합니다.
예기치 않은 내부 오류 발생 자세한 내용은 Google 지원팀에 문의하세요.

SQL Server 오류

오류 문제 해결 단계
DATABASE_NAME 데이터베이스에 대해 CDC가 사용 중지되었습니다.

데이터베이스에 대해 변경 데이터 캡처(CDC)를 사용 설정해야 합니다. Datastream은 실시간 변경사항을 소스 데이터베이스에 복제하고 전체 로그 정보를 가져오기 위해 트랜잭션 로그에 대한 직접 읽기 액세스 권한이 필요합니다. 데이터베이스에 대해 CDC를 사용 설정하고 다시 시도합니다.

데이터베이스에 대해 CDC를 사용 설정하는 방법은 소스 SQL 서버 데이터베이스 구성을 참조하세요.
CDC가 사용 중지된 테이블.

스트림에 포함된 모든 테이블에 대해 변경 데이터 캡처(CDC)를 사용 설정해야 합니다. Datastream은 실시간 변경사항을 소스 테이블에 복제하고 전체 로그 정보를 가져오기 위해 트랜잭션 로그에 대한 직접 읽기 액세스 권한이 필요합니다. 스트림에 포함된 테이블에 대해 CDC를 사용 설정하고 다시 시도합니다.

소스 테이블에 대해 CDC를 사용 설정하는 방법은 소스 SQL Server 데이터베이스 구성을 참조하세요.
권한이 누락되었습니다. 소스에서 읽는 데 필요한 권한이 Datastream에 없습니다. 데이터베이스 연결하는 데 사용되는 사용자 계정에 적절한 권한을 부여하고 다시 시도합니다.
SQL Server EDITION_NAME 버전은 지원되지 않습니다. Datastream에서 이 SQL Server 버전이 지원되지 않습니다. 지원되는 SQL Server 버전에 대한 자세한 내용은 소스로서 SQL Server 개요를 참조하세요.
Standard 버전의 SQL Server 버전 VERSION_NAME은 지원되지 않습니다. Datastream에서 이 버전의 SQL Server Standard 버전이 지원되지 않습니다. 지원되는 SQL Server 버전에 대한 자세한 내용은 소스로서 SQL Server 개요를 참조하세요.
SQL Server CDC 구성: 실패했습니다. 선택한 CDC 메서드가 데이터베이스 구성을 준수하지 않습니다. CDC 메서드를 변경하고 다시 시도합니다.

BigQuery 오류

오류 문제 해결 단계
BIGQUERY_UNSUPPORTED_PRIMARY_KEY_CHANGE, details: Failed to write to BigQuery due to an unsupported primary key change: adding primary keys to existing tables is not supported. 소스에서 기본 키가 변경되면 BigQuery에서 테이블을 삭제하고 백필을 다시 시작해야 합니다. 이는 기본 키가 다른 경우 새 이벤트와 기존 행을 올바르게 병합했는지 확인할 수 있는 방법이 없기 때문에 BigQuery의 제한사항입니다. 자세한 내용은 BigQuery 대상 구성을 참조하세요.
대상 BigQuery 테이블에 소스 테이블보다 훨씬 많은 레코드가 있습니다. 소스 테이블에 기본 키가 없으면 이 문제가 발생할 수 있습니다. 이러한 경우 Datastream은 추가 전용 쓰기 모드에서 테이블을 처리하며, 지정된 행의 각 이벤트가 BigQuery에서 별도의 행으로 표시됩니다.
추가 전용 쓰기 모드에서 백필을 수행하면 데이터가 중복됩니다.

스트림에 추가 전용 쓰기 모드를 선택하면 데이터가 BigQuery에 통합 없이 INSERT, UPDATE-INSERT, UPDATE-DELETE, DELETE 이벤트 스트림으로 추가됩니다. 따라서 백필을 수행할 때 또는 문제가 발생하여 BigQuery 작성자가 쓰기 작업을 다시 시도할 때 BigQuery에 중복 행이 기록될 수 있습니다. 이 문제를 해결하려면 다음과 비슷한 중복 제거 쿼리를 정기적으로 실행하는 것이 좋습니다.

SELECT * FROM (SELECT *, row_number() OVER (PARTITION BY datastream_metadata.uuid) AS num FROM TABLE_NAME) WHERE num=1
Datastream이 병합 쓰기 모드로 구성되었지만 변경사항이 BigQuery에 병합되지 않았습니다.

소스 테이블에 기본 키가 있는지 확인합니다. BigQuery에서 변경사항을 대상 테이블에 병합하려면 기본 키가 필요합니다.

기본 키가 없으면 소스 또는 대상 테이블에 기본 키를 추가해 보세요. 대상 BigQuery 테이블에 기본 키를 추가하려면 다음 단계를 수행합니다.

  1. 스트림을 일시중지합니다.
  2. BigQuery에서 테이블을 자릅니다.
  3. 테이블 정의에 기본 키를 추가합니다.
  4. 스트림을 재개합니다.
  5. 테이블의 백필을 트리거합니다.
이미 BigQuery에 복제된 테이블에 대해 기본 키 추가, 기본 키 삭제, 기본 키 정의 변경을 수행할 수 없습니다.

기본적으로 Datastream은 기본 키 없이 BigQuery에 이미 복제된 테이블에 기본 키를 추가하거나 기본 키로 BigQuery에 복제된 테이블에서 기본 키를 삭제할 수 없습니다. 하지만 이미 기본 키가 있고 BigQuery에 복제된 소스 테이블에 대해서는 기본 키 정의를 변경할 수 있습니다.

  1. 스트림의 총 지연 시간 측정항목을 확인하고 적어도 현재 지연 시간만큼 기다려 진행 중인 이벤트가 대상에 기록되는지 확인합니다. 그러면 원본 기본 키가 있는 모든 이벤트를 성공적으로 스트리밍할 수 있습니다.
  2. 스트림을 일시중지합니다.
  3. BigQuery의 테이블에 대해 CREATE TABLE 데이터 정의 언어(DDL) 명령어를 복사합니다. 
        SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES
      WHERE table_name='TABLE_NAME';

    다음을 바꿉니다.

    • PROJECT_ID: Google Cloud 프로젝트의 식별자입니다.
    • DATASET_ID: BigQuery의 데이터 세트 식별자입니다.
    • TABLE_NAME: DDL 명령어를 복사하려는 테이블의 이름입니다.
  4. BigQuery에서 테이블을 삭제합니다.
  5. 새로운 기본 키로 CREATE TABLE DDL 명령어를 조정합니다. 파티션 및 클러스터 키와 max_staleness OPTION을 포함합니다. 
        CREATE TABLE `[PROJECT_ID].[DATASET_ID].[TABLE_NAME]`
    (
      product_id INT64 NOT NULL,
      product_name STRING,
      datastream_metadata STRUCT,
      PRIMARY KEY (product_id) NOT ENFORCED
    )
    CLUSTER BY dept_no
    OPTIONS(
      max_staleness=INTERVAL '0-0 0 0:MINS:0' YEAR TO SECOND
    );
    ;

    다음을 바꿉니다.

    • PROJECT_ID: Google Cloud 프로젝트의 식별자입니다.
    • DATASET_ID: BigQuery의 데이터 세트 식별자입니다.
    • TABLE_NAME: DDL 명령어를 복사한 테이블의 이름입니다.
    • MINS: max_staleness 옵션에 설정할 시간(분)입니다(예: 15).
  6. 조정된 쿼리를 실행하여 BigQuery에서 테이블을 다시 만듭니다.
  7. 스트림을 재개합니다.
  8. 테이블의 백필을 시작합니다.

다음 단계

  • 스트림의 잠재적 문제를 찾는 방법은 스트림 문제 해결을 참조하세요.
  • 소스 데이터베이스를 구성하는 방법은 소스를 참조하세요.
  • BigQuery 또는 Cloud Storage 대상을 구성하는 방법은 대상을 참조하세요.