Google Spanner Replicat 작업에 대해 BATCHSQL에서 오류 처리
다음 오류는 Google Spanner와 함께 BATCHSQL을 사용할 때 GoldenGate Replicat에서 관리됩니다.
- INSERT: 중복 키 오류
- UPDATE/DELETE: 행을 찾을 수 없음 오류
- 기본 키 업데이트: 키를 찾을 수 없음 오류 및 새 키가 이미 있음 오류
이러한 오류로 인해 DML 작업이 실패하면 기본적으로 트랜잭션이 중단되고 Replicat가 중단됩니다. 사용자가 HANDLECOLLISIONS, OVERRIDEDUPS, INSERT_MISSING_UPDATES 또는 기타 REPERROR 규칙을 사용으로 설정한 경우 재시도, 건너뛰기 또는 수정을 수행한 다음 DML을 실행하여 오류를 해결합니다.
다른 오류로 인해 DML 작업이 실패하면 트랜잭션이 중단되고 Replicat가 중단됩니다. 또는 REPERROR 규칙에 따라 Replicat가 전체 트랜잭션을 중단하고 재시도합니다.
Cloud Spanner의 RESOURCE_EXHAUSTED 오류는 돌연변이 수 또는 총 트랜잭션 크기에 대한 트랜잭션 한도를 초과했음을 나타내는 경우가 많습니다. 다음과 유사한 오류가 발생하여 MAXTRANSOPS 또는 BATCHTRANSOPS를 줄일 것을 제안합니다.
Error: Operation failed on Spanner database due to quota, session limit, or batch size limit error:
Poosible causes :
BATCH LIMIT: Transaction >80,000 mutations or >100 MiB
QUOTA LIMIT: Spanner API quota exhausted (rate-limited)
SESSION LIMIT: Max concurrent sessions (100,000+) exceeded
Action:
For BATCH LIMIT: Reduce batch size or reduce MAXTRANSOPS and restart Replicat.
For QUOTA LIMIT: Increase Spanner quota in Google Cloud Console and restart Replicat.
For SESSION LIMIT: Reduce concurrent sessions to the Spanner and restart Replicat.
Retry using REPERROR with TRANSABORT, MAXRETRIES 5, DELAYSECS 1 is suggested.
Spanner Mutations API 사용
Spanner Mutations라는 Spanner에서 DML을 적용할 때 효율성을 높이려면 BATCHSQL USEMUTATIONS 매개변수가 필요합니다.
즉, ExecuteBatchDml는 작업이 주로 동일한 테이블에 대해 연속적인 삽입인 초기 로드 시드 데이터에 가장 적합합니다.
실시간 DML이 혼합된 일반 작업 로드의 경우 BATCHSQL USEMUTATION 모드는 더 나은 성능 측정 단위를 제공합니다.
BATCHSQL의 USEMUTATIONS 옵션을 사용하는 동안의 작동 제한 사항
스패너 돌연변이를 사용할 때는 다음과 같은 제한 사항이 있습니다.
-
충돌 통계: 충돌 통계는 커밋 시간 돌연변이 결과에서 실제로 업데이트된 삽입 횟수 또는 삽입이 실제로 수행된 누락 행 업데이트 수 또는 건너뛴 업데이트/삭제 작업 수를 식별하지 못하므로 불완전합니다.
-
DML 레벨 REPERROR 작업: Spanner가 버퍼링된 돌연변이에 대한 명령문 레벨 결과를 반환하지 않고 커밋 시 전체 트랜잭션에 대한 오류가 발생하기 때문에 Spanner Mutations를 사용하는 동안 BATCHSQL 모드의 개별 DML 문에
REPERROR작업을 적용할 수 없습니다. -
누락된 행 삭제 작업: 누락된 행에 대한 삭제 작업은 Spanner DeleteMutation 의미로 건너뜁니다. 따라서
USEMUTATIONS의 다른 데이터베이스와 달리 BATCHSQL은 행 삭제 작업이 누락된 경우 항상 성공을 반환합니다. -
PK 업데이트에 대해 일반 모드로 폴백: Replicat가 일반 모드로 폴백됩니다. 기본 키 업데이트가 포함된 모든 트랜잭션의 경우 PK 업데이트가 발생하는 즉시 클래식 모드로 재시도됩니다.
이러한 제한으로 인해 스패너 변형 동작이 변경되지는 않지만 성능 저하가 발생할 수 있습니다.
USEMUTATIONS를 사용한 BATCHSQL 모드 동작
다음은 각 GoldenGate BATCHSQL 모드가 Spanner 돌연변이 유형에 매핑되는 방식을 요약한 것입니다.
-
기본 사례:
1.1. 삽입: 중복 키 삽입의 경우 트랜잭션이 실패하고 커밋 시에만 오류가 반환됩니다.
1.2. Updates: 누락된 행 갱신의 경우 트랜잭션이 실패해야 하며 커밋 시에만 오류가 반환됩니다.
1.3. 삭제: 행이
NOT_FOUND인 경우 삭제 건너뛰기 -
HANDLECOLLISIONS/OVERRIDEDUPS:2.1. 삽입: 중복 키 오류의 경우 삽입을 업데이트로 변환해야 하며 커밋 시에만 오류가 반환되며 PK 충돌 통계가 없습니다.
2.2. Updates: 누락된 행 오류의 경우 업데이트를 건너뛰어야 합니다.
**NOTE:** Spanner locks the row for that specific primary key using Replicat transaction even if it does not exist, which means that Spanner would not allow any other transaction to INSERT that row until Replicat transaction is committed or aborted. {: .infoboxnote}2.3. 삭제:
DELETEMUTATION는 행이NOT_FOUND인 경우 삭제를 건너뜁니다. -
누락된 업데이트 삽입:
3.1. 삽입: 중복 키 삽입의 경우 트랜잭션이 실패하고 커밋 시에만 오류가 반환됩니다.
3.2. Updates: Update는 누락된 행 오류의 경우 행을 삽입해야 하며 커밋 시에만 오류가 반환됩니다.