Auswahl der besten Größe für eine Replikations-Instance - AWS Database Migration Service
Zu berücksichtigende FaktorenHäufige ProblemeBewährte Methoden

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.

Auswahl der besten Größe für eine Replikations-Instance

Die Wahl der geeigneten Replikations-Instance hängt von mehreren Faktoren ab, die sich auf Ihren Anwendungsfall beziehen. Um zu verstehen, wie die Replikations-Instance-Ressourcen verwendet werden, lesen Sie die folgende Diskussion. Sie deckt das übliche Szenario einer Volllast + CDC-Aufgabe ab.

AWS DMS Lädt während einer Aufgabe zum vollständigen Laden die Tabellen einzeln. Standardmäßig werden acht Tabellen gleichzeitig geladen. AWS DMS erfasst laufende Änderungen an der Quelle während einer Aufgabe zum vollständigen Laden, sodass die Änderungen später auf dem Zielendpunkt angewendet werden können. Die Änderungen werden zwischengespeichert. Wenn der verfügbare Arbeitsspeicher erschöpft ist, werden die Änderungen auf der Festplatte zwischengespeichert. Wenn eine Vollladeaufgabe für eine Tabelle abgeschlossen ist, AWS DMS werden die zwischengespeicherten Änderungen sofort auf die Zieltabelle angewendet.

Nachdem alle ausstehenden zwischengespeicherten Änderungen für eine Tabelle übernommen wurden, befindet sich der Ziel-Endpunkt in einem transaktionskonsistenten Status. Zu diesem Zeitpunkt ist das Ziel in Bezug auf die letzten zwischengespeicherten Änderungen mit dem Quellendpunkt synchron. AWS DMS beginnt dann mit der laufenden Replikation zwischen der Quelle und dem Ziel. Dazu werden die AWS DMS Änderungsvorgänge aus den Quelltransaktionsprotokollen übernommen und auf transaktionskonsistente Weise auf das Ziel angewendet. (Bei diesem Vorgang wird davon ausgegangen, dass die Option „Batch-optimiert anwenden“ nicht ausgewählt ist). AWS DMS streamt laufende Änderungen nach Möglichkeit durch den Speicher der Replikationsinstanz. Andernfalls werden Änderungen auf die Festplatte der Replikationsinstanz AWS DMS geschrieben, bis sie auf das Ziel angewendet werden können.

Sie haben eine gewisse Kontrolle darüber, wie die Replikations-Instance die Änderungsverarbeitung handhabt und wie der Arbeitsspeicher bei diesem Prozess verwendet wird. Weitere Informationen zur Optimierung der Änderungsverarbeitung finden Sie unter Einstellungen für die Optimierung der Verarbeitung von Änderungen.

Zu berücksichtigende Faktoren

Arbeitsspeicher und Festplattenspeicher sind wichtige Faktoren bei der Auswahl einer geeigneten Replikations-Instance für Ihren Anwendungsfall. Im Folgenden finden Sie eine Beschreibung der Anwendungsfallmerkmale, die analysiert werden müssen, um eine Replikations-Instance auszuwählen.

  • Datenbank- und Tabellengröße

    Das Daten-Volume hilft bei der Bestimmung der Aufgabenkonfiguration, um die Leistung bei Volllast zu optimieren. Beispielsweise können Sie für zwei 1-TB-Schemata Tabellen in vier Aufgaben mit 500 GB partitionieren und diese parallel ausführen. Die mögliche Parallelität hängt von der CPU-Ressource ab, die in der Replikations-Instance verfügbar ist. Aus diesem Grund ist es eine gute Idee, die Größe Ihrer Datenbank und Ihrer Tabellen zu kennen, um die Leistung bei Volllast zu optimieren. Dies hilft, die Anzahl der Aufgaben zu bestimmen, die Sie möglicherweise haben können.

  • Große Objekte

    Die Datentypen, die in Ihrem Migrationsbereich vorhanden sind, können sich auf die Leistung auswirken. Insbesondere große Objekte (LOBs) wirken sich auf die Leistung und den Speicherverbrauch aus. AWS DMS Führt einen zweistufigen Prozess durch, um einen LOB-Wert zu migrieren. AWS DMS Fügt zunächst die Zeile ohne den LOB-Wert in das Ziel ein. Zweitens AWS DMS aktualisiert die Zeile mit dem LOB-Wert. Dies hat Auswirkungen auf den Speicher. Daher ist es wichtig, die LOB-Spalten an der Quelle zu identifizieren und ihre Größe zu analysieren.

  • Ladefrequenz und Transaktionsgröße

    Ladefrequenz und Transaktionen pro Sekunde (TPS) beeinflussen die Speichernutzung. Eine hohe Anzahl von TPS- oder DML-Aktivitäten (Data Manipulation Language) führt zu einer hohen Speicherauslastung. Dies geschieht, weil DMS die Änderungen zwischenspeichert, bis sie auf das Ziel angewendet werden. Während des CDC-Vorgangs führt dies zu Swapping (Schreiben auf die physische Festplatte aufgrund eines Speicherüberlaufs), was zu Latenz führt.

  • Tabellenschlüssel und referenzielle Integrität

    Informationen zu den Schlüsseln der Tabelle bestimmen den CDC-Modus (Batch Apply oder Transactional Apply), den Sie für die Datenmigration verwenden. Im Allgemeinen ist Transactional Apply langsamer als Batch Apply. Bei Transaktionen mit langer Laufzeit müssen möglicherweise viele Änderungen migriert werden. Wenn Sie transactional apply verwenden, ist AWS DMS möglicherweise mehr Speicher zum Speichern der Änderungen erforderlich als beim Batch-Anwenden. Wenn Sie Tabellen ohne Primärschlüssel migrieren, schlägt Batch Apply fehl und die DMS-Aufgabe wechselt in den Transactional-Apply-Modus. Wenn die referenzielle Integrität zwischen Tabellen während CDC aktiviert ist, AWS DMS verwendet standardmäßig transactional apply. Weitere Informationen zu Batch Apply im Vergleich zu Transactional Apply finden Sie unter Wie kann ich das DMS-Batch-Apply-Feature verwenden, um die CDC-Replikationsleistung zu verbessern?.

Ermitteln Sie anhand dieser Metriken, ob die Replikations-Instance datenverarbeitungs- oder speicheroptimiert sein muss.

Häufige Probleme

Möglicherweise stoßen Sie während der Migration auf die folgenden häufigen Probleme, die zu Ressourcenkonflikten auf der Replikations-Instance führen. Weitere Informationen zu Metriken für Replikations-Instances finden Sie unter Metriken zur Replikations-Instance.

  • Wenn der Arbeitsspeicher in einer Replikations-Instance nicht mehr ausreicht, führt dies dazu, dass Daten auf die Festplatte geschrieben werden. Das Lesen von der Festplatte kann zu Latenz führen, die Sie vermeiden können, indem Sie die Größe der Replikations-Instance mit ausreichend Arbeitsspeicher ausstatten.

  • Die der Replikations-Instance zugewiesene Festplattengröße kann kleiner als erforderlich sein. Die Festplattengröße wird verwendet, wenn Daten im Speicher überlaufen. Sie wird auch zum Speichern der Aufgabenprotokolle verwendet. Der maximale IOPS-Wert hängt ebenfalls davon ab.

  • Das Ausführen mehrerer Aufgaben oder von Aufgaben mit hoher Parallelität wirkt sich auf die CPU-Auslastung der Replikations-Instance aus. Dies verlangsamt die Verarbeitung der Aufgaben und führt zu Latenz.

Bewährte Methoden

Beachten Sie bei der Dimensionierung einer Replikations-Instance diese beiden gängigsten bewährten Methoden. Weitere Informationen finden Sie unter Bewährte Methoden für AWS Database Migration Service.

  1. Definieren Sie Ihren Workload und finden Sie heraus, ob er computing- oder speicherintensiv ist. Auf dieser Grundlage können Sie die Klasse und Größe der Replikations-Instance bestimmen:

    • AWS DMS verarbeitet LOBs im Speicher. Dieser Vorgang benötigt eine beträchtliche Menge an Arbeitsspeicher.

    • Die Anzahl der Aufgaben und die Anzahl der Threads wirken sich auf die CPU-Auslastung aus. Vermeiden Sie es, während des Volllastvorgangs mehr als acht MaxFullLoadSubTasks zu verwenden.

  2. Erhöhen Sie den der Replikations-Instance zugewiesenen Festplattenspeicher, wenn Sie bei Volllast einen hohen Workload haben. Auf diese Weise kann die Replikations-Instance den ihr zugewiesenen maximalen IOPS-Wert verwenden.

Die vorangegangenen Richtlinien decken nicht alle möglichen Szenarien ab. Es ist sehr wichtig, die Besonderheiten Ihres speziellen Anwendungsfalls zu berücksichtigen, wenn Sie die Größe Ihrer Replikations-Instance bestimmen.

Die vorherigen Tests haben gezeigt, dass CPU und Arbeitsspeicher je nach Workload variieren. Insbesondere LOBs wirken sich auf den Arbeitsspeicher aus und die Anzahl der Aufgaben oder die Parallelität wirken sich auf die CPU aus. Nachdem die Migration gestartet wurde, überwachen Sie die Werte für CPU, freigebbaren Arbeitsspeicher, freien Speicherplatz und E/A-Leistung pro Sekunde Ihrer Replikations-Instance. Basierend auf den Daten, die Sie erfassen, können Sie Ihre Replikations-Instance nach Bedarf vergrößern oder verkleinern.