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 v1

Im Folgenden erfahren Sie, wie Aurora Serverless v1 funktioniert.

Aurora Serverless v1-Architektur

Die folgende Abbildung zeigt einen Überblick über die Aurora Serverless v1-Architektur.

Anstatt Datenbankserver bereitzustellen und zu verwalten, geben Sie Aurora-Kapazitätseinheiten (ACUs) an. Jede ACU ist eine Kombination aus etwa 2 Gigabyte (GB) Arbeitsspeicher, entsprechender CPU und Netzwerkleistung. Der Datenbankspeicher wird automatisch von 10 Gibibyte (GiB) auf 128 tebibytes (TiB) skaliert, genau wie Speicher in einem standardmäßigen Aurora-DB-Cluster.

Sie können die minimale und maximale ACU angeben. Die Mindestkapazitätseinheit von Aurora ist die kleinste ACU, auf die das DB-Cluster herabskaliert werden kann. Die maximale Kapazitätseinheit von Aurora ist die größte ACU, auf die das DB-Cluster hinaufskaliert werden kann. Basierend auf Ihren Einstellungen erstellt Aurora Serverless v1 automatisch Skalierungsregeln in Bezug auf Schwellenwerte für CPU-Auslastung, Verbindungen und verfügbaren Arbeitsspeicher.

Aurora Serverless v1verwaltet den warmen Ressourcenpool, um die Skalierungszeit AWS-Region zu minimieren. Wenn Aurora Serverless v1 dem Aurora-DB-Cluster neue Ressourcen hinzufügt, verwendet es die Routerflotte, um aktive Client-Verbindungen auf die neuen Ressourcen umzustellen. Zu einem bestimmten Zeitpunkt werden Ihnen nur diejenigen in Rechnung gestellt ACUs , die aktiv in Ihrem Aurora-DB-Cluster verwendet werden.

Automatische Skalierung für Aurora Serverless v1

Die Ihrem Aurora Serverless v1-DB-Cluster zugewiesene Kapazität wird basierend auf der von Ihrer Client-Anwendung generierten Last nahtlos auf- und abwärts skaliert. Hier ist die Last die CPU-Auslastung und die Anzahl der Verbindungen. Wenn die Kapazität durch eine dieser beiden Faktoren eingeschränkt wird, wird Aurora Serverless v1 skaliert. Aurora Serverless v1 skaliert auch, wenn Leistungsprobleme erkannt werden, die dadurch gelöst werden können.

Sie können Skalierungsereignisse für Ihren Aurora Serverless v1 Cluster im einsehen AWS-Managementkonsole. Während der automatischen Skalierung setzt Aurora Serverless v1 die EngineUptime-Metrik zurück. Der Wert des zurückgesetzten Metrikwertes bedeutet weder, dass die nahtlose Skalierung Probleme hatte, noch, dass Aurora Serverless v1 Verbindungen unterbrochen hat. Er ist einfach der Ausgangspunkt für die Betriebszeit bei der neuen Kapazität. Weitere Informationen über Metriken finden Sie unter Überwachung von Metriken in einem Amazon-Aurora-Cluster.

Wenn Ihr Aurora Serverless v1 DB-Cluster keine aktiven Verbindungen hat, kann er auf eine Kapazität von Null herunterskaliert werden (0 ACUs). Weitere Informationen hierzu finden Sie unter Pausieren und Fortsetzen für Aurora Serverless v1.

Wenn er einen Skalierungsvorgang durchführen muss, versucht Aurora Serverless v1 zuerst einen Skalierungspunkt zu identifizieren, ein Moment, in dem keine Anfragen bearbeitet werden. Aurora Serverless v1 kann aus folgenden Gründen möglicherweise keinen Skalierungspunkt finden:

Um die Erfolgsrate Ihres Aurora Serverless v1-DB-Clusters bei der Suche nach einem Skalierungspunkt zu erhöhen, empfehlen wir, lang andauernde Abfragen und lang andauernde Transaktionen zu vermeiden. Weitere Informationen zu Operationen zum Blockieren von Skalierungen und wie Sie diese vermeiden können, finden Sie unter Bewährte Methoden für die Arbeit mit Aurora Serverless v1.

Standardmäßig versucht Aurora Serverless v1, einen Skalierungspunkt für 5 Minuten (300 Sekunden) zu finden. Sie können bei der Erstellung oder Änderung des Clusters eine andere Zeitspanne festlegen. Die Timeout-Zeit kann zwischen 60 Sekunden und 10 Minuten (600 Sekunden) liegen. Wenn Aurora Serverless v1 innerhalb des angegebenen Zeitraums keinen Skalierungspunkt finden kann, wird der Autoskalierungsvorgang abgebrochen.

Standardmäßig, wenn automatischen Skalierung vor dem Timeout keinen Skalierungspunkt findet, hält Aurora Serverless v1 den Cluster auf der aktuellen Kapazität. Sie können dieses Standardverhalten bei der Erstellung oder Änderung Ihres Aurora Serverless v1 DB-Clusters ändern, indem Sie die Option Kapazitätsänderung erzwingen auswählen. Weitere Informationen finden Sie unter Timeout-Aktion für Kapazitätsänderungen.

Timeout-Aktion für Kapazitätsänderungen

Wenn die automatische Skalierung abbricht, ohne einen Skalierungspunkt zu finden, behält Aurora standardmäßig die aktuelle Kapazität bei. Sie können festlegen, dass Aurora die Änderung erzwingt, indem Sie die Option Force the capacity change (Kapazitätsänderung erzwingen) aktivieren. Diese Option ist im Abschnitt Autoscaling timeout and action (Autoscaling-Timeout und -Aktion) auf der Seite Create database (Datenbank erstellen) verfügbar, wenn Sie den Cluster erstellen.

Standardmäßig ist die Option Force the capacity change (Kapazitätsänderung erzwingen) deaktiviert. Lassen Sie diese Option deaktiviert, damit die Kapazität Ihres Aurora Serverless v1-DB-Clusters unverändert bleibt, wenn der Skalierungsvorgang ausläuft, ohne einen Skalierungspunkt zu finden.

Wenn Sie diese Option aktivieren, erwzingt Ihr Aurora Serverless v1-DB-Cluster die Kapazitätsänderung auch ohne Skalierungspunkt. Bevor Sie diese Option auswählen, sollten Sie sich der Konsequenzen dieser Auswahl bewusst sein:

Die Entscheidungen, die Sie AWS-Managementkonsole bei der Erstellung eines Aurora Serverless v1 DB-Clusters treffen, werden im ScalingConfigurationInfo Objekt, in den Eigenschaften SecondsBeforeTimeout und TimeoutAction gespeichert. Der Wert der TimeoutAction-Eigenschaft wird bei der Erstellung Ihres Clusters auf einen der folgenden Werte festgelegt:

Sie können den Wert dieser Eigenschaft in einem vorhandenen Aurora Serverless v1 DB-Cluster mithilfe des folgenden describe-db-clusters AWS CLI Befehls abrufen.

Für Linux, macOS oder Unix:

aws rds describe-db-clusters --region region \
  --db-cluster-identifier your-cluster-name \
  --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

Für Windows:

aws rds describe-db-clusters --region region ^
  --db-cluster-identifier your-cluster-name ^
  --query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"

Das folgende Beispiel zeigt die Abfrage und die Antwort für einen Aurora Serverless v1 DB-Cluster mit der Bezeichnung west-coast-sles in der Region US-West (Nordkalifornien).

$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles 
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

[
    {
        "ScalingConfigurationInfo": {
            "MinCapacity": 1,
            "MaxCapacity": 64,
            "AutoPause": false,
            "SecondsBeforeTimeout": 300,
            "SecondsUntilAutoPause": 300,
            "TimeoutAction": "RollbackCapacityChange"
        }
    }
]

Wie die Antwort zeigt, verwendet dieser Aurora Serverless v1-DB-Cluster die Standardeinstellung.

Weitere Informationen finden Sie unter Erstellen eines Aurora Serverless v1-DB Clusters. Nach Erstellung Ihres Aurora Serverless v1, können Sie die Timeout-Aktion und andere Kapazitätseinstellungen jederzeit ändern. Um zu erfahren wie, siehe Ändern eines Aurora Serverless v1-DB-Clusters.

Pausieren und Fortsetzen für Aurora Serverless v1

Sie können festlegen, Ihren Aurora Serverless v1-DB-Cluster nach einer bestimmten Zeit ohne Aktivität zu pausieren. Sie geben die Zeitspanne ohne Aktivität an, bevor der DB-Cluster angehalten wird. Wenn Sie diese Option auswählen, beträgt die standardmäßige Inaktivitätszeit fünf Minuten. Sie können diesen Wert jedoch ändern. Dies ist eine optionale Einstellung.

Wenn der DB-Cluster pausiert wird, findet keine Rechen- oder Speicheraktivität statt, und es wird Ihnen nur die Speicherung in Rechnung gestellt. Wenn beim Anhalten eines Aurora Serverless v1 DB-Clusters Datenbankverbindungen angefordert werden, nimmt der DB-Cluster die Verbindungsanforderungen automatisch wieder auf und bedient sie.

Wenn der DB-Cluster die Aktivität fortsetzt, hat er die gleiche Kapazität wie beim Anhalten des Clusters durch Aurora. Die Anzahl ACUs hängt davon ab, wie stark Aurora den Cluster nach oben oder unten skaliert hat, bevor er angehalten wurde.

Bestimmen der maximalen Anzahl von Datenbankverbindungen für Aurora Serverless v1

Im Folgenden sind einige Beispiele für einen DB-Cluster von Aurora Serverless v1 aufgeführt, der mit MySQL 5.7 kompatibel ist. Sie können einen MySQL-Client oder den Abfrage-Editor verwenden, wenn Sie den Zugriff darauf konfiguriert haben. Weitere Informationen finden Sie unter Ausführen von Abfragen im Abfrage-Editor.

Parametergruppen für Aurora Serverless v1

Wenn Sie Ihren Aurora Serverless v1-DB-Cluster erstellen, wählen Sie eine bestimmte Aurora-DB-Engine und eine zugehörige DB-Cluster-Parametergruppe. Im Gegensatz zu bereitgestellten Aurora-DB-Clustern verfügt ein Aurora Serverless v1 DB-Cluster über eine einzige read/write DB-Instance, die nur mit einer DB-Cluster-Parametergruppe konfiguriert ist — sie hat keine separate DB-Parametergruppe. Während der automatischen Skalierung, muss Aurora Serverless v1 in der Lage sein, Parameter zu ändern, damit der Cluster optimal für die erhöhte oder verringerte Kapazität funktioniert. Das heißt, dass bei einem Aurora Serverless v1-DB-Cluster, einige der Änderungen, die Sie an Parametern für einen bestimmten DB-Engine-Typ vornehmen, möglicherweise nicht gelten.

Zum Beispiel kann ein Aurora-PostgreSQL–basierter Aurora Serverless v1-DB-Cluster apg_plan_mgmt.capture_plan_baselines und andere Parameter nicht verwenden, die auf bereitgestellten Aurora PostgreSQL-DB-Clustern für die Verwaltung von Abfrageplänen verwendet werden könnten.

Sie können eine Liste der Standardwerte für die Standardparametergruppen für die verschiedenen Aurora-DB-Engines abrufen, indem Sie den CLI-Befehl describe-engine-default-cluster-parameters verwenden und die abfragen. AWS-Region Die folgenden Werte können Sie für die --db-parameter-group-family-Option verwenden.

Wir empfehlen, dass Sie Ihre AWS CLI mit Ihrer AWS Zugriffsschlüssel-ID und Ihrem AWS geheimen Zugriffsschlüssel konfigurieren und dass Sie Ihre Befehle AWS-Region vor der Verwendung AWS CLI festlegen. Wenn Sie die Region Ihrer CLI-Konfiguration angeben, müssen Sie die --region-Parameter beim Ausführen von Befehlen nicht eingeben. Weitere Informationen zur Konfiguration AWS CLI finden Sie im AWS Command Line Interface Benutzerhandbuch unter Grundlagen der Konfiguration.

Im folgenden Beispiel wird eine Liste von Parametern aus der Standard-DB-Cluster-Gruppe für Aurora-MySQL-Version 2 gezeigt.

Für Linux, macOS oder Unix:

aws rds describe-engine-default-cluster-parameters \
  --db-parameter-group-family aurora-mysql5.7 --query \
  'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \
  --output text

Für Windows:

aws rds describe-engine-default-cluster-parameters ^
   --db-parameter-group-family aurora-mysql5.7 --query ^
   "EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^
   --output text

Änderung von Parameterwerten für Aurora Serverless v1

Wie in Parametergruppen für Amazon Aurora erläutert, können Sie Werte in einer Standardparametergruppe unabhängig von ihrem Typ (DB-Cluster-Parametergruppe, DB-Parametergruppe) nicht direkt ändern. Stattdessen erstellen Sie eine benutzerdefinierte Parametergruppe basierend auf der standardmäßigen DB-Cluster-Parametergruppe für Ihre Aurora-DB-Engine und ändern die Einstellungen nach Bedarf für diese Parametergruppe. Beispielsweise möchten Sie möglicherweise einige Einstellungen für Ihren Aurora Serverless v1 DB-Cluster ändern, um Abfragen zu protokollieren oder DB-Engine-spezifische Protokolle auf Amazon hochzuladen CloudWatch.

Ihre benutzerdefinierte DB-Cluster-Parametergruppe wird der Liste der Parametergruppen hinzugefügt, die in Ihrer AWS-Region verfügbar sind. Sie können Ihre benutzerdefinierte DB-Cluster-Parametergruppe verwenden, wenn Sie neue Aurora Serverless v1-DB-Cluster erstellen. Sie können auch einen vorhandenen Aurora Serverless v1-DB-Cluster anpassen, sodass ser Ihre benutzerdefinierte DB-Cluster-Parametergruppe verwendet. Nachdem Ihr Aurora Serverless v1 DB-Cluster anfängt, Ihre benutzerdefinierte DB-Cluster-Parametergruppe zu verwenden, können Sie Werte für dynamische Parameter entweder mit AWS-Managementkonsole oder mit ändern AWS CLI.

Sie können die Konsole auch verwenden, um einen side-by-side Vergleich der Werte in Ihrer benutzerdefinierten DB-Cluster-Parametergruppe mit der Standard-DB-Cluster-Parametergruppe anzuzeigen, wie im folgenden Screenshot gezeigt.

Wenn Sie Parameterwerte in einem aktiven DB-Cluster ändern, startet Aurora Serverless v1 eine nahtlose Skalierung, um die Parameteränderungen anzuwenden. Wenn Ihr Aurora Serverless v1-DB-Cluster sich in einem pausierten Zustand befindet, wird er fortgesetzt und beginnt mit der Skalierung, damit er die Änderung vornehmen kann. Der Skalierungsvorgang für eine Parametergruppe ändert immer Erzwingen einer Kapazitätsänderung. Beachten Sie daher, dass das Ändern von Parametern zu unterbrochenen Verbindungen führen kann, wenn während der Skalierungsperiode kein Skalierungspunkt gefunden werden kann.

Protokollierung für Aurora Serverless v1

Standardmäßig sind Fehlerprotokolle für aktiviert und Aurora Serverless v1 werden automatisch zu Amazon hochgeladen CloudWatch. Sie können Ihren Aurora Serverless v1 DB-Cluster auch veranlassen, Aurora-Datenbank-Engine-spezifische Protokolle hochzuladen. CloudWatch Aktivieren Sie dazu die Konfigurationsparameter in Ihrer benutzerdefinierten DB-Cluster-Parametergruppe. Ihr Aurora Serverless v1 DB-Cluster lädt dann alle verfügbaren Protokolle auf Amazon CloudWatch hoch. An dieser Stelle können Sie Protokolldaten analysieren CloudWatch , Alarme erstellen und Metriken anzeigen.

Für Aurora MySQL zeigt die folgende Tabelle die Protokolle, die Sie aktivieren können. Wenn sie aktiviert sind, werden sie automatisch von Ihrem Aurora Serverless v1 DB-Cluster zu Amazon hochgeladen CloudWatch.

Weitere Informationen finden Sie unter Verwenden von Advanced Auditing in einem Amazon Aurora MySQL DB-Cluster.

Für Aurora PostgreSQL zeigt die folgende Tabelle die Protokolle, die Sie aktivieren können. Wenn sie aktiviert sind, werden sie CloudWatch zusammen mit den regulären Fehlerprotokollen automatisch von Ihrem Aurora Serverless v1 DB-Cluster zu Amazon hochgeladen.

Nachdem Sie die Logs für Aurora MySQL oder Aurora PostgreSQL für Ihren Aurora Serverless v1 DB-Cluster aktiviert haben, können Sie die Logs einsehen. CloudWatch

Aurora Serverless v1Logs mit Amazon anzeigen CloudWatch

Aurora Serverless v1lädt automatisch CloudWatch alle Logs, die in Ihrer benutzerdefinierten DB-Cluster-Parametergruppe aktiviert sind, auf Amazon hoch („veröffentlicht“). Sie müssen die Protokolltypen nicht auswählen oder angeben. Das Hochladen von Protokollen beginnt, sobald Sie den Protokollkonfigurationsparameter aktivieren. Wenn Sie den Protokoll-Parameter später deaktivieren, werden weitere Uploads angehalten. Alle Protokolle, die bereits veröffentlicht wurden, CloudWatch bleiben jedoch bestehen, bis Sie sie löschen.

Weitere Informationen zur Verwendung CloudWatch mit Aurora MySQL-Protokollen finden Sie unterÜberwachung von Protokollereignissen in Amazon CloudWatch.

Weitere Hinweise zu CloudWatch und Aurora PostgreSQL finden Sie unter. Veröffentlichen von Aurora-PostgreSQL-Protokollen in Amazon CloudWatch Logs

Im folgenden Screenshot finden Sie beispielsweise Verzeichnisse für Protokolle, die für einen Aurora PostgreSQL Aurora Serverless v1-DB-Cluster namens western-sles veröffentlicht wurden. Sie können auch mehrere Verzeichnisse für Aurora MySQL Aurora Serverless v1-DB-Cluster west-coast-sles finden. Wählen Sie das gewünschte Protokoll aus, um sich den Inhalt anzusehen.

Aurora Serverless v1 und Wartung

Die Wartung des Aurora Serverless v1 DB-Clusters, z. B. die Anwendung der neuesten Funktionen, Fixes und Sicherheitsupdates, wird automatisch für Sie durchgeführt. Aurora Serverless v1hat ein Wartungsfenster, das Sie unter Wartung und Backups für Ihren Aurora Serverless v1 DB-Cluster einsehen können. AWS-Managementkonsole Sie finden dort das Datum und die Uhrzeit für die mögliche Durchführung der Wartung, und ob eine Wartung für Ihren Aurora Serverless v1-DB-Cluster aussteht, wie in der folgenden Abbildung dargestellt.

Sie können das Wartungsfenster festlegen, wenn Sie den Aurora Serverless v1-DB-Cluster erstellen, und Sie können das Fenster später ändern. Weitere Informationen finden Sie unter Anpassen des bevorzugten DB-Cluster-Wartungsfensters.

Wartungsfenster werden für geplante Hauptversions-Upgrades verwendet. Nebenversions-Upgrades und Patches werden sofort während der Skalierung angewendet. Die Skalierung erfolgt entsprechend Ihrer Einstellung für TimeoutAction:

Wie bei jeder Änderung, die ohne einen geeigneten Skalierungspunkt erzwungen wird, kann Ihr Workload dadurch unterbrochen werden.

Wann immer möglich, führt Aurora Serverless v1 die Wartung unterbrechungsfrei durch. Wenn eine Wartung erforderlich ist, skaliert Ihr Aurora Serverless v1-DB-Cluster seine Kapazität, damit die erforderlichen Vorgänge durchgeführt werden können. Vor dem Skalieren sucht Aurora Serverless v1 nach einem Skalierungspunkt. Dies geschieht bei Bedarf bis zu drei Tage lang.

Am Ende jedes Tages, an dem Aurora Serverless v1 keinen Skalierungspunkt finden kann, erstellt es ein Cluster-Ereignis. Dieses Ereignis informiert Sie über die ausstehende Wartung und die Notwendigkeit einer Skalierung für die Durchführung der Wartung. Die Benachrichtigung enthält auch das Datum, an dem Aurora Serverless v1 die Skalierung des DB-Clusters erzwingen kann.

Weitere Informationen finden Sie unter Timeout-Aktion für Kapazitätsänderungen.

Aurora Serverless v1 und Failover

Wenn die DB-Instance für einen Aurora Serverless v1-DB-Cluster nicht mehr verfügbar ist oder die Availability Zone (AZ), in der sie sich befindet, ausfällt, erstellt Aurora die DB-Instance in einer anderen AZ neu. Allerdings ist der Aurora Serverless v1-Cluster kein Multi-AZ-Cluster. Das liegt daran, dass er aus einer einzigen DB-Instance in einer einzigen AZ besteht. Dieser Failover-Mechanismus benötigt mehr Zeit als bei einem Aurora-Cluster mit bereitgestellten oder Aurora Serverless v2-Instances. Die Aurora Serverless v1 Failover-Zeit ist nicht definiert, da sie von der Nachfrage und der Kapazitätsverfügbarkeit in anderen AZs Bereichen abhängt. AWS-Region

Da Aurora Rechenkapazität und Speicher voneinander trennt, verteilt sich das Speichervolumen für den Cluster auf mehrere AZs. Ihre Daten bleiben auch bei Ausfällen der DB-Instance oder der zugehörigen AZ verfügbar.

Aurora Serverless v1 und Snapshots

Das Cluster-Volume für einen Aurora Serverless v1-Cluster ist immer verschlüsselt. Sie können den Verschlüsselungsschlüssel auswählen, aber Sie können die Verschlüsselung nicht deaktivieren. Zum Kopieren oder Freigeben eines Snapshots eines Aurora Serverless v1-Clusters verschlüsseln Sie den Snapshot mit Ihrem eigenen AWS KMS key. Weitere Informationen finden Sie unter Kopieren eines DB-Cluster-Snapshots. Weitere Informationen zur Verschlüsselung und zu Amazon Aurora finden Sie unter Verschlüsseln eines Amazon-Aurora-DB-Clusters.