Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Versionierung, Konflikterkennung und Synchronisierungsvorgänge für DynamoDB-Datenquellen in AWS AppSync AWS AppSyncDie erweiterten Datenverwaltungsfunktionen für DynamoDB nutzen drei Hauptfunktionen: versionierte Datenquellen, Konflikterkennung und -lösung sowie Synchronisierungsvorgänge. Diese Tools ermöglichen robuste, skalierbare Anwendungen, die gleichzeitige Datenänderungen und Synchronisierungen in verteilten Umgebungen effizient handhaben. Versionierte Datenquellen bilden die Grundlage AWS AppSync des Datenverwaltungssystems. Diese Funktion erweitert DynamoDB-Elemente automatisch mit Versionsmetadaten, zeichnet Änderungen auf, die durch AWS AppSync Mutationen an einer Delta-Tabelle vorgenommen wurden, und verwaltet „Tombstones“ für gelöschte Elemente. Entwickler können Aufbewahrungsfristen für gelöschte Elemente und Änderungsprotokolle konfigurieren, wodurch der Speicherplatz optimiert und gleichzeitig die Datenkonsistenz gewährleistet wird. Versionierte Datenquellen optimieren die Implementierung von Konflikterkennungs- und Synchronisierungsvorgängen und bieten so eine solide Grundlage für eine erweiterte Datenverarbeitung. Mechanismen zur Konflikterkennung und -lösung gewährleisten die Datenintegrität bei gleichzeitigen Schreibvorgängen. AWS AppSync bietet drei Strategien: Optimistic Concurrency, Automerge und Lambda-basierte Lösung. Optimistic Concurrency lehnt widersprüchliche Mutationen ab, sodass Clients es mit aktualisierten Daten erneut versuchen können. Automerge löst automatisch Konflikte auf der Grundlage von Datentypen, führt Listen zusammen, führt Mengenvereinigungen durch und behält bestehende Skalarwerte bei. Die Lambda-basierte Lösung ermöglicht eine benutzerdefinierte Logik für komplexe Konfliktszenarien. Diese Optionen bieten Entwicklern Flexibilität beim Umgang mit Datenkonflikten und gewährleisten so die Konsistenz zwischen verteilten Systemen. Synchronisierungsvorgänge ermöglichen das effiziente Abrufen und Aktualisieren von Daten in Client-Anwendungen. Mit dieser Funktion können Clients alle Ergebnisse aus einer DynamoDB-Tabelle abrufen und anschließend nur Daten abrufen, die seit ihrer letzten Abfrage geändert wurden. AWS AppSync bestimmt anhand des bereitgestellten Synchronisierungstokens, ob auf die Basistabelle oder die Delta-Tabelle zugegriffen werden soll, wodurch die Leistung optimiert und die Datenübertragung reduziert wird. **Topics** + [Versionierung von DynamoDB-Datenquellen](versioned-data-sources.md) + [Erkennung und Lösung von Konflikten](conflict-detection-and-resolution.md) + [Verwenden von DynamoDB-Synchronisierungsvorgängen für versionierte Datenquellen](aws-appsync-conflict-detection-and-sync-sync-operations.md) # Versionierung von DynamoDB-Datenquellen in AWS AppSync AWS AppSync unterstützt derzeit die Versionierung von DynamoDB-Datenquellen. Konflikterkennungs-, Konfliktlösungs- und Synchronisierungsvorgänge erfordern eine `Versioned`-Datenquelle. Wenn Sie die Versionierung für eine Datenquelle aktivieren, wird automatisch: AWS AppSync + Erweitern von Elementen mit Metadaten zur Objektversionierung. + Zeichnet Änderungen an Elementen mit AWS AppSync Mutationen in einer *Delta-Tabelle* auf. + Verwalten gelöschter Elemente in der *Basis*-Tabelle mit einem „Tombstone“ für einen konfigurierbaren Zeitraum. ## Konfiguration der versionierten Datenquelle Wenn Sie die Versionierung für eine DynamoDB-Datenquelle aktivieren, geben Sie die folgenden Felder an: ** `BaseTableTTL` ** Die Anzahl der Minuten, für die gelöschte Elemente in der *Basis*-Tabelle mit einem „Tombstone“ - einem Metadatenfeld, das angibt, dass das Element gelöscht wurde - beibehalten werden. Sie können diesen Wert auf *0* setzen, wenn Elemente sofort entfernt werden sollen, wenn sie gelöscht werden. Dies ist ein Pflichtfeld. ** `DeltaSyncTableName` ** Der Name der Tabelle, in der Änderungen an Elementen mit AWS AppSync Mutationen gespeichert werden. Dies ist ein Pflichtfeld. ** `DeltaSyncTableTTL` ** Die Anzahl der Minuten, in denen Elemente in der *Delta*-Tabelle aufbewahrt werden sollen. Dies ist ein Pflichtfeld. ## Protokollierung der Delta-Sync-Tabelle AWS AppSync unterstützt derzeit Delta Sync Logging für Mutationen mit `PutItem``UpdateItem`, und `DeleteItem` DynamoDB-Operationen. Wenn eine AWS AppSync Mutation ein Element in einer versionierten Datenquelle ändert, wird ein Datensatz dieser Änderung in einer *Delta-Tabelle* gespeichert, die für inkrementelle Aktualisierungen optimiert ist. Sie können wählen, ob Sie verschiedene *Delta-Tabellen* (z. B. eine pro Typ, eine pro Domainbereich) für andere versionierte Datenquellen oder eine einzelne *Delta-Tabelle* für Ihre API verwenden möchten. AWS AppSync empfiehlt, keine einzige *Delta-Tabelle* für mehrere APIs zu verwenden, um die Kollision von Primärschlüsseln zu vermeiden. Das für diese Tabelle erforderliche Schema ist wie folgt: ** `ds_pk` ** Ein Zeichenfolgenwert, der als Partitionsschlüssel verwendet wird. Sie besteht aus der Verkettung des Namens der *Basisdatenquelle* und des ISO-8601-Formats des Datums, an dem die Änderung eingetreten ist (z. B.). `Comments:2019-01-01` *Wenn das `customPartitionKey` Flag aus der VTL-Mapping-Vorlage als Spaltenname des Partitionsschlüssels gesetzt ist (siehe [Resolver Mapping Template Reference for DynamoDB](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html#aws-appsync-resolver-mapping-template-reference-dynamodb-updateitem) im *AWS AppSync Developer Guide*), ändert sich das Format der `ds_pk` Änderungen und die Zeichenfolge wird erstellt, indem ihr der Wert des Partitionsschlüssels im neuen Datensatz in der Basistabelle angehängt wird.* Wenn der Datensatz in der *Basistabelle* beispielsweise den Partitionsschlüsselwert `1a` und den Sortierschlüsselwert von hat`2b`, lautet der neue Wert der Zeichenfolge:`Comments:2019-01-01:1a`. ** `ds_sk` ** Ein Zeichenfolgenwert, der als Sortierschlüssel verwendet wird. Es wird erstellt, indem das ISO 8601-Format des Zeitpunkts der Änderung, des Primärschlüssels des Elements und der Version des Elements verkettet wird. Die Kombination dieser Felder garantiert die Einzigartigkeit jedes Eintrags in der *Delta-Tabelle* (z. B. für eine Uhrzeit und eine ID von `09:30:00` und eine Version von `1a``2`, das wäre). `09:30:00:1a:2` *Wenn das `customPartitionKey` Flag der VTL-Mapping-Vorlage auf den Spaltennamen des Partitionsschlüssels gesetzt ist (siehe [Resolver Mapping Template Reference for DynamoDB](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html#aws-appsync-resolver-mapping-template-reference-dynamodb-updateitem) im *AWS AppSync Developer Guide*), ändert sich das Format der `ds_sk` Änderungen und die Zeichenfolge wird erstellt, indem der Wert des Kombinationsschlüssels durch den Wert des Sortierschlüssels in der Basistabelle ersetzt wird.* Wenn der Datensatz in der *Basistabelle* gemäß dem vorherigen Beispiel den Partitionsschlüsselwert `1a` und den Sortierschlüsselwert von hat`2b`, lautet der neue Wert der Zeichenfolge:`09:30:00:2b:3`. ** `_ttl` ** Ein numerischer Wert, der den Zeitstempel in Epochensekunden speichert, zu dem ein Element aus der *Delta*-Tabelle entfernt werden soll. Dieser Wert wird festgelegt, indem der in der Datenquelle konfigurierte `DeltaSyncTableTTL`-Wert zum Zeitpunkt der Änderung hinzugefügt wird. Dieses Feld sollte als DynamoDB TTL-Attribut konfiguriert werden. Die für die Verwendung mit der *Basis*-Tabelle konfigurierte IAM-Rolle muss auch die Berechtigung zum Betrieb für die *Delta*-Tabelle enthalten. In diesem Beispiel wird die Berechtigungsscheine für eine *Basis*-Tabelle mit dem Namen `Comments` und eine *Delta*-Tabelle mit dem Namen `ChangeLog` angezeigt: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:DeleteItem", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query", "dynamodb:Scan", "dynamodb:UpdateItem" ], "Resource": [ "arn:aws:dynamodb:us-east-1:000000000000:table/Comments", "arn:aws:dynamodb:us-east-1:000000000000:table/Comments/*", "arn:aws:dynamodb:us-east-1:000000000000:table/ChangeLog", "arn:aws:dynamodb:us-east-1:000000000000:table/ChangeLog/*" ] } ] } ``` ------ ## Versionierte Datenquellen-Metadaten AWS AppSync verwaltet in Ihrem Namen Metadatenfelder in `Versioned` Datenquellen. Wenn Sie diese Felder selbst ändern, kann dies zu Fehlern in Ihrer Anwendung oder zu Datenverlusten führen. Zu diesen Feldern gehören: ** `_version` ** Ein monoton steigender Zähler, der jedes Mal aktualisiert wird, wenn eine Änderung an einem Element auftritt. ** `_lastChangedAt` ** Ein numerischer Wert, der den Zeitstempel in Epochenmillisekunden speichert, an dem ein Element zuletzt geändert wurde. ** `_deleted` ** Ein boolescher „Tombstone“-Wert, der angibt, dass ein Element gelöscht wurde. Dies kann von Anwendungen verwendet werden, um gelöschte Elemente aus lokalen Datenspeichern zu entfernen. ** `_ttl` ** Ein numerischer Wert, der den Zeitstempel in Epochensekunden speichert, an dem ein Element aus der zugrunde liegenden Datenquelle entfernt werden soll. ** `ds_pk` ** Ein Zeichenfolgenwert, der als Partitionsschlüssel für *Delta*-Tabellen verwendet wird. ** `ds_sk` ** Ein Zeichenfolgenwert, der als Sortierschlüssel für *Delta*-Tabellen verwendet wird. **`gsi_ds_pk`** Ein Zeichenkettenwertattribut, das generiert wurde, um einen globalen sekundären Index als Partitionsschlüssel zu unterstützen. *Es wird nur aufgenommen, wenn `customPartitionKey` sowohl die `populateIndexFields` Flags als auch in der VTL-Mapping-Vorlage aktiviert sind (siehe [Resolver Mapping Template Reference for DynamoDB](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html#aws-appsync-resolver-mapping-template-reference-dynamodb-updateitem) im AWS AppSync Developer Guide).* Wenn diese Option aktiviert ist, wird der Wert durch Verkettung des Namens der *Basisdatenquelle* und des ISO 8601-Formats des Datums, an dem die Änderung vorgenommen wurde, gebildet (wenn die *Basistabelle* beispielsweise *Comments* heißt, wird dieser Datensatz als gesetzt). `Comments:2019-01-01` **`gsi_ds_sk`** Ein Zeichenkettenwertattribut, das generiert wurde, um einen globalen sekundären Index als Sortierschlüssel zu unterstützen. *Es wird nur aufgenommen, wenn `customPartitionKey` sowohl die `populateIndexFields` Flags als auch in der VTL-Mapping-Vorlage aktiviert sind (siehe [Resolver Mapping Template Reference for DynamoDB](https://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html#aws-appsync-resolver-mapping-template-reference-dynamodb-updateitem) im AWS AppSync Developer Guide).* Wenn diese Option aktiviert ist, wird der Wert durch Verkettung des ISO 8601-Formats des Zeitpunkts, zu dem die Änderung erfolgte, des Partitionsschlüssels des Elements in der *Basistabelle*, des Sortierschlüssels des Elements in der *Basistabelle* und der Version des Elements (z. B. für eine Zeit von`09:30:00`, ein Partitionsschlüsselwert von`1a`, ein Sortierschlüsselwert von `2b` und die Version von`3`, das wäre`09:30:00:1a#2b:3`) konstruiert. Diese Metadatenfelder wirken sich auf die Gesamtgröße der Elemente in der zugrunde liegenden Datenquelle aus. AWS AppSync empfiehlt, beim Entwerfen Ihrer *Anwendung 500 Byte oder mehr als die maximale Primärschlüsselgröße* des Speichers für versionierte Datenquellenmetadaten zu reservieren. Um diese Metadaten in Clientanwendungen zu verwenden, schließen Sie die Felder `_version`, `_lastChangedAt` und `_deleted` in Ihre GraphQL-Typen und in den Auswahlsatz für Mutationen ein. # Konflikterkennung und Konfliktlösung in AWS AppSync Bei gleichzeitigen Schreibvorgängen mit AWS AppSync können Sie Strategien zur Konflikterkennung und Konfliktlösung konfigurieren, um Aktualisierungen entsprechend zu handhaben. Die Konflikterkennung bestimmt, ob die Mutation mit dem tatsächlich geschriebenen Element in der Datenquelle in Konflikt steht. Die Konflikterkennung wird aktiviert, indem der Wert im `conflictDetection` Feld SyncConfig für auf `VERSION` gesetzt wird. Die Konfliktlösung ist die Aktion, die für den Fall ausgeführt wird, dass ein Konflikt erkannt wird. Dies wird bestimmt, indem das Feld Konflikthandler im gesetzt wird SyncConfig. Es gibt drei Strategien zur Konfliktlösung: + OPTIMISTIC\$1CONCURRENCY + AUTOMERGE + LAMBDA Versionen werden AWS AppSync bei Schreibvorgängen automatisch inkrementiert und sollten nicht von Clients oder außerhalb eines Resolvers geändert werden, der mit einer versionsfähigen Datenquelle konfiguriert ist. Dadurch ändert sich das Konsistenzverhalten des Systems, was zu Datenverlusten führen kann. ## Optimistische Parallelität Optimistische Parallelität ist eine Konfliktlösungsstrategie, die versionierte Datenquellen AWS AppSync vorsieht. Wenn der Konflikt-Resolver auf „Optimistische Parallelität“ gesetzt ist und eine eingehende Mutation eine Version hat, die sich von der tatsächlichen Version des Objekts unterscheidet, weist der Conflict Handler die eingehende Anforderung einfach zurück. Innerhalb der GraphQL-Antwort wird das vorhandene Element auf dem Server mit der neuesten Version bereitgestellt. Vom Client wird dann erwartet, dass er diesen Konflikt lokal behandelt und die Mutation mit der aktualisierten Version des Elements erneut versucht. ## Automatische Zusammenführungen Automerge bietet Entwicklern eine einfache Möglichkeit, eine Konfliktlösungsstrategie zu konfigurieren, ohne clientseitige Logik zu schreiben, um Konflikte manuell zusammenzuführen, die nicht von anderen Strategien behandelt werden konnten. Automerge hält sich an einen strengen Regelsatz, wenn Daten zusammengeführt werden, um Konflikte zu lösen. Die Grundsätze des Automerge-Verfahrens drehen sich um den zugrunde liegenden Datentyp des GraphQL-Feldes. Diese sind: + Konflikt in einem Skalarfeld: GraphQL-Skalar oder jedes Feld, das keine Sammlung ist (d. h. List, Set, Map). Zurückweisen des eingehenden Werts für das skalare Feld und Auswahl des auf dem Server vorhandenen Werts. + Konflikt in einer Liste: GraphQL-Typ und Datenbanktyp sind Listen. Verketten der eingehenden Liste mit der vorhandenen Liste auf dem Server. Die Listenwerte in der eingehenden Mutation werden an das Ende der Liste auf dem Server angehängt. Doppelte Werte werden beibehalten. + Konflikt auf einem Set: Der GraphQL-Typ ist eine Liste, und der Datenbanktyp ist ein Set. Anwenden einer Set-Vereinigung mit dem eingehenden und dem vorhandenen Set auf dem Server. Dies entspricht den Eigenschaften eines Sets, d. h. es gibt keine doppelten Einträge. + Wenn eine eingehende Mutation dem Element ein neues Feld hinzufügt oder auf ein Feld mit dem Wert von angewendet wird`null`, fügen Sie dieses Feld mit dem vorhandenen Element zusammen. + Konflikt auf einer Map: Wenn der zugrunde liegende Datentyp in der Datenbank eine Map ist (d.h ein Schlüssel-Wert-Dokument), werden die die oben genannten Regeln angewendet, wenn jede Eigenschaft der Map analysiert und verarbeitet wird. Automerge wurde entwickelt, um Anforderungen automatisch mit einer aktualisierten Version zu erkennen, zusammenzuführen und erneut zu versuchen, so dass der Client keine Konflikte manuell zusammenführen muss. Um ein Beispiel dafür zu zeigen, wie Automerge einen Konflikt auf einem Scalar-Typ verarbeitet, verwenden wir den folgenden Datensatz als Ausgangspunkt. ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "_version" : 4 } ``` Jetzt versucht eine eingehende Mutation möglicherweise, das Element zu aktualisieren, jedoch mit einer älteren Version, da der Client noch nicht mit dem Server synchronisiert wurde. Dies sollte wie folgt aussehen: ``` { "id" : 1, "name" : "Nadia", "jersey" : 55, "_version" : 2 } ``` Beachten Sie die veraltete Version von 2 in der eingehenden Anforderung. Während dieses Vorgangs führt Automerge die Daten zusammen, indem die Aktualisierung des Feldes „jersey“ auf „55“ abgelehnt wird und der Wert bei „5“ bleibt, was dazu führt, dass das folgende Abbild des Elements auf dem Server gespeichert wird. ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "_version" : 5 # version is incremented every time automerge performs a merge that is stored on the server. } ``` Angesichts des Status des oben gezeigten Elements mit Version 5, nehmen wir jetzt an, es geht eine Mutation ein, die versucht, das Element mit dem folgenden Abbild zu mutieren: ``` { "id" : 1, "name" : "Shaggy", "jersey" : 5, "interests" : ["breakfast", "lunch", "dinner"] # underlying data type is a Set "points": [24, 30, 27] # underlying data type is a List "_version" : 3 } ``` Es gibt drei Punkte zu dieser eingehenden Mutation drei wichtige Punkte. Der Name, ein Skalar, wurde geändert, aber zwei neue Felder „interests“, ein Satz und „points“, eine Liste, wurden hinzugefügt. In diesem Szenario wird ein Konflikt aufgrund fehlender Versionsübereinstimmungen erkannt. Automerge hält sich an seine Eigenschaften und weist die Namensänderung zurück, da es sich um einen Skalar und eine Hinzufügung zu den nicht in Konflikt stehenden Feldern handelt. Dies führt dazu, dass das Element, das auf dem Server gespeichert wird, wie folgt aussieht. ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "interests" : ["breakfast", "lunch", "dinner"] # underlying data type is a Set "points": [24, 30, 27] # underlying data type is a List "_version" : 6 } ``` Bei dem aktualisierten Abbild des Elements mit Version 6 nehmen wir nur an, dass eine eingehende Mutation (mit einer anderen fehlenden Versionsübereinstimmung) versucht, das Element in Folgendes umzuwandeln: ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "interests" : ["breakfast", "lunch", "brunch"] # underlying data type is a Set "points": [30, 35] # underlying data type is a List "_version" : 5 } ``` Hier beobachten wir, dass das eingehende Feld für „interests“ einen doppelten Wert hat, der auf dem Server vorhanden ist, sowie zwei neue Werte. Da der zugrunde liegende Datentyp ein Set ist, kombiniert Automerge in diesem Fall die Werte, die auf dem Server vorhanden sind, mit den Werten in der eingehenden Anforderung und entfernt alle Duplikate. Ähnlich besteht ein Konflikt im Feld „points“, in dem ein doppelter Wert und ein neuer Wert vorhanden ist. Da der zugrunde liegende Datentyp hier jedoch eine Liste ist, hängt Automerge einfach alle Werte in der eingehenden Anforderung an das Ende der bereits auf dem Server vorhandenen Werte an. Das resultierende zusammengeführte Abbild, das auf dem Server gespeichert wird, sieht wie folgt aus: ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "interests" : ["breakfast", "lunch", "dinner", "brunch"] # underlying data type is a Set "points": [24, 30, 27, 30, 35] # underlying data type is a List "_version" : 7 } ``` Nehmen wir an, dass das Element, das auf dem Server gespeichert ist, in Version 8 wie folgt aussieht. ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "interests" : ["breakfast", "lunch", "dinner", "brunch"] # underlying data type is a Set "points": [24, 30, 27, 30, 35] # underlying data type is a List "stats": { "ppg": "35.4", "apg": "6.3" } "_version" : 8 } ``` Eine eingehende Anforderung versucht jedoch, das Element mit dem folgenden Abbild zu aktualisieren, erneut mit einer fehlenden Versionsübereinstimmung: ``` { "id" : 1, "name" : "Nadia", "stats": { "ppg": "25.7", "rpg": "6.9" } "_version" : 3 } ``` In diesem Szenario können wir sehen, dass die Felder, die bereits auf dem Server vorhanden sind, fehlen (interests, points, jersey). Zusätzlich wird der Wert für „ppg“ innerhalb der Map „stats“ bearbeitet, ein neuer Wert „rpg“ wird hinzugefügt, und „apg“ wird weggelassen. Automerge behält die Felder, die weggelassen wurden (Hinweis: Wenn Felder entfernt werden sollen, muss die Anforderung erneut mit der übereinstimmenden Version versucht werden), damit sie nicht verloren gehen. Es wendet auch die gleichen Regeln auf Felder in Maps an, weshalb die Änderung zu „ppg“ abgelehnt wird, während „apg“ erhalten bleibt und „rpg“, ein neues Feld, hinzugefügt wird. Das resultierende Element, das auf dem Server gespeichert wird, sieht jetzt wie folgt aus: ``` { "id" : 1, "name" : "Nadia", "jersey" : 5, "interests" : ["breakfast", "lunch", "dinner", "brunch"] # underlying data type is a Set "points": [24, 30, 27, 30, 35] # underlying data type is a List "stats": { "ppg": "35.4", "apg": "6.3", "rpg": "6.9" } "_version" : 9 } ``` ## Lambdas Es stehen mehrere Strategien zur Lambda-Auflösung zur Auswahl: + `RESOLVE`: Ersetzt den vorhandenen Artikel durch einen neuen Artikel, der als Antwort-Payload geliefert wird. Sie können denselben Vorgang nur für ein einzelnes Element gleichzeitig wiederholen. Derzeit unterstützt für DynamoDB `PutItem` und `UpdateItem`. + `REJECT`: Lehnt die Mutation ab und gibt einen Fehler mit dem vorhandenen Element in der GraphQL-Antwort zurück. Derzeit unterstützt für DynamoDB `PutItem`, `UpdateItem` und `DeleteItem`. + `REMOVE`: Entfernt das vorhandene Element. Derzeit unterstützt für DynamoDB `DeleteItem`. **Die Lambda-Aufrufanforderung** Der AWS AppSync DynamoDB-Resolver ruft die in der angegebene Lambda-Funktion auf. `LambdaConflictHandlerArn` Er verwendet die gleiche `service-role-arn`-Konfiguration für die Datenquelle. Die Nutzlast des Aufrufs hat die folgende Struktur: ``` { "newItem": { ... }, "existingItem": {... }, "arguments": { ... }, "resolver": { ... }, "identity": { ... } } ``` Die Felder sind wie folgt definiert: ** `newItem` ** Das Vorschauelement, wenn die Mutation erfolgreich war. ** `existingItem` ** Das Element, das sich derzeit in der DynamoDB-Tabelle befindet. ** `arguments` ** Die Argumente aus der GraphQL-Mutation. ** `resolver` ** Informationen über den Resolver. AWS AppSync ** `identity` ** Informationen über den Aufrufer. Dieses Feld wird auf null gesetzt, wenn der Zugriff mit API-Schlüssel erfolgt. Beispiel-Nutzlast: ``` { "newItem": { "id": "1", "author": "Jeff", "title": "Foo Bar", "rating": 5, "comments": ["hello world"], }, "existingItem": { "id": "1", "author": "Foo", "rating": 5, "comments": ["old comment"] }, "arguments": { "id": "1", "author": "Jeff", "title": "Foo Bar", "comments": ["hello world"] }, "resolver": { "tableName": "post-table", "awsRegion": "us-west-2", "parentType": "Mutation", "field": "updatePost" }, "identity": { "accountId": "123456789012", "sourceIp": "x.x.x.x", "username": "AIDAAAAAAAAAAAAAAAAAA", "userArn": "arn:aws:iam::123456789012:user/appsync" } } ``` **Die Lambda-Aufrufantwort** Für `PutItem`- und `UpdateItem`-Konfliktlösung Die Mutation `RESOLVE`. Die Antwort muss das folgende Format haben. ``` { "action": "RESOLVE", "item": { ... } } ``` Das `item`-Feld stellt ein Objekt dar, das verwendet wird, um das vorhandene Element in der zugrunde liegenden Datenquelle zu ersetzen. Der Primärschlüssel und die Synchronisierungsmetadaten werden ignoriert, wenn sie in `item` enthalten sind. Die Mutation `REJECT`. Die Antwort muss das folgende Format haben. ``` { "action": "REJECT" } ``` Für `DeleteItem`-Konfliktlösung Das Element `REMOVE` Die Antwort muss das folgende Format haben. ``` { "action": "REMOVE" } ``` Die Mutation `REJECT`. Die Antwort muss das folgende Format haben. ``` { "action": "REJECT" } ``` Die folgende Lambda-Beispielfunktion überprüft, wer den Aufruf tätigt, sowie den Namen des Resolvers. Falls es sich um das Objekt handelt`jeffTheAdmin`, `REMOVE` das DeletePost gelöst werden soll, oder `RESOLVE` der Konflikt mit dem neuen Objekt für Update/Put die Problembehebung. Wenn nicht, ist die Mutation `REJECT`. ``` exports.handler = async (event, context, callback) => { console.log("Event: "+ JSON.stringify(event)); // Business logic goes here. var response; if ( event.identity.user == "jeffTheAdmin" ) { let resolver = event.resolver.field; switch(resolver) { case "deletePost": response = { "action" : "REMOVE" } break; case "updatePost": case "createPost": response = { "action" : "RESOLVE", "item": event.newItem } break; default: response = { "action" : "REJECT" }; } } else { response = { "action" : "REJECT" }; } console.log("Response: "+ JSON.stringify(response)); return response; } ``` ## Fehler Im Folgenden finden Sie eine Liste möglicher Fehler, die während eines Konfliktlösungsprozesses auftreten können: ** `ConflictUnhandled` ** Die Konflikterkennung findet eine fehlende Versionsübereinstimmung, und der Conflict Handler lehnt die Mutation ab. Beispiel: Konfliktlösung mit einem Conflict Handler für optimistische Parallelität. Oder Lambda-Conflict Handler, zurückgegeben mit `REJECT`. ** `ConflictError` ** Beim Versuch, einen Konflikt zu lösen, tritt ein interner Fehler auf. Beispiel: Lambda-Conflict Handler gibt eine nicht wohlgeformte Antwort zurück. Oder: Lambda-Conflict Handler kann nicht aufgerufen werden, da die bereitgestellte Ressource `LambdaConflictHandlerArn` nicht gefunden wurde. ** `MaxConflicts` ** Für die Konfliktlösung wurde die maximale Zahl der Wiederholungsversuche erreicht. Beispiel: Zu viele gleichzeitige Anfragen für dasselbe Objekt. Bevor der Konflikt gelöst wird, wird das Objekt von einem anderen Client auf eine neue Version aktualisiert. ** `BadRequest` ** Client versucht, Metadatenfelder (`_version`, `_ttl`, `_lastChangedAt`, `_deleted`) zu aktualisieren. Beispiel: Der Client versucht, ein Objekt mit `_version` einer Aktualisierungsmutation zu aktualisieren. ** `DeltaSyncWriteError` ** Fehler beim Schreiben des Delta-Synchronisierungsdatensatzes. Beispiel: Mutation erfolgreich, aber ein interner Fehler trat auf, als versucht wurde, in die Delta-Synchronisationstabelle zu schreiben. ** `InternalFailure` ** Es ist ein interner Fehler aufgetreten. **`UnsupportedOperation`** Der Vorgang '*X*' wird nicht unterstützt. Die Versionierung von Datenquellen unterstützt nur die folgenden Operationen (TransactGetItems,,, ScanPutItem, QueryBatchGetItem,,, GetItemDeleteItem, UpdateItem Sync). Beispiel: Verwendung bestimmter Transaktions- und Batchoperationen bei aktiviertem Konflikt. detection/resolution Diese Operationen werden derzeit nicht unterstützt. ## CloudWatch Logs Wenn eine AWS AppSync API CloudWatch Protokolle aktiviert hat und die Protokollierungseinstellungen auf Protokolle auf Feldebene `enabled` und Protokollebene für die Protokolle auf Feldebene auf gesetzt sind`ALL`, AWS AppSync werden Informationen zur Konflikterkennung und -lösung an die Protokollgruppe ausgegeben. Informationen zum Format der Protokollmeldungen finden Sie in der [Dokumentation zu Konflikterkennung und Synchronisierungsprotokollierung](monitoring.md#aws-appsync-monitoring-conflict-detection-and-sync-logging). # Verwenden von DynamoDB-Synchronisierungsvorgängen für versionierte Datenquellen in AWS AppSync Versionierte Datenquellen unterstützen `Sync` Operationen, die es Ihnen ermöglichen, alle Ergebnisse aus einer DynamoDB-Tabelle abzurufen und dann nur die Daten zu empfangen, die seit Ihrer letzten Abfrage geändert wurden (die Delta-Updates). Wenn es eine Anforderung für einen `Sync` Vorgang AWS AppSync erhält, verwendet es die in der Anforderung angegebenen Felder, um zu bestimmen, ob auf die *Basistabelle* oder die *Delta-Tabelle zugegriffen* werden soll. + Wenn das `lastSync`-Feld nicht angegeben ist, wird ein `Scan` auf der *Basis*-Tabelle durchgeführt. + Wenn das `lastSync`-Feld angegeben ist, der Wert jedoch vor dem `current moment - DeltaSyncTTL` liegt, wird ein `Scan` auf der *Basis*-Tabelle durchgeführt. + Wenn das `lastSync`-Feld angegeben ist und der Wert auf oder nach dem `current moment - DeltaSyncTTL` liegt, wird ein `Query` auf der *Delta*-Tabelle ausgeführt. AWS AppSync gibt das `startedAt` Feld an die Antwortzuordnungsvorlage für alle `Sync` Operationen zurück. Das `startedAt`-Feld ist der Moment, in Epochenmillisekunden, an dem der `Sync`-Vorgang gestartet wurde, den Sie lokal speichern und in einer anderen Anforderung verwenden können. Wenn ein Paginierungstoken in der Anforderung enthalten war, entspricht dieser Wert dem Wert, der von der Anforderung für die erste Ergebnisseite zurückgegeben wird. Informationen zum Format für `Sync`-Zuweisungsvorlagen finden Sie in [der Zuweisungsvorlagen-Referenz](aws-appsync-resolver-mapping-template-reference-dynamodb-sync.md).