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.
| 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 |
Für die Migration von KCL 3.x zum Einzeltabellenformat ist eine Bereitstellung in zwei Phasen erforderlich:
-
Phase 1: Stellen Sie den aktualisierten KCL 3.5-Code bereit, der auf
migrateAllEntitiesToLeaseTablegesetzt ist (Standardeinstellung).falseDadurch wird der neue Code installiert, der das Einzeltabellenformat unterstützt, die Migration jedoch nicht aktiviert. -
Phase 2: Nachdem alle Worker den neuen Code und die Reaches ausgeführt haben und Sie
TableMigrationStatussich vergewissert habenDEPLOYED, dass keine Regressionen vorliegen, führen Sie die Bereitstellung erneut mitmigrateAllEntitiesToLeaseTableset to durch, um die Migrationtruezu 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
| 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 |
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
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:
Operation |
Metrik |
Einheit |
Description |
|---|---|---|---|
|
|
Keine |
Ordnungszahl des aktuellen DynamoDB-Migrationsstatus: |
|
|
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:
Operation |
Metrik |
Einheit |
Description |
|---|---|---|---|
|
|
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. |
|
|
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. |
|
|
Anzahl |
Anzahl der Worker einer Version vor 3.5, die den Betrieb mit einer einzelnen DynamoDB-Tabelle nicht unterstützen. |
|
|
Anzahl |
|
|
|
Anzahl |
|
|
|
Anzahl |
|
|
|
Anzahl |
|
|
|
Millisekunden |
Dauer des asynchronen Verschiebungsvorgangs. |
|
|
Anzahl |
Anzahl der Stapel, die erfolgreich verschoben wurden. |
Während einer Migration geben alle Worker die folgenden Metriken aus:
Operation |
Metrik |
Einheit |
Description |
|---|---|---|---|
|
|
Anzahl |
|
|
|
Millisekunden |
Dauer des Zustandsautomaten-Laufs. |
|
|
Anzahl |
|
|
|
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 ist0, 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 (
TableMigrationStatusist festgelegtDEPLOYEDoder 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 (
TableMigrationStatusistDEPLOYEDoderPENDING): 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
DEPLOYEDden StatusTableMigration3.5erreicht hat. Stellen Sie sicher, dass keine Regressionen vorliegen, bevor Sie mit Phase 2 fortfahren. -
Überwachen Sie den Eintrag
TableMigrationStatusimTableMigration3.5Koordinatorstatus, 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.coordinatorStateTableConfigoder 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.
