View a markdown version of this page

Einzeltabellenformat für KCL - Amazon Kinesis Data Streams
So funktioniert das EinzeltabellenformatKonfigurieren Sie das Format einer einzelnen TabelleStatus der MigrationÜberlegungen zum RollbackBest Practices

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 Koordinatorstatustabelle. Das Einzeltabellenformat reduziert diese drei Tabellen auf eine, wodurch Sie Tabellenbeschränkungen auf DynamoDB-Account-Ebene vermeiden können.

So funktioniert das Einzeltabellenformat

Im Einzeltabellenformat speichert KCL neben den Leasingeinträgen auch Worker-Kennzahlen und Einträge zum Koordinatorstatus in der Leasing-Tabelle. Jedes Element enthält ein entityType Attribut, das zwischen den verschiedenen Datensatztypen unterscheidet.

Die Kennzahlen für Arbeitskräfte und Angaben zum Status des Koordinators verwenden dieselbe Primärschlüsselstruktur wie die Leasingtabelle, enthalten jedoch einen eigenen entityType Wert. Dieses Attribut ermöglicht es KCL, bei Tabellenscans den Verwendungszweck der einzelnen Elemente zu identifizieren.

Jede Komponente von KCL filtert anhand des Attributs die Einträge heraus, die sie für ihre Geschäftslogik benötigt. entityType Der Lease Assignment Manager (LAM) filtert beispielsweise nach Leasing- und Arbeitskräftekennzahlen, 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 dem aktualisierten Migrationsleitfaden, 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. Sehen Sie sich die folgenden Konfiguration und Migrationsschritte an.

Für bestehende KCL 3.x-Kunden legen Sie die migrateAllEntitiesToLeaseTable Konfigurationsoption unter fest. CoordinatorConfig Diese Option steuert, ob KCL alle Metadaten-Entitätstypen in der Leasetabelle speichert.

Konfigurationswerte für die Migration AllEntitiesToLeaseTable
Wert Standard Auswirkung
false Ja

KCL verwendet separate Tabellen für Worker-Metriken und den Status des Koordinators. Der Anwendungscode unterstützt das Einzeltabellenformat, aktiviert es jedoch nicht.
true Nein

KCL beginnt mit dem Schreiben von Arbeitskräftekennzahlen und Daten zum Koordinatorstatus in die Leasing-Tabelle. Wenn Sie diesen Wert für die Phase-2-Bereitstellung nach den TableMigrationStatus Erreichungen festlegen, haben Sie DEPLOYED alles getan, damit keine Regressionen auftreten.

Die Migration von KCL 3.x zum Einzeltabellenformat erfordert eine Bereitstellung in zwei Phasen:

  1. Phase 1: Stellen Sie den aktualisierten KCL 3.5-Code mit der migrateAllEntitiesToLeaseTable Einstellung auf false (Standard) bereit. Dadurch wird der neue Code installiert, der das Einzeltabellenformat unterstützt, die Migration jedoch nicht aktiviert.

  2. Phase 2: Nachdem alle Mitarbeiter den neuen Code und die Reaches ausgeführt haben und Sie TableMigrationStatus sich vergewissert habenDEPLOYED, dass keine Regressionen vorliegen, führen Sie die Implementierung erneut mit migrateAllEntitiesToLeaseTable set to durch, um mit der true Migration zu beginnen.

Status der Migration

Der TableMigrationStateMachine verwaltet den Übergang vom Mehrtabellenformat zum Einzeltabellenformat. KCL verfolgt den aktuellen Migrationsstatus in einem separaten Eintrag für den Koordinatorstatus, der TableMigration3.5 in der Koordinatorstatustabelle aufgerufen wird. Eine vollständige Liste der Status, Übergänge und Beschreibungen finden Sie unter Migrationsstatus in einer einzelnen Tabelle mit KCL-Migrationsstatus.

Migrationsstatus im Einzeltabellenformat
Status Description Übergangsbedingung
INIT

Ausgangszustand. Alle Mitarbeiter geben den Mindestunterstützungscode in den Metrikstatistiken für Arbeitnehmer aus. Mitarbeiter geben weiterhin Arbeitskräftekennzahlen in die alte Tabelle ein und lesen die Arbeitskräftekennzahlen und den Koordinatorstatus sowohl aus der alten Tabelle als auch aus der Leasingtabelle ab. Funktionell gesehen gibt es keinen Unterschied zwischen INIT und DEPLOYED.

Alle Mitarbeiter geben während der Backzeit kontinuierlich den Mindest-Supportcode aus. Die Anwendung ist bereit, zur 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 auftrue.
PENDING

Alle Mitarbeiter führen den neuen Code aus. KCL migriert Daten aus den Tabellen mit den Worker-Metriken und den Koordinatorstatus-Tabellen in die Leasing-Tabelle.

Nach Abschluss der Migration wird eine standardmäßige Backzeit von 24 Stunden verstrichen.
COMPLETE

Die Migration ist abgeschlossen. KCL verwendet die Leasetabelle ausschließlich für alle Lese- und Schreibvorgänge. Die alten Tabellen mit Mitarbeiterkennzahlen und Koordinatorstatus werden nicht mehr verwendet.

Terminalstatus. Es finden keine weiteren Übergänge statt.

Ausführliche Informationen zu den einzelnen Zuständen, den Übergangsbedingungen und dem vollständigen Verhalten von Zustandsmaschinen finden Sie unter KCL Single Table Migration State Machine.

Anmerkung

Die Standardzeit zwischen den Zuständen PENDING und COMPLETE beträgt 24 Stunden, Sie können sie jedoch auf bis zu einer Woche festlegen. Während dieses Zeitraums verwendet KCL die Leasetabelle für alle Lese- und Schreibvorgänge, löscht jedoch nicht die alten Tabellen. Sie müssen die alten Worker-Metriken und Koordinatorstatustabellen manuell löschen, nachdem Sie bestätigt haben, dass die Migration erfolgreich war. KCL löscht diese Tabellen nicht automatisch.

Überlegungen zum Rollback

Die Rollback-Unterstützung hängt von der aktuellen Version ab: TableMigrationStatus

  • Während Phase 1 (TableMigrationStatusist 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 die Leasetabelle geschrieben, die keine Leasingeinträge sind.

  • Während Phase 2 (TableMigrationStatusist DEPLOYED oderPENDING): Sie können zu Phase 1 zurückkehren. Mitarbeiter verwenden wieder die alten Tabellen (Format mit mehreren Tabellen) für Arbeitskräftekennzahlen und den Status der Koordinatoren. Die Migration wurde rückgängig gemacht.

  • Status nach COMPLETE: Rollback wird nicht unterstützt. KCL verwendet nur die Leasetabelle für alle Entitäten. Selbst wenn der Code zu Phase 1 zurückkehrt, verwendet der Worker weiterhin die Leasetabelle für alle Entitäten und die Konfiguration wird ignoriert.

Warnung

Sobald 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, da selbst ein Code-Rollback danach nicht zu mehreren Tabellen zurückwechselt.

Best Practices

Folgen Sie diesen bewährten Methoden, wenn Sie das Einzeltabellenformat verwenden:

  • Stellen Sie nach der Bereitstellung in Phase 1 sicher, dass der Eintrag im Koordinatorstatus DEPLOYED den Status TableMigration3.5 erreicht hat. Stellen Sie sicher, dass keine Regressionen vorliegen, bevor Sie mit Phase 2 fortfahren.

  • Überwachen Sie den Status TableMigrationStatus im TableMigration3.5 Koordinator, um die Fortschritte in den Zuständen DEPLOYED, PENDING und COMPLETE zu verfolgen. Der Status wird in der Tabelle mit dem Status des Koordinators als separater Eintrag gespeichert (nicht in der Tabelle „Lease“), bis die Migration den Status ABGESCHLOSSEN erreicht.

  • Stellen Sie sicher, dass die Backzeit ausreichend ist, bevor Sie zu COMPLETE wechseln, da selbst nach einem Code-Rollback nicht zu mehreren Tabellen zurückgeschaltet wird. Die Anwendung funktioniert nur im Einzeltabellenmodus.

  • Wenn die Migration ABGESCHLOSSEN ist, löschen Sie manuell die alten Tabellen mit den Worker-Metriken und den Koordinatorstatus. KCL löscht diese Tabellen nicht automatisch, sondern verwendet sie nur nicht mehr.

  • Wenn Sie CoordinatorConfig.coordinatorStateTableConfig oder konfiguriert habenLeaseManagementConfig.workerUtilizationAwareAssignmentConfig.workerMetricsTableConfig, können Sie diese Konfigurationen nach Abschluss der Migration entfernen. Diese Konfigurationen sind in KCL 3.5 und höher veraltet.