Ein Synchronisierungslauf kann mittendrin stoppen, weil ein Worker neu startet, das andere System ausgefallen ist oder ein Datensatz abgelehnt wird. Nach einem gestoppten Worker oder einem kurzen Ausfall nimmt Tajo die Synchronisierung von selbst wieder auf. Datensätze, die es in den letzten sieben Tagen geschrieben hat, sendet es nicht erneut. Diese Seite erklärt, was Tajo tut, was du auf der Seite der Synchronisierung siehst und in welchen wenigen Fällen du handeln musst.
Kurzcheck Öffne die Synchronisierung unter Syncs and mappings in Connections und lies den neuesten Lauf in Run history. Ein fehlgeschlagener Lauf sagt, was passiert ist und was als Nächstes zu tun ist.
Was Tajo selbst tut
Der Cursor. Ein Lauf liest seine Quelle in Batches, ab dem gespeicherten Cursor der Synchronisierung. Der Cursor rückt am Ende eines Batches nur vor, wenn jeder Datensatz in diesem Batch angekommen ist. Schlägt der Lauf fehl, bleibt die letzte sauber erreichte Position erhalten. Der nächste Lauf beginnt dort. Ein unterbrochener Batch wird also erneut gelesen und nicht übersprungen.
Das Zustellbuch. Bevor ein Datensatz geschrieben wird, bekommt er einen Zustellschlüssel. Der Schlüssel ist ein Hash aus der Synchronisierung, der Quelle, dem Seiten-Cursor, der Position des Datensatzes auf der Seite und dem Datensatz selbst. Er enthält daher keine personenbezogenen Daten. Bevor das Ziel aufgerufen wird, wird der Schlüssel reserviert. Gelingt der Schreibvorgang, wird der Schlüssel als abgeschlossen markiert und sieben Tage lang aufbewahrt. Der Schlüssel hängt nicht davon ab, welcher Lauf fragt. Eine Wiederholung oder ein späterer geplanter Lauf leitet für denselben Datensatz also denselben Schlüssel ab. Innerhalb dieser sieben Tage wird das gespeicherte Ergebnis verwendet, und das Ziel wird nicht erneut aufgerufen. Deshalb kommt ein wiederholter Batch nicht doppelt an.
Ein Lauf nach dem anderen. Jede Synchronisierung hat einen Lease, den der laufende Lauf für seine ganze Dauer hält. Der Lease hat ein eigenes Token und eine Lebensdauer von 15 Minuten. Solange der Lauf arbeitet, wird er alle 5 Minuten erneuert. Ein Lauf, der seinen Lease verliert, stoppt vor seinem nächsten Schreibvorgang oder Checkpoint, um nicht doppelt zu schreiben. Stoppt ein Worker, wird sein Lease nicht mehr erneuert und läuft innerhalb von 15 Minuten ab.
Automatische Wiederholungen. Ein Lauf aus der Warteschlange, der fehlschlägt, bekommt bis zu fünf Versuche. Tajo wartet 60 Sekunden vor dem zweiten Versuch, dann 120, 240 und 480 Sekunden. Eine Wiederholung oder ein Testlauf, den du selbst startest, läuft einmal. Ein Lauf, der mit einem bereits laufenden Lauf kollidiert ist, wird nicht wiederholt. Ebenso wenig ein Lauf, dessen veröffentlichte Version oder Verbindungen nicht mehr gültig sind.
Hängende Läufe. Bei einer Synchronisierung, die Tajo nach Zeitplan ausführt, wird ein Lauf geschlossen und ein neuer in die Warteschlange gestellt, sobald er vor mehr als einer Stunde gestartet ist und seinen Lease nicht mehr hält. Der geschlossene Lauf zeigt “The run stopped reporting progress and was closed.” Der Lease eines gestoppten Laufs hält also höchstens 15 Minuten, und der hängende Lauf einer geplanten Synchronisierung wird nach einer Stunde ersetzt. Shopify-Datensynchronisation mit Brevo verstehen listet auf, welche Synchronisierungen nach Zeitplan laufen.
Pause nach wiederholten Fehlschlägen. Sind die letzten fünf abgeschlossenen Läufe seit der letzten Änderung der Synchronisierung alle fehlgeschlagen, pausiert Tajo die Synchronisierung. Ihre Seite zeigt “Paused automatically by the failure circuit breaker” mit dem letzten Fehler. Ein erfolgreicher Lauf setzt die Zählung zurück. Nichts startet eine pausierte Synchronisierung von selbst neu: Sie bleibt pausiert, bis du die Ursache behebst und sie erneut veröffentlichst.
Die stündliche Prüfung. Jede Stunde, um 13 Minuten nach der vollen Stunde, alarmiert Tajo sein eigenes Team über jeden Workspace mit einer aktiven Synchronisierung und ohne erfolgreichen Lauf in den letzten 24 Stunden. Dazu gehört auch ein Workspace, in dem überhaupt kein Lauf erfasst wurde. Der Alarm wird einmal ausgelöst und erst wieder, nachdem ein Lauf erfolgreich war. Ein Workspace, dessen älteste aktive Synchronisierung vor weniger als 24 Stunden aktiviert oder geändert wurde, wird noch nicht geprüft. Dieser Alarm erreicht Tajo, nicht dich, und er ändert nichts an deiner Synchronisierung.
Was du siehst
Öffne die Synchronisierung unter Syncs and mappings. Run history listet jeden Lauf mit den geschriebenen von den gelesenen Datensätzen, der Zahl der Fehlschläge, der Dauer und dem Startzeitpunkt. Sein Status ist Queued, Running, Succeeded, Partial (einige Datensätze sind fehlgeschlagen) oder Failed.
- Ein laufender Lauf, der seit 2 Minuten keinen Fortschritt gemeldet hat, zeigt “Waiting for a fresh progress update”.
- Ein fehlgeschlagener Lauf zeigt einen Satz dazu, was passiert ist, einen dazu, was als Nächstes zu tun ist, den Namen des Fehlers und die Lauf-ID.
- View DLQ auf der Seite Syncs listet fehlgeschlagene und teilweise fehlgeschlagene Läufe aller Synchronisierungen, jeweils mit einer Schaltfläche Retry.
Was zu tun ist
- Lies den neuesten fehlgeschlagenen Lauf. Seine Zeile „was zu tun ist“ nennt den nächsten Schritt. Die Tabelle unten listet die Fehler, auf die du am ehesten stößt.
- Steht dort “Nothing”, warte. Der nächste geplante Lauf erholt sich von selbst.
- Steht dort, du sollst die Synchronisierung erneut ausführen, drücke Retry beim fehlgeschlagenen Lauf unter View DLQ. Die Wiederholung beginnt beim gespeicherten Cursor. Bereits geschriebene Batches werden also nicht noch einmal geschrieben. Eine erfolgreiche Wiederholung nimmt den fehlgeschlagenen Lauf von der Liste.
- Wurde die Synchronisierung pausiert, behebe die Ursache, die das Banner nennt, und veröffentliche die Synchronisierung dann erneut mit Publish sync oder Request publish approval.
- Kommt derselbe Fehler wieder, schick uns die Lauf-ID, die unter dem fehlgeschlagenen Lauf steht.
Jeder Fehlername gehört zu einem Satz dazu, was passiert ist, einem dazu, was als Nächstes zu tun ist, und zu der Angabe, wer ihn behebt: du oder Tajo.
| Fehlername | Was passiert ist | Was zu tun ist | Wer es behebt |
|---|---|---|---|
lease_conflict | Ein anderer Lauf dieser Synchronisierung war bereits im Gang. | Nichts. Der laufende Lauf wird fertig; der nächste geplante Lauf startet normal. | Tajo |
lease_lost | Der Lauf hat seinen Slot unterwegs verloren und gestoppt, um nicht doppelt zu schreiben. | Führe die Synchronisierung erneut aus. | Tajo |
lease_unavailable | Die Synchronisierung konnte ihren Lauf-Slot nicht reservieren. | Führe die Synchronisierung erneut aus. Schlägt sie auf dieselbe Weise fehl, schick uns die Lauf-ID. | Tajo |
stale_job_swept | Der Lauf hat keinen Fortschritt mehr gemeldet und wurde geschlossen. | Führe die Synchronisierung erneut aus. | Tajo |
provider_rate_limited | Das andere System hat uns gebeten, langsamer zu werden. | Nichts. Warte auf den nächsten geplanten Lauf. | Tajo |
provider_unavailable | Das andere System war nicht erreichbar oder hat nicht rechtzeitig geantwortet. | Nichts. Warte auf den nächsten geplanten Lauf. Schlägt sie einen Tag lang auf dieselbe Weise fehl, schick uns die Lauf-ID. | Tajo |
connection_missing | Ein Tool, das die Synchronisierung nutzt, ist in diesem Workspace nicht verbunden; der Lauf nennt es. | Verbinde es und führe die Synchronisierung dann erneut aus. | Du |
connection_unauthorized | Das andere System hat unseren Zugriff abgelehnt. | Stelle die Verbindung neu her, damit sie eine frische Autorisierung bekommt, und führe die Synchronisierung dann erneut aus. | Du |
destination_rejected | Das Ziel hat jeden Datensatz dieses Laufs abgelehnt. | Prüfe die Feldzuordnung gegen die Pflichtfelder und Formate des Ziels und führe die Synchronisierung dann erneut aus. | Du |
node_failed | Ein Schritt der Synchronisierung ist beim Lesen, Umwandeln oder Schreiben von Datensätzen fehlgeschlagen. | Öffne den Lauf, um zu sehen, welcher Schritt warum fehlgeschlagen ist, behebe das und führe die Synchronisierung dann erneut aus. | Du |
attestation_rule_not_active | Diese Synchronisierung ist pausiert. | Setze die Synchronisierung fort, um sie auszuführen. | Du |
attestation_publication_not_attested | Diese Version der Synchronisierung wurde nicht veröffentlicht. | Veröffentliche die Synchronisierung. Änderungen an einer Synchronisierung laufen erst, wenn sie veröffentlicht sind. | Du |
unclassified_exception | Die Synchronisierung ist aus einem Grund fehlgeschlagen, den wir noch nicht eingeordnet haben. | Führe die Synchronisierung erneut aus. Schlägt sie auf dieselbe Weise fehl, schick uns die Lauf-ID. | Tajo |
Was schiefgehen kann
- Retry antwortet “This sync rule is already running.” Eine Wiederholung oder ein Testlauf, den du startest, wird abgelehnt, solange irgendein Lauf der Synchronisierung als Queued oder Running erscheint. Das gilt auch für einen Lauf, dessen Worker gestoppt hat. Bei einer Synchronisierung, die Tajo nach Zeitplan ausführt, wird dieser Lauf geschlossen und ersetzt, sobald er vor mehr als einer Stunde gestartet ist. Bei jeder anderen Synchronisierung schick uns die Lauf-ID.
- Eine Synchronisierung schlägt seit mehr als sieben Tagen fehl. Nach sieben Tagen vergisst das Zustellbuch einen abgeschlossenen Schreibvorgang. Ein danach wiederholter Batch kann Datensätze erneut schreiben. Prüfe das Ziel daher auf doppelte Kontakte.
- Eine Synchronisierung ist still, während eine andere funktioniert. Die stündliche Prüfung beobachtet den Workspace, nicht jede einzelne Synchronisierung. Eine gesunde Synchronisierung verdeckt eine stille im selben Workspace. Lies deshalb die Run history jeder Synchronisierung.
- Du willst andere Grenzwerte. Die Pause nach fünf Fehlschlägen und die 24-Stunden-Prüfung gelten für die gesamte Tajo-Installation, nicht pro Synchronisierung.