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.
# Einzeltabellenformat für KCL
Ab KCL 3.5 können Sie alle DynamoDB-Metadaten mithilfe des Einzeltabellenformats in einer einzigen Leasetabelle konsolidieren. ** ** Standardmäßig erstellt KCL 3.x drei DynamoDB-Tabellen für jede Anwendung: die Leasing-Tabelle, die Worker-Metriktabelle und die Coordinator-State-Tabelle. Das Einzeltabellenformat reduziert diese drei Tabellen auf eine, wodurch Sie die Beschränkungen für DynamoDB-Tabellen auf Kontoebene umgehen können.
## So funktioniert das Einzeltabellenformat
Im Einzeltabellenformat speichert KCL neben den Leasingeinträgen auch Personalkennzahlen und Angaben zum Status der Koordinatoren in der Leasing-Tabelle. Jedes Element enthält ein `entityType` Attribut, das zwischen den verschiedenen Datensatztypen unterscheidet.
Kennzahlen für Arbeitskräfte und Angaben zum Status des Koordinators verwenden dieselbe Primärschlüsselstruktur wie die Leasing-Tabelle, enthalten jedoch einen anderen `entityType` Wert. Dieses Attribut ermöglicht es KCL, bei Tabellenscans den Verwendungszweck der einzelnen Artikel zu identifizieren.
Jede Komponente von KCL filtert auf der Grundlage des Attributs die Einträge heraus, die sie für ihre Geschäftslogik benötigt. `entityType` Beispielsweise filtert der Lease Assignment Manager (LAM) nach Leasing- und Worker-Metriken, um die Leasingzuweisung durchzuführen.
## Konfigurieren Sie das Format einer einzelnen Tabelle
Wie Sie das Einzeltabellenformat aktivieren, hängt von Ihrer aktuellen KCL-Version ab:
+ **Wenn Sie KCL 2.x verwenden: ** Folgen Sie der aktualisierten Migrationsanleitung, um auf KCL 3.5 zu aktualisieren. Das Einzeltabellenformat wird standardmäßig für neue Migrationen von 2.x auf 3.5 verwendet.
+ **Wenn Sie KCL 3.0—3.4 verwenden: ** Sie müssen eine zweiphasige Bereitstellung durchführen, um zum Einzeltabellenformat zu migrieren. Lesen Sie die folgenden Schritte zur Konfiguration und Migration.
Für bestehende KCL 3.x-Kunden stellen Sie die `migrateAllEntitiesToLeaseTable` Konfigurationsoption in ein. `CoordinatorConfig` Diese Option steuert, ob KCL alle Metadaten-Entitätstypen in der Leasing-Tabelle speichert.
**Konfigurationswerte für die Migration `AllEntitiesToLeaseTable`**
| Wert | Standard | Auswirkung |
| --- | --- | --- |
| false | Ja | KCL verwendet separate Tabellen für Worker-Metriken und den Koordinatorstatus. Der Anwendungscode unterstützt das Einzeltabellenformat, aktiviert es jedoch nicht. |
| true | Nein | KCL beginnt, Kennzahlen für Mitarbeiter und Daten zum Status der Koordinatoren in die Leasing-Tabelle zu schreiben. Setzen Sie diesen Wert bei der Bereitstellung in Phase 2 ein, nachdem Sie die Ziele `TableMigrationStatus` erreicht haben, `DEPLOYED` und schon sind Sie darauf vorbereitet, dass keine Regressionen mehr auftreten. |
Für die Migration von KCL 3.x zum Einzeltabellenformat ist eine Bereitstellung in zwei Phasen erforderlich:
1. **Phase 1: ** Stellen Sie den aktualisierten KCL 3.5-Code bereit, der auf `migrateAllEntitiesToLeaseTable` gesetzt ist (Standardeinstellung). `false` Dadurch wird der neue Code installiert, der das Einzeltabellenformat unterstützt, die Migration jedoch nicht aktiviert.
1. **Phase 2: ** Nachdem alle Worker den neuen Code und die Reaches ausgeführt haben und Sie `TableMigrationStatus` sich vergewissert haben`DEPLOYED`, dass keine Regressionen vorliegen, führen Sie die Bereitstellung erneut mit `migrateAllEntitiesToLeaseTable` set to durch, um die Migration `true` zu beginnen.
## Status der Migration
Das `TableMigrationStateMachine` verwaltet den Übergang vom Mehrtabellenformat zum Einzeltabellenformat. KCL verfolgt den aktuellen Migrationsstatus in einem separaten Koordinatorstatuseintrag, der `TableMigration3.5` in der Koordinatorstatustabelle aufgerufen wird. Eine vollständige Liste der Status, Übergänge und Beschreibungen finden Sie unter [ KCL Single Table Migration States](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/coordinator/migration/TableMigrationStatus.java).
**Migrationsstatus im Einzeltabellenformat**
| Status | Description | Übergangsbedingung |
| --- | --- | --- |
| INIT | Ausgangszustand. Alle Arbeiter geben den Mindestunterstützungscode in den Statistiken zur Arbeitermetrik aus. Die Mitarbeiter geben weiterhin Arbeitskennzahlen in die alte Tabelle ein und lesen die Arbeitskennzahlen und den Koordinatorstatus sowohl aus der alten Tabelle als auch aus den Leasing-Tabellen. Funktionell gibt es keinen Unterschied zwischen INIT und DEPLOYED. | Alle Worker geben während der Backzeit kontinuierlich den Mindest-Supportcode aus. Die Anwendung ist bereit, in die Phase 2-Bereitstellung überzugehen. |
| DEPLOYED | Alle Mitarbeiter wurden mit dem neuen Code eingesetzt (Phase 1 abgeschlossen). Die Anwendung unterstützt das Einzeltabellenformat, hat es jedoch nicht aktiviert. | Die Bereitstellung in Phase 2 beginnt mit der `migrateAllEntitiesToLeaseTable` Einstellung auf`true`. |
| PENDING | Alle Worker führen den neuen Code aus. KCL migriert Daten aus den Worker-Metriken und den Coordinator-Statustabellen in die Leasing-Tabelle. | Nach Abschluss der Migration vergeht eine Standard-Backzeit von 24 Stunden. |
| COMPLETE | Die Migration ist abgeschlossen. KCL verwendet die Leasetabelle ausschließlich für alle Lese- und Schreibvorgänge. Die alten Worker-Metriken und Koordinator-Statustabellen werden nicht mehr verwendet. | Endstatus. Es finden keine weiteren Übergänge statt. |
Detaillierte Informationen zu den einzelnen Zuständen, den Übergangsbedingungen und dem vollständigen Verhalten der Zustandsmaschine finden Sie unter [ KCL Single Table Migration State Machine](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client/src/main/java/software/amazon/kinesis/coordinator/migration/TableMigrationStatus.java).
**Anmerkung**
Die Standard-Backzeit zwischen den Zuständen PENDING und COMPLETE beträgt 24 Stunden, Sie können sie jedoch auf bis zu einer Woche konfigurieren. Während dieses Zeitraums verwendet KCL die Lease-Tabelle für alle Lese- und Schreibvorgänge, löscht die alten Tabellen jedoch nicht. Sie müssen die alten Worker-Metriken und Koordinator-Statustabellen manuell löschen, nachdem Sie bestätigt haben, dass die Migration erfolgreich war. KCL löscht diese Tabellen nicht automatisch.
## Metriken zur Migration
Mit KCL können Sie den Fortschritt und den Zustand der Migration einer einzelnen Tabelle mithilfe von CloudWatch Metriken überwachen. Verwenden Sie diese Metriken, um zu bestätigen, dass die Mitarbeiter den neuen Code übernommen haben, und um die Migration in ihren einzelnen Phasen zu verfolgen. Sie können während der Migration auch DynamoDB-Lese-, Schreib- oder Löschfehler erkennen. In den folgenden Tabellen sind die Metriken nach der KCL-Operation (metrische Dimension) gruppiert, die sie ausgibt, und danach, wann die einzelnen Metriken ausgegeben werden.
Der gewählte leitende Mitarbeiter gibt kontinuierlich die folgenden Kennzahlen aus, unabhängig davon, ob eine Migration im Gange ist:
**Von der Führungskraft zu jeder Zeit ausgegebene Kennzahlen**
| Operation | Metrik | Einheit | Description |
| --- | --- | --- | --- |
| `TableMigration` | `StatusOrdinal` | Keine | Ordnungszahl des aktuellen DynamoDB-Migrationsstatus: `0` = UNKNOWN, = INIT, `1` = DEPLOYED, `2` = PENDING, `3` = COMPLETE. `4` |
| `WorkerMetrics` | `FleetMinSupportCode` | Keine | Mindestunterstützungscode für alle Leasingnehmer in der Flotte. |
Der gewählte leitende Arbeitnehmer gibt nur während einer Migration die folgenden Kennzahlen aus:
**Metriken, die von der Führungskraft während der Migration ausgegeben werden**
| Operation | Metrik | Einheit | Description |
| --- | --- | --- | --- |
| `TableMigration` | `Phase1Worker` | Anzahl | Anzahl der Worker, die das Arbeiten mit einer einzelnen DynamoDB-Tabelle unterstützen, aber noch nicht auf die Verwendung einer einzigen Tabelle umgestellt haben. |
| `TableMigration` | `Phase2Worker` | Anzahl | Anzahl der Worker, die dazu übergegangen sind, in die einzige Tabelle zu schreiben. Diese Worker lesen möglicherweise immer noch aus mehreren Tabellen, bis die Tabellenmigration abgeschlossen ist. |
| `TableMigration` | `PrePhase1Worker` | Anzahl | Anzahl der Worker einer Version vor 3.5, die den Betrieb mit einer einzelnen DynamoDB-Tabelle nicht unterstützen. |
| `TableMigration` | `WriteFault` | Anzahl | `1`bei einem DynamoDB-Schreibfehler, bei Erfolg. `0` |
| `TableMigration` | `DeleteFault` | Anzahl | `1`bei einem DynamoDB-Löschfehler, bei Erfolg. `0` |
| `TableMigration` | `CompletionFault` | Anzahl | `1`wenn das transaktionale Schreiben des `COMPLETE` Status fehlschlägt, bei Erfolg. `0` |
| `TableMigrationAsyncMove` | `Success` | Anzahl | `1`bei einer erfolgreichen transaktionalen Übertragung von CoordinatorState Einträgen, bei einem Fehlschlag. `0` |
| `TableMigrationAsyncMove` | `Time` | Millisekunden | Dauer des asynchronen Verschiebungsvorgangs. |
| `TableMigrationAsyncMove` | `BatchCount` | Anzahl | Anzahl der Stapel, die erfolgreich verschoben wurden. |
Während einer Migration geben alle Worker die folgenden Metriken aus:
**Metriken, die von allen Mitarbeitern während der Migration ausgegeben werden**
| Operation | Metrik | Einheit | Description |
| --- | --- | --- | --- |
| `TableMigration` | `ReadFault` | Anzahl | `1`wenn das `TableMigrationState` aus DynamoDB nicht gelesen werden kann, `0` bei Erfolg. |
| `TableMigration` | `Time` | Millisekunden | Dauer des Zustandsautomaten-Laufs. |
| `TableMigrationInitialize` | `Success` | Anzahl | `1`bei erfolgreicher Initialisierung, `0` bei Fehlschlag. |
| `TableMigrationInitialize` | `Time` | Millisekunden | Dauer des Initialisierungsvorgangs. |
Verwenden Sie diese Metriken, um zu entscheiden, wann die Migration fortgesetzt werden soll. Wenn die `StatusOrdinal` Option konsistent `2` (DEPLOYED) `PrePhase1Worker` ist und ist`0`, unterstützen alle Worker das Einzeltabellenformat, und Sie können zu Phase 2 der Bereitstellung der Tabellenmigration übergehen. Nach `StatusOrdinal` Erreichen `4` (COMPLETE) können Sie die alten Tabellen problemlos löschen.
## Überlegungen zum Rollback
Die Rollback-Unterstützung hängt von folgenden Faktoren ab: `TableMigrationStatus`
+ **Während Phase 1 ** (`TableMigrationStatus`ist festgelegt `DEPLOYED` oder noch nicht festgelegt): Sie können problemlos zur vorherigen Version zurückkehren. Der neue Code wird in einem abwärtskompatiblen Modus ausgeführt, und es wurden keine Daten in Einträge in der Lease-Tabelle geschrieben, die nichts mit Leasing zu tun haben.
+ **Während Phase 2 ** (`TableMigrationStatus`ist `DEPLOYED` oder`PENDING`): Sie können zu Phase 1 zurückkehren. Die Mitarbeiter verwenden wieder die alten Tabellen (Format mit mehreren Tabellen) für die Kennzahlen der Mitarbeiter und den Status des Koordinators. Die Migration wird rückgängig gemacht.
+ **Nach dem Status ** COMPLETE: Rollback wird nicht unterstützt. KCL verwendet nur die Leasing-Tabelle für alle Entitäten. Selbst wenn der Code zu Phase 1 zurückkehrt, verwendet der Worker weiterhin die Leasing-Tabelle für alle Entitäten und die Konfiguration wird ignoriert.
**Warnung**
Nachdem die Migration den Status COMPLETE erreicht hat, arbeitet die Anwendung ausschließlich im Einzeltabellenmodus. Die `migrateAllEntitiesToLeaseTable` Konfiguration wird ignoriert, und KCL verwendet nicht wieder separate Tabellen. Stellen Sie sicher, dass die Backzeit ausreichend ist, bevor Sie zu COMPLETE wechseln, denn danach wechselt auch ein Code-Rollback nicht mehr zu mehreren Tabellen zurück.
## Bewährte Methoden
Folgen Sie diesen bewährten Methoden, wenn Sie das Format einer einzelnen Tabelle verwenden:
+ Stellen Sie nach der Bereitstellung in Phase 1 sicher, dass der Eintrag für den Koordinatorstatus `DEPLOYED` den Status `TableMigration3.5` erreicht hat. Stellen Sie sicher, dass keine Regressionen vorliegen, bevor Sie mit Phase 2 fortfahren.
+ Überwachen Sie den Eintrag `TableMigrationStatus` im `TableMigration3.5` Koordinatorstatus, um den Fortschritt in den Zuständen DEPLOYED, PENDING und COMPLETE nachzuverfolgen. Der Status wird in der Statustabelle des Koordinators als separater Eintrag (nicht in der Leasing-Tabelle) gespeichert, bis die Migration COMPLETE erreicht ist.
+ Stellen Sie sicher, dass die Backzeit ausreichend ist, bevor Sie zu COMPLETE wechseln, denn danach wechselt auch ein Code-Rollback nicht mehr zu mehreren Tabellen zurück. Die Anwendung funktioniert nur im Einzeltabellenmodus.
+ Wenn die Migration ABGESCHLOSSEN ist, löschen Sie die alten Worker-Metriken und Koordinator-Statustabellen manuell. KCL löscht diese Tabellen nicht automatisch, sondern verwendet sie nur nicht mehr.
+ Wenn Sie `CoordinatorConfig.coordinatorStateTableConfig` oder konfiguriert haben`LeaseManagementConfig.workerUtilizationAwareAssignmentConfig.workerMetricsTableConfig`, können Sie diese Konfigurationen nach Abschluss der Migration entfernen. Diese Konfigurationen sind in KCL 3.5 und höher veraltet.