Gestion des erreurs dans BATCHSQL pour les opérations de réplication Google Spanner

Les erreurs suivantes sont gérées par GoldenGate Replicat lors de l'utilisation de BATCHSQL avec Google Spanner :

INSERT : erreur de clé en double
UPDATE/DELETE : erreur de ligne introuvable
Mise à jour de la clé primaire : erreur de clé introuvable et erreur de nouvelle clé existante

Si une opération LMD échoue avec l'une de ces erreurs, par défaut, la transaction est abandonnée et le processus Replicat est abandonné. Si l'utilisateur a activé les règles HANDLECOLLISIONS, OVERRIDEDUPS, INSERT_MISSING_UPDATES ou toute autre règle REPERROR, il essaie, ignore ou modifie, puis exécute le LMD pour résoudre l'erreur.

Si une opération LMD échoue avec une autre erreur, la transaction est abandonnée et le processus Replicat est abandonné. Sinon, en fonction des règles REPERROR, le processus Replicat abandonne et retente l'intégralité de la transaction.

Une erreur RESOURCE_EXHAUSTED dans Cloud Spanner indique souvent que la limite de transaction a dépassé le nombre de mutations ou la taille totale de la transaction. Une erreur semblable à la suivante se produit, suggérant de réduire MAXTRANSOPS ou 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.

Utilisation de l'API Spanner Mutations

Le paramètre BATCHSQL USEMUTATIONS est requis pour augmenter l'efficacité lors de l'application de DML dans Spanner, appelées mutations de Spanner.

Cela signifie que ExecuteBatchDml est particulièrement intéressant pour les données initiales de chargement où les opérations sont principalement des insertions contiguës pour la même table.

Pour les charges globales génériques avec des instructions LMD mixtes en temps réel, le mode BATCHSQL USEMUTATION fournit de meilleures mesures de performances.

Limites opérationnelles lors de l'utilisation de l'option USEMUTATIONS de BATCHSQL

Les limitations suivantes existent lors de l'utilisation des mutations de Spanner :

Statistiques de collision : les statistiques de collision sont incomplètes car les résultats de mutation lors de la validation n'identifient pas le nombre d'insertions effectivement devenues mises à jour, ou le nombre de mises à jour de lignes manquantes effectivement devenues insertions ou le nombre d'opérations de mise à jour/suppression ignorées.
Actions REPERROR de niveau LMD : les actions REPERROR ne peuvent pas être appliquées à des instructions LMD individuelles en mode BATCHSQL lors de l'utilisation de mutations Spanner car Spanner ne renvoie pas de résultats de niveau instruction pour les mutations mises en mémoire tampon et nous obtenons une erreur pour l'ensemble de la transaction au moment de la validation.
Opérations de suppression de ligne manquantes : les opérations de suppression sur les lignes manquantes sont ignorées par la sémantique Spanner DeleteMutation. Par conséquent, contrairement aux autres bases de données, BATCHSQL avec USEMUTATIONS renvoie toujours un succès en cas d'opérations de suppression de ligne manquantes.
Retour au mode normal pour les mises à jour de clé primaire : le processus Replicat revient au mode normal. Pour toute transaction contenant une mise à jour de clé primaire, il fait l'objet d'une nouvelle tentative en mode classique dès qu'il rencontre une mise à jour de clé primaire.

Bien que le comportement de Spanner Mutation ne change pas en raison de ces limitations, il peut entraîner une dégradation des performances.

Comportement du mode BATCHSQL avec USEMUTATIONS

Voici un résumé de la façon dont chaque mode GoldenGate BATCHSQL est mappé avec les types de mutation Spanner :

Par défaut:

1,1 Inserts : la transaction doit échouer en cas d'insertions de clé en double et l'erreur est renvoyée uniquement au moment de la validation.

1,2 Mises à jour : la transaction doit échouer en cas de mise à jour de ligne manquante et l'erreur est renvoyée uniquement au moment de la validation.

1,3 Supprime : ignore la suppression si la ligne est NOT_FOUND
HANDLECOLLISIONS/OVERRIDEDUPS:

2,1 Inserts : l'insertion doit être convertie en mise à jour en cas d'erreur de clé en double et l'erreur est renvoyée uniquement au moment de la validation, et nous n'aurions aucune statistique de collision de clé primaire.

2,2 Mises à jour : les mises à jour doivent être ignorées en cas d'erreurs de ligne manquante.
```
 **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 Supprime : DELETEMUTATION ignore la suppression si la ligne est NOT_FOUND.
Insérer les mises à jour manquantes:

3,1 Inserts : la transaction doit échouer en cas d'insertions de clé en double et l'erreur est renvoyée uniquement au moment de la validation.

3,2 Mises à jour : la mise à jour doit insérer la ligne en cas d'erreur de ligne manquante et l'erreur est renvoyée uniquement au moment de la validation.