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.

Wie Aurora Serverless v1 funktioniert

Im Folgenden erfahren Sie, wie Aurora Serverless v1 funktioniert.

Aurora Serverless v1 Anwendung ansehen

Das folgende Bild zeigt einen Überblick über 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 Aurora Serverless v1 erstellt automatisch Skalierungsregeln für Schwellenwerte für CPU-Auslastung, Verbindungen und verfügbaren Speicher.

Aurora Serverless v1 verwaltet den warmen Ressourcenpool, um die Skalierungszeit AWS-Region zu minimieren. Wann Aurora Serverless v1 fügt dem Aurora-DB-Cluster neue Ressourcen hinzu und verwendet die Router-Flotte, um aktive Client-Verbindungen auf die neuen Ressourcen umzuschalten. Zu einem bestimmten Zeitpunkt werden Ihnen nur diejenigen in Rechnung gestellt ACUs , die aktiv in Ihrem Aurora-DB-Cluster verwendet werden.

Autoscaling für Aurora Serverless v1

Die Kapazität, die Ihrem zugewiesen ist Aurora Serverless v1 Der DB-Cluster lässt sich je nach der von Ihrer Client-Anwendung generierten Last nahtlos nach oben oder unten skalieren. Hier ist die Last die CPU-Auslastung und die Anzahl der Verbindungen. Wenn die Kapazität durch einen dieser Faktoren eingeschränkt wird, Aurora Serverless v1 skaliert. Aurora Serverless v1 wird auch hochskaliert, wenn Leistungsprobleme erkannt werden, die auf diese Weise behoben werden können.

Sie können Skalierungsereignisse für Ihre anzeigen Aurora Serverless v1 Cluster im AWS Management Console. Während der automatischen Skalierung Aurora Serverless v1 setzt die Metrik zurück. EngineUptime Der Wert des Metrikwerts zum Zurücksetzen bedeutet nicht, dass bei der nahtlosen Skalierung Probleme aufgetreten sind oder Aurora Serverless v1 hat Verbindungen unterbrochen. 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 dein Aurora Serverless v1 Der DB-Cluster hat keine aktiven Verbindungen, er kann 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 ein Skalierungsvorgang durchgeführt werden muss, Aurora Serverless v1 versucht zunächst, einen Skalierungspunkt zu identifizieren, also einen Moment, in dem keine Abfragen verarbeitet werden. Aurora Serverless v1 kann aus den folgenden Gründen möglicherweise keinen Skalierungspunkt finden:

Um deine zu erhöhen Aurora Serverless v1 Die Erfolgsquote des DB-Clusters bei der Suche nach einem Skalierungspunkt: Wir empfehlen, lang andauernde Abfragen und lang andauernde Transaktionen zu vermeiden. Weitere Informationen zu Vorgängen, die die Skalierung blockieren, und darüber, wie Sie sie vermeiden können, finden Sie unter Bewährte Methoden für die Arbeit mit Aurora Serverless v1.

Standardmäßig Aurora Serverless v1 versucht für 5 Minuten (300 Sekunden) einen Skalierungspunkt 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 kann innerhalb des angegebenen Zeitraums keinen Skalierungspunkt finden, der Autoscaling-Vorgang läuft ab.

Wenn die automatische Skalierung vor dem Timeout keinen Skalierungspunkt findet, Aurora Serverless v1 hält den Cluster auf der aktuellen Kapazität. Sie können dieses Standardverhalten ändern, wenn Sie Ihr Aurora Serverless v1 DB-Cluster, 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 leer, um Ihre Aurora Serverless v1 Die Kapazität des DB-Clusters bleibt unverändert, wenn beim Skalierungsvorgang ein Timeout auftritt, ohne dass ein Skalierungspunkt gefunden wurde.

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

Die Entscheidungen, die Sie treffen AWS Management Console , wenn Sie ein Aurora Serverless v1 DB-Cluster werden im ScalingConfigurationInfo Objekt, in den TimeoutAction Eigenschaften SecondsBeforeTimeout und 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 für ein vorhandenes Objekt abrufen Aurora Serverless v1 DB-Cluster mithilfe des describe-db-clusters AWS CLI Befehls, wie im Folgenden gezeigt.

Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Linux, macOS, oder Unix:

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

Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. Windows:

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

Im Folgenden werden die Abfrage und die Antwort für ein Beispiel dargestellt Aurora Serverless v1 DB-Cluster, der west-coast-sles in der Region USA West (Nordkalifornien) benannt ist.

$ 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, ist das Aurora Serverless v1 Der DB-Cluster verwendet die Standardeinstellung.

Weitere Informationen finden Sie unter Erstellen eines Aurora Serverless v1 DB-Cluster. Nach der Erstellung Ihres Aurora Serverless v1, Sie können die Timeout-Aktion und andere Kapazitätseinstellungen jederzeit ändern. Um zu erfahren wie dies geht, vgl. Modifizieren eines Aurora Serverless v1 DB-Cluster.

Pausieren und fortsetzen für Aurora Serverless v1

Sie können wählen, ob Sie Ihre Pause einlegen möchten Aurora Serverless v1 DB-Cluster nach einer bestimmten Zeit ohne Aktivität. 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 Datenbankverbindungen angefordert werden, wenn Aurora Serverless v1 Der DB-Cluster wird angehalten, der DB-Cluster nimmt die Verbindungsanfragen automatisch wieder auf und bearbeitet 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.

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

Die folgenden Beispiele beziehen sich auf Aurora Serverless v1 DB-Cluster, 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 Ihre erstellen Aurora Serverless v1 DB-Cluster, Sie wählen eine bestimmte Aurora-DB-Engine und eine zugehörige DB-Cluster-Parametergruppe aus. Im Gegensatz zu bereitgestellten Aurora-DB-Clustern Aurora Serverless v1 Ein DB-Cluster hat eine einzelne DB-Instance mit Lese-/Schreibzugriff, die nur mit einer DB-Cluster-Parametergruppe konfiguriert ist — sie hat keine separate DB-Parametergruppe. Während der automatischen Skalierung Aurora Serverless v1 muss in der Lage sein, Parameter zu ändern, damit der Cluster für die erhöhte oder verringerte Kapazität am besten funktioniert. Somit mit einem Aurora Serverless v1 Bei einem DB-Cluster gelten einige der Änderungen, die Sie möglicherweise an den Parametern für einen bestimmten DB-Engine-Typ vornehmen, möglicherweise nicht.

Zum Beispiel ein Aurora PostgreSQL-basiertes Aurora Serverless v1 Der DB-Cluster kann keine anderen Parameter verwendenapg_plan_mgmt.capture_plan_baselines, 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.

Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. 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

Wählen Sie in der &Snowconsole; Ihren Auftrag aus der Tabelle. 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

Ändern 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. Möglicherweise möchten Sie beispielsweise einige Einstellungen für Ihr ändern Aurora Serverless v1 DB-Cluster zum Protokollieren von Abfragen oder zum Hochladen von DB-Engine-spezifischen Protokollen auf Amazon 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 erstellen Aurora Serverless v1 DB-Cluster. Sie können auch ein vorhandenes ändern Aurora Serverless v1 DB-Cluster, um Ihre benutzerdefinierte DB-Cluster-Parametergruppe zu verwenden. Nach deinem Aurora Serverless v1 Der DB-Cluster verwendet zunächst Ihre benutzerdefinierte DB-Cluster-Parametergruppe. Sie können Werte für dynamische Parameter entweder mit AWS Management Console 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, Aurora Serverless v1 startet eine Seamless-Skala, um die Parameteränderungen anzuwenden. Wenn Ihre Aurora Serverless v1 Der DB-Cluster befindet sich im angehaltenen Zustand. Er wird fortgesetzt und beginnt mit der Skalierung, sodass die Änderung vorgenommen werden 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 werden Fehlerprotokolle für Aurora Serverless v1 sind aktiviert und werden automatisch auf Amazon hochgeladen CloudWatch. Sie können auch Ihre haben Aurora Serverless v1 DB-Cluster laden Aurora-Datenbank-Engine-spezifische Protokolle in hoch. CloudWatch Aktivieren Sie dazu die Konfigurationsparameter in Ihrer benutzerdefinierten DB-Cluster-Parametergruppe. Ihre Aurora Serverless v1 Der DB-Cluster lädt dann alle verfügbaren Protokolle zu 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 hochgeladen Aurora Serverless v1 DB-Cluster zu Amazon CloudWatch.

Weitere Informationen finden Sie unter Verwenden von Advanced Auditing mit einem Amazon Aurora My SQL DB-Cluster.

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

Nachdem Sie Logs für Aurora MySQL oder Aurora PostgreSQL für Ihr Aurora Serverless v1 Im DB-Cluster können Sie sich die Logs ansehen. CloudWatch

Wird angezeigt Aurora Serverless v1 Logs mit Amazon CloudWatch

Aurora Serverless v1 lä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Überwachen von Protokollereignissen in Amazon CloudWatch.

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

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

Aurora Serverless v1 und Wartung

Wartung für Aurora Serverless v1 Der DB-Cluster, z. B. das Anwenden der neuesten Funktionen, Fixes und Sicherheitsupdates, wird automatisch für Sie durchgeführt. Aurora Serverless v1 hat ein Wartungsfenster, das Sie unter Wartung und Backups für Ihr AWS Management Console Aurora Serverless v1 DB-Cluster. Sie können das Datum und die Uhrzeit ermitteln, zu der möglicherweise Wartungsarbeiten durchgeführt werden, und finden heraus, ob Wartungsarbeiten für Ihr Aurora Serverless v1 DB-Cluster, wie in der folgenden Abbildung dargestellt.

Sie können das Wartungsfenster festlegen, wenn Sie das erstellen Aurora Serverless v1 DB-Cluster, 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. Upgrades und Patches für kleinere Versionen werden sofort während der Skalierung angewendet. Die Skalierung erfolgt entsprechend Ihrer Einstellung fürTimeoutAction:

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

Wann immer möglich Aurora Serverless v1 führt Wartungsarbeiten unterbrechungsfrei durch. Wenn eine Wartung erforderlich ist, ist Ihr Aurora Serverless v1 Der DB-Cluster skaliert seine Kapazität, um die erforderlichen Operationen abzuwickeln. Vor der Skalierung Aurora Serverless v1 sucht nach einem Skalierungspunkt. Dies geschieht bei Bedarf für bis zu drei Tage.

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

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

Aurora Serverless v1 und Failover

Wenn die DB-Instance für ein Aurora Serverless v1 Der DB-Cluster ist nicht mehr verfügbar oder die Availability Zone (AZ), in der er sich befindet, schlägt fehl. Aurora erstellt die DB-Instance in einer anderen AZ neu. Doch die Aurora Serverless v1 Cluster ist kein Multi-AZ-Cluster. Das liegt daran, dass er aus einer einzigen DB-Instance in einer einzigen AZ besteht. Somit dauert dieser Failover-Mechanismus länger als bei einem Aurora-Cluster mit bereitgestellten oder Aurora Serverless v2 Instanzen. Das Tool Aurora Serverless v1 Die 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 Schnappschüsse

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