Fehler in BATCHSQL für Google Spanner Replicat-Vorgänge behandeln

Die folgenden Fehler werden von GoldenGate Replicat bei der Verwendung von BATCHSQL mit Google Spanner verwaltet:

INSERT: Fehler bei doppeltem Schlüssel
UPDATE/DELETE: Fehler: Zeile nicht gefunden
Primärschlüsselaktualisierung: Fehler "Schlüssel nicht gefunden" und Fehler "Neuer Schlüssel ist bereits vorhanden"

Wenn ein DML-Vorgang mit einem dieser Fehler nicht erfolgreich verläuft, wird die Transaktion standardmäßig abgebrochen, und Replicat wird abgebrochen. Wenn der Benutzer HANDLECOLLISIONS, OVERRIDEDUPS, INSERT_MISSING_UPDATES oder andere REPERROR-Regeln aktiviert hat, versucht, überspringt oder modifiziert und führt dann die DML aus, um den Fehler zu beheben.

Wenn ein DML-Vorgang mit einem anderen Fehler nicht erfolgreich verläuft, wird die Transaktion abgebrochen, und Replicat wird abgebrochen. Alternativ kann Replicat basierend auf den REPERROR-Regeln die gesamte Transaktion abbrechen und wiederholen.

Ein RESOURCE_EXHAUSTED-Fehler in Cloud Spanner gibt häufig an, dass das Transaktionslimit für die Anzahl der Mutationen oder die gesamte Transaktionsgröße überschritten wurde. Es tritt ein Fehler wie der Folgende auf, der vorschlägt, MAXTRANSOPS oder BATCHTRANSOPS zu reduzieren.

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 Mutationen-API

Der Parameter BATCHSQL USEMUTATIONS ist erforderlich, um die Effizienz beim Anwenden von DMLs in Spanner, Spanner Mutations, zu erhöhen.

Das bedeutet, dass ExecuteBatchDml für Seed-Daten für das anfängliche Laden am attraktivsten ist, wenn Vorgänge überwiegend zusammenhängende Einfügungen für dieselbe Tabelle sind.

Für generische Workloads mit gemischten Echtzeit-DMLs bietet der BATCHSQL-USEMUTATION-Modus bessere Performancemetriken.

Betriebsbeschränkungen bei Verwendung der Option USEMUTATIONS von BATCHSQL

Die folgenden Einschränkungen bestehen bei der Verwendung von Spanner-Mutationen:

Kollisionsstatistiken: Kollisionsstatistiken sind unvollständig, da die Ergebnisse der Commit-Time-Mutation nicht identifizieren, wie viele Einfügungen effektiv zu Aktualisierungen wurden oder wie viele fehlende Zeilenaktualisierungen effektiv zu Einfügungen wurden oder wie viele Aktualisierungen/Löschvorgänge übersprungen wurden.
REPERROR-Aktionen auf DML-Ebene: REPERROR-Aktionen können bei Verwendung von Spanner Mutations nicht auf einzelne DML-Anweisungen im BATCHSQL-Modus angewendet werden, da Spanner keine Ergebnisse auf Anweisungsebene für gepufferte Mutationen zurückgibt und beim Festschreiben für die gesamte Transaktion ein Fehler angezeigt wird.
Fehlende Zeilenlöschvorgänge: Löschvorgänge für fehlende Zeilen werden von der Spanner-Semantik DeleteMutation übersprungen. Im Gegensatz zu anderen Datenbanken gibt BATCHSQL mit USEMUTATIONS bei fehlenden Zeilenlöschvorgängen immer den Erfolg zurück.
Fallback-zu-Normal-Modus für PK-Updates: Replicat fällt in den Normal-Modus zurück. Für jede Transaktion, die eine Primärschlüsselaktualisierung enthält, wird der Vorgang im klassischen Modus wiederholt, sobald eine PK-Aktualisierung auftritt.

Obwohl sich das Verhalten der Spanner-Mutation aufgrund dieser Einschränkungen nicht ändert, kann dies zu einer Leistungsverschlechterung führen.

Verhalten des BATCHSQL-Modus mit USEMUTATIONS

Im Folgenden finden Sie eine Übersicht darüber, wie jeder GoldenGate BATCHSQL-Modus den Spanner-Mutationstypen zugeordnet wird:

Standard-Case:

1,1 Einfügungen: Die Transaktion sollte bei Einfügungen mit doppeltem Schlüssel fehlschlagen, und der Fehler wird nur beim Festschreiben zurückgegeben.

1,2 Updates: Transaktion sollte fehlschlagen, wenn Zeilenaktualisierungen fehlen, und der Fehler wird nur beim Festschreiben zurückgegeben.

1,3 Löscht: Überspringt das Löschen, wenn Zeile NOT_FOUND ist
HANDLECOLLISIONS/OVERRIDEDUPS:

2,1 Einfügevorgänge: Einfügevorgänge sollten in ein Update konvertiert werden, falls ein Fehler mit doppeltem Schlüssel auftritt. Der Fehler wird nur zum Zeitpunkt des Festschreibens zurückgegeben, und es würden keine PK-Collision-Statistiken vorhanden sein.

2,2 Updates: Aktualisierungen sollten übersprungen werden, falls Zeilenfehler fehlen.
```
 **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 Löschvorgänge: DELETEMUTATION überspringt das Löschen, wenn die Zeile NOT_FOUND ist.
Fehlende Aktualisierungen einfügen:

3,1 Einfügungen: Die Transaktion sollte bei Einfügungen mit doppeltem Schlüssel fehlschlagen, und der Fehler wird nur beim Festschreiben zurückgegeben.

3,2 Updates: Update sollte die Zeile bei fehlendem Zeilenfehler einfügen und der Fehler wird nur beim Festschreiben zurückgegeben.