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.
Funktionsweise von Aurora Serverless v2
Die folgende Übersicht beschreibt die Funktionsweise von Aurora Serverless v2.
Themen
Übersicht über Aurora Serverless v2
Amazon Aurora Serverless v2 eignet sich für die anspruchsvollsten, sehr variablen Workloads. Zum Beispiel könnte Ihre Datenbanknutzung für einen kurzen Zeitraum sehr hoch sein, gefolgt von langen Zeiträumen mit nur leichter oder gar keiner Aktivität. Beispiele hierfür sind Einzelhandels-Websites, Spiele oder Sportveranstaltungen mit regelmäßigen Werbeveranstaltungen sowie Datenbanken, die nach Bedarf Berichte erstellen. Andere Beispiele sind Entwicklungs- und Testumgebungen sowie neue Anwendungen, in denen die Nutzung schnell ansteigen könnte. In Fällen wie diesen und vielen anderen ist es mit dem bereitgestellten Modell nicht immer möglich, die Kapazität vorab korrekt zu konfigurieren. Es können auch höhere Kosten entstehen, wenn Sie zu viel Kapazität bereitstellen, die Sie dann nicht benötigen.
Im Gegensatz dazu sind von Aurora bereitgestellte Cluster für stetige Workloads geeignet. Bei bereitgestellten Clustern wählen Sie eine DB-Instance-Klasse aus, die über eine vordefinierte Menge an Arbeitsspeicher, CPU-Leistung, I/O Bandbreite usw. verfügt. Wenn sich Ihre Workload ändert, ändern Sie die Instance-Klasse Ihres Writers und Ihrer Readers manuell. Das bereitgestellte Modell funktioniert gut, wenn Sie die Kapazität im Vorfeld der erwarteten Verbrauchsmustern anpassen können. Es ist akzeptabel, dass kurze Ausfälle auftreten, während Sie die Instance-Klasse des Writers und der Reader in Ihrem Cluster ändern.
Aurora Serverless v2 ist von Grund auf so konzipiert, dass serverlose DB-Cluster unterstützt werden, die sofort skalierbar sind. Aurora Serverless v2 wurde entwickelt, um das gleiche Maß an Sicherheit und Isolation zu bieten wie mit bereitgestellten Writern und Readern. Diese Aspekte sind in serverlosen Cloud-Umgebungen mit mehreren Mandanten entscheidend. Der dynamische Skalierungsmechanismus umfasst sehr wenig Aufwand, sodass er schnell auf Änderungen der Datenbank-Workload reagieren kann. Er bietet auch genügend Leistung, um einen drastischen Anstieg beim Bedarf nach Rechenleistung zu meistern.
Durch die Verwendung von Aurora Serverless v2 können Sie einen Aurora-DB-Cluster erstellen, ohne für jeden Writer und Reader an eine bestimmte Datenbankkapazität gebunden zu sein. Sie geben den minimalen und maximalen Bereich für die Kapazität an. Aurora skaliert jeden Aurora Serverless v2-Writer oder -Reader im Cluster innerhalb dieses Kapazitätsbereichs. Durch die Verwendung eines Multi-AZ-Clusters, in dem jeder Writer oder Reader dynamisch skalieren kann, können Sie die dynamische Skalierung und Hochverfügbarkeit nutzen.
Aurora Serverless v2 skaliert die Datenbankressourcen automatisch basierend auf Ihren minimalen und maximalen Kapazitätsspezifikationen. Die Skalierung ist schnell, da die meisten Skalierungsereignisoperationen den Writer oder Reader auf demselben Host halten. In seltenen Fällen, in denen ein Aurora Serverless v2-Writer oder -Reader von einem Host zu einem anderen verschoben wird, verwaltet Aurora Serverless v2 die Verbindungen automatisch. Sie müssen Ihren Datenbank-Client-Anwendungscode oder Ihre Datenbank-Verbindungszeichenfolgen nicht ändern.
Wie bei bereitgestellten Clustern sind bei Aurora Serverless v2 Speicherkapazität und Rechenkapazität getrennt. Wenn wir uns auf Aurora Serverless v2-Kapazität und -Skalierung beziehen, geht es immer um die Rechenkapazität, die zunimmt oder abnimmt. Somit kann Ihr Cluster viele Terabyte an Daten enthalten, auch wenn die CPU und Speicherkapazität auf ein niedriges Niveau herunterskalieren.
Anstelle der Bereitstellung und Verwaltung von Datenbankservern geben Sie die Datenbankkapazität an. Details zur Aurora Serverless v2-Kapazität finden Sie unter Kapazität von Aurora Serverless v2. Die tatsächliche Kapazität jedes Aurora Serverless v2-Writers oder -Readers variiert im Laufe der Zeit, je nach Workload. Details zu diesem Mechanismus finden Sie unter Aurora Serverless v2-Skalierung.
Wichtig
Mit Aurora Serverless v1 verfügt Ihr Cluster über eine einzige Maßeinheit für die Rechenkapazität, die zwischen den minimalen und maximalen Kapazitätswerten skaliert werden kann. Mit Aurora Serverless v2 kann Ihr Cluster zusätzlich zum Writer auch Reader enthalten. Jeder Aurora Serverless v2-Writer und -Reader kann zwischen minimalen und maximalen Kapazitätswerten skalieren. Somit hängt die Gesamtkapazität Ihres Aurora Serverless v2-Clusters sowohl vom Kapazitätsbereich ab, den Sie für Ihren DB-Cluster definieren, als auch von der Anzahl der Writer und Reader im Cluster. Zu jedem Zeitpunkt wird Ihnen nur die Aurora Serverless v2-Kapazität in Rechnung gestellt, die in Ihrem Aurora-DB-Cluster aktiv genutzt wird.
Konfigurationen für Aurora-DB-Cluster
Für jeden Ihrer Aurora DB-Cluster können Sie eine beliebige Kombination von Aurora Serverless v2-Kapazität, bereitgestellter Kapazität oder beides auswählen.
Sie können einen Cluster einrichten, der beides enthält, Aurora Serverless v2 und bereitgestellte Kapazität. Dies wird als Cluster mit gemischter Konfiguration bezeichnet. Nehmen wir zum Beispiel an, dass Sie mehr read/write Kapazität benötigen, als für einen Aurora Serverless v2 Writer verfügbar ist. In diesem Fall können Sie den Cluster mit einem sehr großen bereitgestellten Writer einrichten. Sie können in diesem Fall immer noch Aurora Serverless v2 für die Reader verwenden. Oder nehmen Sie an, dass die Schreib-Workload für Ihren Cluster variiert, die Lese-Workload jedoch stabil ist. In diesem Fall können Sie Ihren Cluster mit einem Aurora Serverless v2-Writer und einem oder mehreren bereitgestellten Readern einrichten.
Sie können auch einen DB-Cluster einrichten, bei dem die gesamte Kapazität von Aurora Serverless v2 verwaltet wird. Dazu können Sie einen neuen Cluster erstellen und von Anfang an Aurora Serverless v2 verwenden. Oder Sie können die gesamte bereitgestellte Kapazität in einem vorhandenen Cluster durch Aurora Serverless v2 ersetzen. Einige der Upgrade-Pfade älterer Engine-Versionen erfordern z. B., mit einem bereitgestellten Writer zu beginnen und ihn durch einen Aurora Serverless v2-Writer zu ersetzen. Informationen zu den Verfahren zum Erstellen eines neuen DB-Clusters mit Aurora Serverless v2 oder zum Wechseln eines vorhandenen DB-Cluster auf Aurora Serverless v2 finden Sie unter Erstellen einer Aurora Serverless v2 DB-Cluster und Wechsel von einem bereitgestellten Cluster zu Aurora Serverless v2.
Wenn Sie Aurora Serverless v2 in einem DB-Cluster überhaupt nicht verwenden, sind alle Writer und Reader im DB-Cluster bereitgestellt. Dies ist die älteste und gebräuchlichste Art von DB-Cluster, mit der die meisten Benutzer vertraut sind. Vor Einführung von Aurora Serverless gab es tatsächlich keinen besonderen Namen für diese Art von Aurora-DB-Cluster. Die bereitgestellte Kapazität ist konstant. Die Gebühren sind relativ einfach zu prognostizieren. Sie müssen jedoch im Vorfeld prognostizieren, wie viel Kapazität Sie benötigen. In einigen Fällen sind Ihre Prognosen möglicherweise ungenau oder Ihr Kapazitätsbedarf kann sich ändern. In diesen Fällen kann Ihr DB-Cluster unterdimensioniert (langsamer als gewünscht) oder überdimensioniert (teurer als gewünscht) sein.
Kapazität von Aurora Serverless v2
Die Maßeinheit für Aurora Serverless v2 ist die Aurora-Kapazitätseinheit (ACU). Die Kapazität von Aurora Serverless v2 ist nicht an die DB-Instance-Klassen gebunden, die Sie für bereitgestellte Cluster verwenden.
Jede ACU ist eine Kombination aus etwa 2 Gibibyte (GiB) Arbeitsspeicher, entsprechender CPU und Netzwerkleistung. Mit dieser Maßeinheit geben Sie den Kapazitätsbereich der Datenbank an. Die Metriken ServerlessDatabaseCapacity
und ACUUtilization
helfen Ihnen festzustellen, wie viel Kapazität Ihre Datenbank tatsächlich nutzt und wo diese Kapazität innerhalb des angegebenen Bereichs liegt.
Zu jedem Zeitpunkt verfügt jeder Aurora Serverless v2-DB-Writer oder -Reader über eine Kapazität. Die Kapazität wird als Gleitkommazahl dargestellt. ACUs Die Kapazität steigt oder nimmt ab, sobald der Writer oder Reader skaliert. Dieser Wert wird jede Sekunde gemessen. Für jeden DB-Cluster, für den Sie Aurora Serverless v2 verwenden möchten, definieren Sie einen Kapazitätsbereich: Die minimalen und maximalen Kapazitätswerte, zwischen denen jeder Aurora Serverless v2-Writer oder -Reader skalieren kann. Der Kapazitätsbereich ist für jeden Aurora Serverless v2-Writer oder -Reader in einem DB-Cluster gleich. Jeder Aurora Serverless v2-Writer oder -Reader hat eine eigene Kapazität, die in diesen Bereich fällt.
Die folgende Tabelle zeigt die Aurora Serverless v2 Kapazitätsbereiche und die Unterstützung der Engine-Versionen für Aurora MySQL und Aurora PostgreSQL.
Kapazitätsbereich () ACUs | Von Aurora MySQL unterstützte Versionen | Unterstützte Versionen von Aurora PostgreSQL |
---|---|---|
0,5—128 | 3.02.0 und höher | 13.6 und höher, 14.3 und höher, 15.2 und höher, 16.1 und höher |
0,5—256 | 3.06.0 und höher | 13.13 und höher, 14.10 und höher, 15.5 und höher, 16.1 und höher |
0—256 | 3.08.0 und höher | 13.15 und höher, 14.12 und höher, 15.7 und höher, 16.3 und höher |
Die folgende Tabelle zeigt die Aurora Serverless v2 Plattformversionen mit ihren ACU-Bereichen und Leistungsmerkmalen.
Aurora Serverless v2-Plattformversion | ACU-Reihe | Leistung |
---|---|---|
1 | 0—128 | Basisleistung |
2 | 0—256 | Basisleistung |
3 | 0—256 | Bis zu 30% verbesserte Leistung im Vergleich zu Plattformversion 2 |
Anmerkung
Der verfügbare Skalierungsbereich für einen bestimmten Cluster wird sowohl von der Engine-Version als auch von der Plattformversion bestimmt. Es ist möglich, eine leistungsfähigere Engine-Version auf einer weniger leistungsfähigen Plattformversion laufen zu lassen und umgekehrt. Der Skalierungsbereich wird durch die Engine- oder Plattformversion mit der niedrigsten Kapazität bestimmt.
Sie können im Abschnitt Instanzkonfiguration der AWS Management Console oder über die API feststellen, auf welcher Plattformversion Ihr Cluster ausgeführt wird, indem Sie sich das ServerlessV2PlatformVersion
für a ansehen DBCluster.
Die kleinste Aurora Serverless v2 Kapazität, die Sie definieren können, ist 0 für Aurora Serverless v2 Versionen ACUs, die die automatische Pause-Funktion unterstützen. Sie können eine größere Zahl angeben, wenn sie kleiner oder gleich Ihrem maximalen Kapazitätswert ist. Wenn Sie die Mindestkapazität auf eine kleine Zahl festlegen, können leicht geladene DB-Cluster minimale Rechenressourcen verbrauchen. Gleichzeitig bleiben sie bereit, Verbindungen sofort anzunehmen und hochzuskalieren, wenn ihre Aktivität ansteigt.
Wir empfehlen, das Minimum auf einen Wert festzulegen, der es jedem DB-Writer oder -Reader ermöglicht, den Arbeitssatz der Anwendung im Pufferpool zu halten. Auf diese Weise wird der Inhalt des Pufferpools in Zeiten geringer Aktivität nicht verworfen. Alle Überlegungen zur Auswahl des minimalen Kapazitätswerts finden Sie unter Auswählen der minimalen Aurora Serverless v2-Kapazitätseinstellung für einen Cluster. Alle Überlegungen zur Auswahl des maximalen Kapazitätswerts finden Sie unter Auswählen der maximalen Aurora Serverless v2-Kapazitätseinstellung für einen Cluster.
Je nachdem, wie Sie die Leser in einer Multi-AZ-Bereitstellung konfigurieren, können ihre Kapazitäten an die Kapazität des Schreibers gebunden oder unabhängig voneinander genutzt werden. Weitere Informationen zur Vorgehensweise finden Sie unter Aurora Serverless v2-Skalierung.
Die Überwachung von Aurora Serverless v2 umfasst die Messung der Kapazitätswerte für den Writer und die Reader in Ihrem DB-Cluster im Zeitverlauf. Wenn Ihre Datenbank nicht auf die Mindestkapazität herunterskaliert, können Sie Maßnahmen ergreifen, z. B. den minimalen Wert anpassen und Ihre Datenbankanwendung optimieren. Wenn Ihre Datenbank ihre maximale Kapazität konsequent erreicht, können Sie Maßnahmen wie die Erhöhung des maximalen Werts ergreifen. Sie können auch Ihre Datenbankanwendung optimieren und die Abfragelast auf mehr Reader verteilen.
Die Gebühren für die Aurora Serverless v2-Kapazität werden in Form von ACU-Stunden gemessen. Informationen darüber, wie Aurora Serverless v2-Gebühren berechnet werden, finden Sie auf der Seite Aurora-Preisübersicht
Angenommen, die Gesamtzahl der Autoren und Leser in Ihrem Cluster beträgtn
. In diesem Fall verbraucht der Cluster ungefähr, n x
wenn Sie keine Datenbankoperationen ausführen. Aurora selbst führt möglicherweise Überwachungs- oder Wartungsvorgänge durch, die eine geringe Last verursachen. Dieser Cluster verbraucht nicht mehr als minimum ACUs
n x
, wenn die Datenbank mit voller Kapazität läuft.maximum ACUs
Weitere Informationen zur Auswahl geeigneter minimaler und maximaler ACU-Werte finden Sie unter Auswählen des Aurora Serverless v2-Kapazitätsbereichs für einen Aurora-Cluster. Die minimalen und maximalen ACU-Werte, die Sie angeben, wirken sich auch auf die Funktionsweise einiger Aurora-Konfigurationsparameter für Aurora Serverless v2 aus. Weitere Informationen zur Wechselwirkung zwischen dem Kapazitätsbereich und den Konfigurationsparametern finden Sie unter Arbeiten mit Parametergruppen für Aurora Serverless v2.
Aurora Serverless v2-Skalierung
Für jeden Aurora Serverless v2-Writer oder -Reader verfolgt Aurora kontinuierlich die Auslastung von Ressourcen wie CPU, Arbeitsspeicher und Netzwerk. Diese Messungen werden zusammen als Last bezeichnet. Die Last umfasst die von Ihrer Anwendung ausgeführten Datenbankoperationen. Außerdem umfasst sie auch die Hintergrundverarbeitung für den Datenbankserver und Aurora-Verwaltungsaufgaben. Wenn die Kapazität durch einen dieser Faktoren eingeschränkt wird, wird Aurora Serverless v2 hochskaliert. Aurora Serverless v2 skaliert auch hoch, wenn Leistungsprobleme erkannt werden, die dadurch gelöst werden können. Sie können die Ressourcenauslastung und deren Auswirkung auf die Aurora Serverless v2-Skalierung überwachen, indem Sie die Verfahren in Wichtige CloudWatch Amazon-Metriken für Aurora Serverless v2 und Überwachung der Aurora Serverless v2-Leistung mit Performance Insights verwenden.
Die Last kann je nach Writer und Reader in Ihrem DB-Cluster variieren. Der Writer verarbeitet alle DDL-Anweisungen (Data Definition Language), wie CREATE TABLE
,ALTER TABLE
und DROP
TABLE
. Außerdem verarbeitet der Writer alle DML-Anweisungen (Data Manipulation Language), wie INSERT
und UPDATE
. Reader können schreibgeschützte Anweisungen verarbeiten, z. B. SELECT
-Abfragen.
Skalierung ist die Operation, die die Aurora Serverless v2-Kapazität für Ihre Datenbank erhöht oder senkt. Damit Aurora Serverless v2 hat jeder Schreiber und jeder Leser seinen eigenen aktuellen Kapazitätswert, gemessen in ACUs. Aurora Serverless v2skaliert einen Schreib- oder Lesegerät auf eine höhere Kapazität, wenn die aktuelle Kapazität zu gering ist, um die Last zu bewältigen. Der Writer oder Reader wird auf eine geringere Kapazität skaliert, wenn seine aktuelle Kapazität höher als erforderlich ist.
Im Gegensatz zu Aurora Serverless v1, bei der skaliert wird, indem die Kapazität bei jedem Erreichen eines Schwellenwerts verdoppelt wird, kann Aurora Serverless v2 die Kapazität inkrementell erhöhen. Wenn Ihr Workload-Bedarf beginnt, die aktuelle Datenbankkapazität eines Schreibers oder Lesegeräts zu erreichen, Aurora Serverless v2 erhöht sich die Anzahl der ACUs für diesen Schreiber oder Leser. Aurora Serverless v2skaliert die Kapazität in den erforderlichen Schritten, um die beste Leistung für die verbrauchten Ressourcen zu erzielen. Die Skalierung erfolgt in Schritten von nur 0,5. ACUs Je größer die aktuelle Kapazität, desto größer ist das Skalierungsinkrement und desto schneller kann die Skalierung erfolgen.
Da die Aurora Serverless v2 Skalierung so häufig, detailliert und unterbrechungsfrei erfolgt, verursacht sie keine diskreten Ereignisse, wie dies AWS Management Console der Fall ist. Aurora Serverless v1 Stattdessen können Sie die CloudWatch Amazon-Metriken wie ServerlessDatabaseCapacity
und messen ACUUtilization
und deren Mindest-, Höchst- und Durchschnittswerte im Laufe der Zeit verfolgen. Weitere Informationen über Aurora-Metriken finden Sie unter Überwachung von Metriken in einem Amazon-Aurora-Cluster. Tipps zur Überwachung von Aurora Serverless v2 finden Sie unter Wichtige CloudWatch Amazon-Metriken für Aurora Serverless v2.
Sie können wählen, ob ein Reader gleichzeitig mit dem zugehörigen Writer oder unabhängig vom Writer skalieren soll. Dazu geben Sie die Hochstufungsstufe für diesen Reader an.
-
Reader in den Hochstufungsstufen 0 und 1 skalieren gleichzeitig mit dem Writer. Dieses Skalierungsverhalten macht Reader in den Prioritätsstufen 0 und 1 ideal verfügbar. Das liegt daran, dass sie immer auf die richtige Kapazität dimensioniert sind, um die Workload des Writers im Falle eines Failovers zu übernehmen.
-
Reader der Hochstufungsstufen 2 bis 15 skalieren unabhängig vom Writer. Jeder Reader bleibt innerhalb der minimalen und maximalen ACU-Werte, die Sie für Ihren Cluster angegeben haben. Wenn ein Reader unabhängig von der zugehörigen Writer-DB skaliert, kann er inaktiv werden und herunterskalieren, während der Writer weiterhin ein hohes Transaktionsvolumen verarbeitet. Er ist nach wie vor als Failover-Ziel verfügbar, wenn keine anderen Reader in niedrigeren Hochstufungsstufen zur Verfügung stehen. Wenn der Reader jedoch zum Writer hochgestuft wird, muss er möglicherweise hochskalieren, um die volle Workload des Writers zu bewältigen.
Weitere Informationen zu Hochstufungsstufen finden Sie unter Auswählen der Hochstufungsstufe für einen Aurora Serverless v2-Reader.
Die Begriffe Skalierungpunkte und zugehörige Timeout-Perioden von Aurora Serverless v1 finden in Aurora Serverless v2 keine Anwendung. Die Aurora Serverless v2-Skalierung kann auftreten, während Datenbankverbindungen geöffnet sind, während SQL-Transaktionen in Bearbeitung sind, während Tabellen gesperrt sind und während temporäre Tabellen verwendet werden. Aurora Serverless v2 wartet nicht auf einen Ruhepunkt, um mit der Skalierung zu beginnen. Die Skalierung unterbricht keine laufenden Datenbankoperationen.
Wenn Ihre Workload mehr Lesekapazität benötigt, als mit einem einzigen Writer und einem einzigen Reader verfügbar ist, können Sie dem Cluster mehrere Aurora Serverless v2-Reader hinzufügen. Jeder Aurora Serverless v2-Reader kann innerhalb der minimalen und maximalen Kapazitätswerte skalieren, die Sie für Ihren DB-Cluster angegeben haben. Sie können den Reader-Endpunkt des Clusters verwenden, um schreibgeschützte Sitzungen an die Reader zu leiten und die Last des Writers zu reduzieren.
Ob Aurora Serverless v2 die Skalierung durchführt und wie schnell die Skalierung nach dem Start erfolgt, hängt auch von den minimalen und maximalen ACU-Einstellungen für den Cluster ab. Darüber hinaus hängt es davon ab, ob ein Reader so konfiguriert ist, dass er zusammen mit dem Writer oder unabhängig davon skaliert wird. Details zu den Faktoren, die Auswirkungen auf die Aurora Serverless v2-Skalierung haben, finden Sie unter Performance und Skalierung für Aurora Serverless v2.
Skalierung auf Null
In den neuesten Versionen von Aurora MySQL und Aurora PostgreSQL können Aurora Serverless v2 Autoren und Leser bis auf Null herunterskalieren. ACUs Wir bezeichnen diese Funktion als automatische Pause und Wiederaufnahme oder automatische Pause. Sie können wählen, ob Sie dieses Verhalten zulassen möchten, indem Sie für die Mindestkapazität einen Wert von Null oder einen Wert ungleich Null angeben. Sie können auch wählen, wie lange gewartet werden soll, bis eine Aurora Serverless v2 Instance angehalten wird. Informationen darüber, welche Versionen über diese Funktion verfügen, finden Sie unterKapazität von Aurora Serverless v2. Hinweise zur effektiven Verwendung finden Sie unterSkalierung auf Null ACUs mit automatischer Pause und Wiederaufnahme für Aurora Serverless v2.
In älteren Versionen von Aurora MySQL und Aurora PostgreSQL können ungenutzte Aurora Serverless v2 Schreib- und Lesegeräte auf den ACU-Mindestwert herunterskaliert werden, den Sie für den Cluster angegeben haben, aber nicht bis auf Null. ACUs In diesem Fall steht Null ACUs nicht als Option zur Verfügung, wenn Sie den Kapazitätsbereich festlegen. Dieses Verhalten ist anders als bei Aurora Serverless v1, bei der nach einer Zeit der Inaktivität eine Pause erfolgen kann, aber dann einige Zeit benötigt wird, den Betrieb fortzusetzen, wenn Sie eine neue Verbindung öffnen.
Wenn Ihr DB-Cluster mit Aurora Serverless v2 Kapazität für einige Zeit nicht benötigt wird, können Sie auch den gesamten Cluster stoppen und starten, genau wie bei bereitgestellten DB-Clustern. Diese Technik eignet sich am besten für Entwicklungs- und Testsysteme, bei denen sie möglicherweise viele Stunden am Stück nicht benötigt werden und die Geschwindigkeit, mit der der Cluster wieder aufgenommen wird, nicht entscheidend ist. Die stop/start Cluster-Funktion ist für alle Aurora Serverless v2 Versionen verfügbar. Weitere Informationen zu dieser Funktion finden Sie unterStoppen und Starten eines Amazon Aurora-DB-Clusters.
Aurora Serverless v2 und hohe Verfügbarkeit
Hohe Verfügbarkeit für einen Aurora-DB-Cluster wird erreicht, indem Sie ihn zu einem Multi-AZ-DB-Cluster hochstufen. Ein Multi-AZ-Aurora-DB-Cluster verfügt jederzeit über Rechenkapazität in mehr als einer Availability Zone (AZ). Diese Konfiguration hält Ihre Datenbank auch im Falle eines größeren Ausfalls betriebsbereit. Aurora führt ein automatisches Failover im Falle eines Problems durch, das den Writer oder sogar die gesamte AZ betrifft. Mit Aurora Serverless v2 können Sie wählen, ob die Standby-Rechenkapazität zusammen mit der Kapazität des Schreibers hoch- oder herunterskaliert werden soll. Auf diese Weise ist die Rechenkapazität in der zweiten AZ bereit, die aktuelle Workload jederzeit zu übernehmen. Gleichzeitig AZs kann die gesamte Rechenkapazität herunterskaliert werden, wenn sich die Datenbank im Leerlauf befindet. Einzelheiten zur Zusammenarbeit von Aurora mit Availability Zones AWS-Regionen und Availability Zones finden Sie unterHohe Verfügbarkeit für Aurora-DB-Instances.
Die Aurora Serverless v2-Multi-AZ-Fähigkeit verwendet Reader zusätzlich zum Writer. Die Unterstützung für Reader ist neu für Aurora Serverless v2 im Gegensatz zu Aurora Serverless v1. Sie können einem Aurora-DB-Cluster bis AZs zu 15 Aurora Serverless v2 Leser hinzufügen, die auf 3 verteilt sind.
Für geschäftskritische Anwendungen, die auch im Falle eines Problems, das Ihren gesamten Cluster oder die gesamte AWS Region betrifft, verfügbar bleiben müssen, können Sie eine globale Aurora-Datenbank einrichten. Sie können Aurora Serverless v2-Kapazität in den sekundären Clustern verwenden, damit sie im Falle einer Notfallwiederherstellung zur Übernahme bereit sind. Sie können auch herunterskalieren, wenn die Datenbank nicht ausgelastet ist. Weitere Informationen zu globalen Aurora-Datenbanken finden Sie unter Verwenden der Amazon Aurora Global Database.
Aurora Serverless v2 funktioniert wie für Failover und andere Hochverfügbarkeitsfunktionen bereitgestellt. Weitere Informationen finden Sie unter Hohe Verfügbarkeit für Amazon Aurora.
Angenommen, Sie möchten maximale Verfügbarkeit für Ihre Aurora Serverless v2-Cluster sicherstellen. Sie können zusätzlich zum Writer einen Reader erstellen. Wenn Sie dem Reader die Hochstufungsstufe 0 oder 1 zuweisen, geschieht jede Skalierung sowohl für den Writer als auch für den Reader. Auf diese Weise ist ein Reader mit identischer Kapazität im Falle eines Failovers immer zur Übernahme für den Writer bereit.
Angenommen, Sie möchten Quartalsberichte für Ihr Unternehmen erstellen, während Ihr Cluster weiterhin Transaktionen verarbeitet. Wenn Sie dem Cluster einen Aurora Serverless v2-Reader hinzufügen und ihm eine Hochstufungsstufe zwischen 2 und 15 zuweisen, können Sie sich direkt mit diesem Reader verbinden, um die Berichte zu erstellen. Abhängig davon, wie arbeitsspeicherintensiv und CPU-intensiv die Berichtsabfragen sind, kann dieser Reader hochskalieren, um die Workload zu bewältigen. Anschließend kann er wieder herunterskalieren, wenn die Berichte erstellt sind.
Aurora Serverless v2 und Speicher
Der Speicher für jeden Aurora-DB-Cluster besteht aus sechs Kopien all Ihrer Daten, verteilt auf drei AZs. Diese integrierte Datenreplikation gilt unabhängig davon, ob Ihr DB-Cluster zusätzlich zum Writer auch Reader enthält. Auf diese Weise sind Ihre Daten sicher, auch bei Problemen, die sich auf die Rechenkapazität des Clusters auswirken.
Aurora Serverless v2-Speicher hat die gleichen Zuverlässigkeits- und Haltbarkeitseigenschaften wie unter Amazon Aurora Aurora-Speicher beschrieben. Das liegt daran, dass der Speicher für Aurora-DB-Cluster identisch funktioniert, unabhängig davon, ob die Rechenkapazität Aurora Serverless v2 verwendet oder bereitgestellt wird.
Konfigurationsparameter für Aurora-Cluster
Sie können Cluster- und Datenbankkonfigurationsparameter für Cluster mit Aurora Serverless v2-Kapazität genauso anpassen wie für bereitgestellte DB-Clustern. Einige kapazitätsbezogene Parameter werden für Aurora Serverless v2 jedoch unterschiedlich behandelt. In einem Cluster mit gemischter Konfiguration gelten die Parameterwerte, die Sie für diese kapazitätsbezogenen Parameter angeben, weiterhin für bereitgestellte Writer und Reader.
Fast alle Parameter funktionieren für Aurora Serverless v2-Writer und Reader auf die gleiche Weise wie für bereitgestellte Writer und Reader. Ausnahmen sind einige Parameter, die Aurora während der Skalierung automatisch anpasst, und einige Parameter, die von Aurora als feste Werte beibehalten werden, die von der maximalen Kapazitätseinstellung abhängen.
Beispielsweise erhöht sich die für den Puffer-Cache reservierte Speichermenge, wenn ein Writer oder Reader hochskaliert, und nimmt beim Herunterskalieren ab. Auf diese Weise kann Arbeitsspeicher freigegeben werden, wenn Ihre Datenbank nicht ausgelastet ist. Umgekehrt legt Aurora die maximale Anzahl von Verbindungen automatisch auf einen Wert fest, der basierend auf der maximalen Kapazitätseinstellung angemessen ist. Auf diese Weise werden aktive Verbindungen nicht unterbrochen, wenn die Last sinkt und Aurora Serverless v2 herunterskaliert. Weitere Informationen zum Umgang von Aurora Serverless v2 mit bestimmten Parametern finden Sie unter Arbeiten mit Parametergruppen für Aurora Serverless v2.