Verwalten von Aurora serverless-DB-Clustern

Mit Aurora serverless sind Ihre Cluster mit bereitgestellten Clustern austauschbar. Die Aurora serverless-Eigenschaften gelten für eine oder mehrere DB-Instances innerhalb eines DB-Clusters. Daher sind die Verfahren zum Erstellen von Clustern, zum Ändern von Clustern, zum Erstellen und Wiederherstellen von Snapshots usw. im Grunde die gleichen wie bei anderen Arten von Aurora-Clustern. Allgemeine Verfahren zum Verwalten von Aurora-Clustern und DB-Instances finden Sie unter Verwalten eines Amazon Aurora-DB-Clusters.

In den folgenden Themen erfahren Sie mehr über die Überlegungen im Hinblick auf die Verwaltung von Clustern, die Aurora serverless-DB-Instances enthalten.

Festlegen des Aurora serverless-Kapazitätsbereichs für einen Cluster

Wenn Sie die Konfigurationsparameter oder andere Einstellungen für Cluster mit Aurora serverless-DB-Instances oder die DB-Instances selbst ändern möchten, folgen Sie denselben allgemeinen Verfahren wie für bereitgestellte Cluster. Details hierzu finden Sie unter Ändern eines Amazon Aurora-DB-Clusters.

Die wichtigste Einstellung, die für Aurora serverless einzigartig ist, ist der Kapazitätsbereich. Nachdem Sie die Werte für die minimale und maximale Aurora-Kapazitätseinheit (ACU) für einen Aurora-Cluster festgelegt haben, müssen Sie die Kapazität der Aurora serverless-DB-Instances im Cluster aktiv anpassen. Aurora übernimmt diesen Schritt nicht. Diese Einstellung wird auf Cluster-Ebene verwaltet. Für jede Aurora serverless-DB-Instance im Cluster gelten die gleichen minimalen und maximalen ACU-Werte.

Sie können die folgenden spezifischen Werte festlegen:

Der verfügbare Kapazitätsbereich für Aurora serverless ist sowohl von der DB-Engine-Version als auch von der Plattformversion abhängig. Neuere DB-Engine-Versionen ermöglichen eine maximale Kapazität von 256 ACUs, eine Mindestkapazität von 0 ACUs oder beides. Die Kapazitätsbereiche für verschiedene DB-Engine-Versionen finden Sie unter Kapazität von Aurora serverless.

Informationen zur Funktion zum automatischen Anhalten und Fortsetzen, die durch Festlegen der Mindestkapazität auf 0 ACUs aktiviert wird, finden Sie unter Skalierung auf 0 ACUs mit automatischem Anhalten und Fortsetzen für Aurora serverless.

Weitere Informationen dazu, wie Sie sicherstellen können, dass Ihre Aurora serverless-DB-Cluster auf bis zu 256 ACUs skaliert werden können, finden Sie unter Aktualisieren des Aurora serverless-DB-Clusters, um eine Skalierung auf 256 ACUs zu ermöglichen.

In Aurora serverless können Sie die aktuelle Kapazität nicht direkt festlegen, ohne den Kapazitätsbereich zu ändern, da die Kapazität dynamisch an die Workload innerhalb des angegebenen Bereichs angepasst wird. Sie können jedoch die Kapazität auf eine der folgenden Arten indirekt beeinflussen:

Weitere Informationen zu den Auswirkungen des Kapazitätsbereichs und zur Überwachung und Feinabstimmung finden Sie unter Wichtige CloudWatch Amazon-Metriken für Aurora serverless und Performance und Skalierung für Aurora serverless. Ihr Ziel ist es, sicherzustellen, dass die maximale Kapazität für den Cluster hoch genug ist, um Spitzen bei der Workload zu bewältigen, und die miminale Kapazität niedrig genug ist, um die Kosten zu minimieren, wenn der Cluster nicht aktiv ist.

Angenommen, Sie bestimmen basierend auf Ihrer Überwachung, dass der ACU-Bereich für den Cluster höher, niedriger, breiter oder schmaler sein sollte. Sie können die Kapazität eines Aurora-Clusters mit der, der oder der Amazon RDS-API auf einen bestimmten Bereich von ACUs festlegen. AWS-Managementkonsole AWS CLI Dieser Kapazitätsbereich gilt für jede Aurora serverless-DB-Instance im Cluster.

Angenommen, Ihr Cluster hat einen Kapazitätsbereich von 1 bis 16 ACUs und enthält zwei Aurora serverless-DB-Instances. Dann verbraucht der Cluster insgesamt zwischen 2 ACUs (bei Inaktivität) und 32 ACUs (bei Vollauslastung). Wenn Sie den Kapazitätsbereich von 8 in 40,5 ACUs ändern, verbraucht der gesamte Cluster jetzt 16 ACUs bei Inaktivität und bei voller Auslastung bis zu 81 ACUs.

Aurora legt automatisch bestimmte Parameter für Aurora serverless-DB-Instances auf Werte fest, die vom maximalen ACU-Wert im Kapazitätsbereich abhängen. Eine Liste dieser Parameter finden Sie unter Maximale Anzahl der Verbindungen für Aurora serverless. Bei statischen Parametern, die von dieser Berechnungsart abhängen, wird der Wert beim Neustart der DB-Instance erneut ausgewertet. So können Sie den Wert solcher Parameter aktualisieren, indem Sie die DB-Instance neu starten, nachdem Sie den Kapazitätsbereich geändert haben. Wenn Sie wissen möchten, ob Sie Ihre DB-Instance neu starten müssen, um Parameteränderungen zu übernehmen, überprüfen Sie das ParameterApplyStatus-Attribut der DB-Instance. Der Wert pending-reboot gibt an, dass ein Neustart Änderungen auf einige Parameterwerte anwendet.

Sie können den Kapazitätsbereich eines Clusters, der Aurora serverless-DB-Instances enthält, über die AWS-Managementkonsole festlegen.

Wenn Sie die Konsole verwenden, legen Sie den Kapazitätsbereich für den Cluster zu dem Zeitpunkt fest, zu dem Sie dem Cluster die erste Aurora serverless-DB-Instance hinzufügen. Diesen Schritt können Sie ausführen, wenn Sie beim Erstellen des Clusters die DB-Instance-Klasse Serverless v2 für die Writer-DB-Instance auswählen. Sie können diesen Schritt auch ausführen, wenn Sie beim Hinzufügen einer Aurora serverless-Reader-DB-Instance zum Cluster die DB-Instance-Klasse Serverless auswählen. Möglich ist dieser Schritt auch, wenn Sie eine vorhandene bereitgestellte DB-Instance im Cluster in die DB-Instance-Klasse Serverless konvertieren. Die ausführliche Version dieser Verfahren finden Sie unter Erstellen einer Aurora serverless-Writer-DB-Instance, Hinzufügen eines Aurora serverless-Readers und Konvertieren eines bereitgestellten Writers oder Readers in Aurora serverless.

Der jeweilige Kapazitätsbereich, den Sie auf Cluster-Ebene festlegen, gilt für alle Aurora serverless-DB-Instances in Ihrem Cluster. Die folgende Abbildung zeigt einen Cluster mit mehreren Aurora serverless-Reader-DB-Instances. Jede Instance hat einen identischen Kapazitätsbereich von 2 bis 64 ACU.

So ändern Sie den Kapazitätsbereich eines Aurora serverless-Clusters

1. Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.

2. Wählen Sie im Navigationsbereich Datenbanken aus.

3. Wählen Sie den Cluster, der Ihre Aurora serverless-DB-Instances enthält, aus der Liste aus. Der Cluster muss bereits mindestens eine Aurora serverless-DB-Instance enthalten. Andernfalls zeigt Aurora den Abschnitt Capacity range (Kapazitätsbereich) nicht an.

4. Wählen Sie für Actions (Aktionen) die Option Modify (Ändern) aus.

5. Wählen Sie im Abschnitt Capacity range (Kapazitätsbereich) Folgendes aus:

   1. Geben Sie einen Wert für Minimum ACUs (Minimale ACUs) ein. Die Konsole zeigt den zulässigen Wertebereich an. Sie können eine Mindestkapazität zwischen 0 und 256 ACUs wählen. Sie können eine maximale Kapazität zwischen 1 und 256 ACUs wählen. Sie können die Kapazitätswerte in Schritten von 0,5 ACUs anpassen. Der verfügbare Kapazitätsbereich ist sowohl von der DB-Engine-Version als auch von der Plattformversion abhängig.

   2. Geben Sie einen Wert für Maximum ACUs (Maximale ACUs) ein. Dieser Wert muss gleich oder größer als der Wert für Minimum ACUs (Minimale ACUs) sein. Die Konsole zeigt den zulässigen Wertebereich an. In der folgenden Abbildung wird diese Auswahl veranschaulicht.

      

6. Klicken Sie auf Weiter. Die Seite Summary of modifications (Zusammenfassung der Änderungen) wird angezeigt.

7. Wählen Sie Apply immediately (Sofort anwenden) aus.

   Die Kapazitätsänderung erfolgt sofort, unabhängig davon, ob Sie sie sofort oder während des nächsten geplanten Wartungsfensters anwenden möchten.

8. Wählen Sie Modify cluster (Cluster ändern), um die Zusammenfassung der Änderungen zu akzeptieren. Sie können auch Back (Zurück) wählen, um Ihre Änderungen zu bearbeiten, oder Cancel (Abbrechen), um Ihre Änderungen zu verwerfen.

Um die Kapazität eines Clusters festzulegen, in dem Sie Aurora serverless DB-Instances mit dem verwenden möchten AWS CLI, führen Sie den Befehl AWS CLI modify-db-cluster aus. Legen Sie die Option --serverless-v2-scaling-configuration fest. Der Cluster enthält möglicherweise bereits eine oder mehrere Aurora serverless-DB-Instances oder Sie können die DB-Instances später hinzufügen. Gültige Werte für die Felder MinCapacity und MaxCapacity sind unter anderem folgende:

• 0, 0.5, 1, 1.5, 2 usw. in Schritten von 0,5 bis maximal 256. Der ACU-Mindestwert von 0 ist nur für die Aurora-Versionen verfügbar, die die Auto-Pause-Funktion unterstützen.

Die maximal verfügbare Kapazität ist sowohl von der DB-Engine-Version als auch von der Plattformversion abhängig.

In diesem Beispiel legen Sie den ACU-Bereich eines Aurora-DB-Clusters namens sample-cluster auf ein Minimum von 48.5 und maximal 64 fest.

aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
  --serverless-v2-scaling-configuration MinCapacity=48.5,MaxCapacity=64

Die Kapazitätsänderung erfolgt sofort, unabhängig davon, ob Sie sie sofort oder während des nächsten geplanten Wartungsfensters anwenden möchten.

Danach können Sie dem Cluster Aurora serverless-DB-Instances hinzufügen und jede neue DB-Instance kann zwischen 48,5 und 64 ACUs skaliert werden. Der neue Kapazitätsbereich gilt auch für alle Aurora serverless-DB-Instances, die sich bereits im Cluster befanden. Die DB-Instances skalieren bei Bedarf hoch oder herunter, um in den neuen Kapazitätsbereich zu gelangen.

Weitere Beispiele für die Einstellung des Kapazitätsbereichs über die CLI finden Sie unter Auswählen des Aurora serverless-Kapazitätsbereichs für einen Aurora-Cluster.

Um die Skalierungskonfiguration eines Aurora Serverless DB-Clusters mithilfe von zu ändern, führen Sie den AWS CLI Befehl modify-db-cluster aus. AWS CLI Geben Sie die Option --serverless-v2-scaling-configuration an, um die minimale und die maximale Kapazität zu konfigurieren. Zu den gültigen Kapazitätswerten gehören die folgenden:

• Aurora MySQL: 0, 0.5, 1, 1.5, 2 usw. in Schritten von 0,5 ACUs bis maximal 256.

• Aurora PostgreSQL: 0, 0.5, 1, 1.5, 2 usw. in Schritten von 0,5 ACUs bis maximal 256.

• Der ACU-Mindestwert von 0 ist nur für die Aurora-Versionen verfügbar, die die Auto-Pause-Funktion unterstützen.

Im folgenden Beispiel ändern Sie die Skalierungskonfiguration einer Aurora serverless-DB-Instance mit dem Namen sample-instance, die Teil eines Clusters namens sample-cluster ist.

Für Linux, macOS oder Unix:

aws rds modify-db-cluster --db-cluster-identifier sample-cluster \
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64

Für Windows:

aws rds modify-db-cluster --db-cluster-identifier sample-cluster ^
--serverless-v2-scaling-configuration MinCapacity=8,MaxCapacity=64

Sie können die Kapazität einer Aurora-DB-Instance über die API-Operation ModifyDBCluster festlegen. Geben Sie den Parameter ServerlessV2ScalingConfiguration an. Gültige Werte für die Felder MinCapacity und MaxCapacity sind unter anderem folgende:

• 0, 0.5, 1, 1.5, 2 usw. in Schritten von 0,5 bis maximal 256. Der ACU-Mindestwert von 0 ist nur für die Aurora-Versionen verfügbar, die die Auto-Pause-Funktion unterstützen.

Sie können die Skalierungskonfiguration eines Clusters, der Aurora serverless-DB-Instances enthält, über die API-Operation ModifyDBCluster ändern. Geben Sie den Parameter ServerlessV2ScalingConfiguration an, um die minimale und die maximale Kapazität zu konfigurieren. Zu den gültigen Kapazitätswerten gehören die folgenden:

• Aurora MySQL: 0, 0.5, 1, 1.5, 2 usw. in Schritten von 0,5 ACUs bis maximal 256.

• Aurora PostgreSQL: 0, 0.5, 1, 1.5, 2 usw. in Schritten von 0,5 ACUs bis maximal 256.

• Der ACU-Mindestwert von 0 ist nur für die Aurora-Versionen verfügbar, die die Auto-Pause-Funktion unterstützen.

Die maximal verfügbare Kapazität ist sowohl von der DB-Engine-Version als auch von der Plattformversion abhängig.

Die Kapazitätsänderung erfolgt sofort, unabhängig davon, ob Sie sie sofort oder während des nächsten geplanten Wartungsfensters anwenden möchten.

Aktualisieren des Aurora serverless-DB-Clusters, um eine Skalierung auf 256 ACUs zu ermöglichen

In einigen Fällen erhalten Sie eine Fehlermeldung, wenn Sie versuchen, Ihren Aurora serverless-DB-Cluster auf Kapazitäten von mehr als 128 ACUs zu skalieren. In der Fehlermeldung erfahren Sie, welche Instances mit dem neuen Skalierungsbereich nicht kompatibel sind. Dies unterstreicht die wichtige Beziehung zwischen Ihrem Kapazitätsbereich, der DB-Engine-Version und der Plattformversion.

Es gibt zwei mögliche Ursachen dafür, dass eine Skalierung auf mehr als 128 ACUs nicht möglich ist:

Überprüfen des Kapazitätsbereichs für Aurora serverless

Das Verfahren zur Überprüfung des Kapazitätsbereichs für Ihren Aurora serverless-Cluster erfordert, dass Sie zuerst einen Kapazitätsbereich festlegen. Wenn Sie dies noch nicht getan haben, gehen Sie wie unter Festlegen des Aurora serverless-Kapazitätsbereichs für einen Cluster beschrieben vor.

Der jeweilige Kapazitätsbereich, den Sie auf Cluster-Ebene festlegen, gilt für alle Aurora serverless-DB-Instances in Ihrem Cluster. Die folgende Abbildung zeigt einen Cluster mit mehreren Aurora serverless-DB-Instances. Jede Instance hat einen identischen Kapazitätsbereich.

Sie können auch die Detailseite für alle Aurora serverless-DB-Instances im Cluster anzeigen. Der Kapazitätsbereich der DB-Instances wird auf dem Tab Configuration (Konfiguration) angezeigt.

Sie können den aktuellen Kapazitätsbereich für den Cluster auch auf der Seite Modify (Ändern) für den Cluster sehen. An diesem Punkt können Sie den Kapazitätsbereich ändern. Alle Möglichkeiten, wie Sie den Kapazitätsbereich einstellen oder ändern können, finden Sie unter Festlegen des Aurora serverless-Kapazitätsbereichs für einen Cluster.

Überprüfen des aktuellen Kapazitätsbereichs für einen Aurora-Cluster

Sie können den Kapazitätsbereich überprüfen, der für Aurora serverless-DB-Instances in einem Cluster konfiguriert ist, indem Sie sich das ServerlessV2ScalingConfiguration-Attribut für den Cluster ansehen. Das folgende AWS CLI -Beispiel zeigt einen Cluster mit einer minimalen Kapazität von 0,5 Aurora-Kapazitätseinheiten (ACU) und einer maximalen Kapazität von 16 ACUs.

$ aws rds describe-db-clusters --db-cluster-identifier serverless-v2-64-acu-cluster \
  --query 'DBClusters[*].[ServerlessV2ScalingConfiguration]'
[
    [
        {
            "MinCapacity": 0.5,
            "MaxCapacity": 16.0
        }
    ]
]

Überprüfen Sie die Plattformversion für einen vorhandenen Cluster Aurora serverless

Die Plattformversion wird im Abschnitt Instanzkonfiguration der Instanz angezeigt.

Sie können den describe-db-clusters Befehl verwenden, um die Plattformversion auf vorhandene Cluster zu überprüfen.

Beispiel

aws rds describe-db-clusters \
    --db-cluster-identifier mydbcluster

Überprüfen Sie die Standard-Plattformversion

$ aws rds describe-serverless-v2-platform-versions 
{
    "ServerlessV2PlatformVersions": [
        {
            "Engine": "aurora-postgresql",
            "ServerlessV2PlatformVersion": "3",
            "ServerlessV2PlatformVersionDescription": "Version 3 powered by Graviton 3 processors offering scaling up to 256 ACUs, and performance improvement up to 30% compared to version 2"
            "ServerlessV2FeatureSupport": {
                "MinCapacity": 0
                "MaxCapacity": 256
            },
            "Status": "available",
            "IsDefault": True
        },
        ...
    ]
}

# describing the default platform version for an engine
$ aws rds describe-serverless-v2-platform-versions --engine aurora-postgresql --default-only
{
    "ServerlessV2PlatformVersions": [
        {
            "Engine": "aurora-postgresql",
            "ServerlessV2PlatformVersion": "3",
            "ServerlessV2PlatformVersionDescription": "Version 3 powered by Graviton 3 processors offering scaling up to 256 ACUs, and performance improvement up to 30% compared to version 2"
            "ServerlessV2FeatureSupport": {
                "MinCapacity": 0
                "MaxCapacity": 256
            },
            "Status": "available",
            "IsDefault": True
        }
    ]
}

Es wird nach ausstehenden Plattformversions-Upgrades gesucht

Sie können den describe-pending-maintenance-actions Befehl verwenden, um zu überprüfen, ob Upgrades der Plattformversionen für Ihre Aurora serverless DB-Cluster ausstehen.

Um nach ausstehenden Upgrades für einen bestimmten Cluster zu suchen, verwenden Sie den --resource-identifier Parameter, um den Amazon-Ressourcennamen (ARN) Ihres DB-Clusters anzugeben:

aws rds describe-pending-maintenance-actions \
    --resource-identifier arn:aws:rds:us-east-1:123456789012
    :cluster:my-serverless-cluster

Planung eines Upgrades der Plattformversion

Nachdem Sie ein ausstehendes Plattformversions-Upgrade identifiziert haben, können Sie den apply-pending-maintenance-action Befehl verwenden, um zu planen, wann das Upgrade durchgeführt wird.

Um ein Upgrade der Plattformversion zu planen, geben Sie die folgenden Parameter an:

Hinzufügen eines Aurora serverless-Readers

Wenn Sie Ihrem Cluster eine Aurora serverless-Reader-DB-Instance hinzufügen möchten, folgen Sie dem gleichen allgemeinen Verfahren wie in Hinzufügen von Aurora-Replicas zu einem DB-Cluster. Wählen Sie die Instance-Klasse Serverless v2 für die neue DB-Instance aus.

Wenn die Reader-DB-Instance die erste Aurora serverless-DB-Instance im Cluster ist, wählen Sie auch den Kapazitätsbereich aus. Diese Einstellung gilt für diese Reader-DB-Instance und für alle weiteren Aurora serverless-DB-Instances, die Sie dem Cluster hinzufügen. Jede Aurora serverless-DB-Instance kann zwischen dem minimalen und dem maximalen ACU-Wert skaliert werden.

Wenn im Cluster bereits andere Aurora serverless-Instances vorhanden sind, zeigt das Dialogfeld Reader hinzufügen den aktuellen Kapazitätsbereich für den Cluster an. In diesem Fall können Sie die Kapazität nicht ändern. Die folgende Abbildung zeigt den Bericht über die Kapazität des aktuellen Clusters.

Wenn Sie dem Cluster bereits Aurora serverless-DB-Instances hinzugefügt haben, wird Ihnen beim Hinzufügen weiterer Aurora serverless-Reader-DB-Instances der aktuelle Kapazitätsbereich angezeigt. Die folgende Abbildung zeigt diese schreibgeschützten Steuerelemente.

Wenn Sie den Kapazitätsbereich für den Cluster ändern möchten, gehen Sie vor, wie in Festlegen des Aurora serverless-Kapazitätsbereichs für einen Cluster bechrieben.

Bei Clustern, die mehr als eine Reader-DB-Instance enthalten, spielt die Failover-Priorität jeder Aurora serverless-Reader-DB-Instance eine wichtige Rolle dabei, wie diese DB-Instance hoch- oder herunterskaliert. Sie können die Priorität nicht angeben, wenn Sie den Cluster erstellen. Denken Sie an diese Eigenschaft, wenn Sie Ihrem Cluster einen zweiten Reader oder eine weitere DB-Instance hinzufügen. Weitere Informationen finden Sie unter Auswählen der Hochstufungsstufe für einen Aurora serverless-Reader.

Weitere Möglichkeiten zum Anzeigen des aktuellen Kapazitätsbereichs für einen Cluster finden Sie unter Überprüfen des Kapazitätsbereichs für Aurora serverless.

Konvertieren eines bereitgestellten Writers oder Readers in Aurora serverless

Sie können eine bereitgestellte DB-Instance konvertieren, um Aurora serverless zu verwenden. Befolgen Sie dazu die Anleitung unter Ändern einer DB-Instance in einem DB-Cluster. Der Cluster muss die Anforderungen in Anforderungen und Einschränkungen für Aurora serverless erfüllen. Aurora serverless-DB-Instances erfordern beispielsweise, dass der Cluster bestimmte Mindest-Engine-Versionen ausführt.

Angenommen, Sie konvertieren einen laufenden bereitgestellten Cluster, um Aurora serverless zu nutzen. In diesem Fall können Sie Ausfallzeiten minimieren, indem Sie im ersten Schritt des Umstellungsprozesses eine DB-Instance in Aurora serverless konvertieren. Das vollständige Verfahren finden Sie unter Konvertieren eines bereitgestellten Writers oder Readers in Aurora serverless.

Wenn die DB-Instance, die Sie konvertieren, die erste Aurora serverless-DB-Instance im Cluster ist, wählen Sie den Kapazitätsbereich für den Cluster im Rahmen der Operation Modify (Ändern) aus. Dieser Kapazitätsbereich gilt für jede Aurora serverless-DB-Instance, die Sie dem Cluster hinzufügen. Die folgende Abbildung zeigt die Seite, auf der Sie die minimalen und maximalen Aurora-Kapazitätseinheiten (ACUs) angeben.

Weitere Informationen zur Bedeutung des Kapazitätsbereichs finden Sie unter Kapazität von Aurora serverless.

Wenn der Cluster bereits eine oder mehrere Aurora serverless-DB-Instances enthält, sehen Sie den vorhandenen Kapazitätsbereich, wenn Sie die Operation Modify (Ändern) verwenden. Die folgende Abbildung zeigt ein Beispiel für dieses Informationsfeld.

Wenn Sie den Kapazitätsbereich für den Cluster ändern möchten, nachdem Sie weitere Aurora serverless-DB-Instances hinzugefügt haben, gehen Sie vor, wie in Festlegen des Aurora serverless-Kapazitätsbereichs für einen Cluster bechrieben.

Konvertieren eines Aurora serverless-Writers oder -Readers in bereitgestellt

Sie können eine Aurora serverless-DB-Instance in eine bereitgestellte DB-Instance konvertieren. Befolgen Sie dazu die Anleitung unter Ändern einer DB-Instance in einem DB-Cluster. Wählen Sie eine andere DB-Instance-Klasse als Serverless aus.

Sie können eine Aurora serverless-DB-Instance in eine bereitgestellte Instance konvertieren, wenn sie eine größere Kapazität benötigt, als mit den maximalen Aurora-Kapazitätseinheiten (ACUs) einer Aurora serverless-DB-Instance verfügbar ist. Zum Beispiel haben die größten DB-Instance-Klassen db.r5 und db.r6g eine größere Speicherkapazität als die Kapazität, auf die eine Aurora serverless-DB-Instance skalieren kann.

Wenn Sie die Writer-DB-Instance Ihres Clusters von Aurora serverless in eine bereitgestellte Instance konvertieren, können Sie die Vorgehensweise unter Konvertieren eines bereitgestellten Writers oder Readers in Aurora serverless verwenden. Stellen Sie eine der Reader-DB-Instances im Cluster von Aurora serverless auf eine bereitgestellte Instance um. Führen Sie ein Failover durch, damit diese bereitgestellte DB-Instance zur Writer-Instance wird.

Jeder Kapazitätsbereich, den Sie zuvor für den Cluster angegeben haben, bleibt bestehen, auch wenn alle Aurora serverless-DB-Instances aus dem Cluster entfernt werden. Wenn Sie den Kapazitätsbereich ändern möchten, können Sie den Cluster ändern, wie in Festlegen des Aurora serverless-Kapazitätsbereichs für einen Cluster erläutert.

Anhalten von Aurora serverless-DB-Instances

Sie können Aurora-Cluster so konfigurieren, dass ihre Aurora serverless-DB-Instances automatisch angehalten und fortgesetzt werden. Weitere Informationen finden Sie unter Skalierung auf 0 ACUs mit automatischem Anhalten und Fortsetzen für Aurora serverless.

Auswählen der Hochstufungsstufe für einen Aurora serverless-Reader

Bei Clustern mit mehreren Aurora serverless-DB-Instances oder mit einer Mischung aus bereitgestellten und Aurora serverless-DB-Instances achten Sie auf die Einstellung der Hochstufungsstufe für jede einzelne Aurora serverless-DB-Instance. Diese Einstellung steuert mehr Verhaltensweisen für Aurora serverless-DB-Instances als für bereitgestellte DB-Instances.

In der AWS-Managementkonsole geben Sie diese Einstellung mithilfe der Failover-Prioritätsauswahl unter Zusätzliche Konfiguration für die Seiten Datenbank erstellen, Instanz ändern und Leser hinzufügen an. Sie sehen diese Eigenschaft für vorhandene DB-Instances in der optionalen Spalte Priority tier(Prioritätsstufe) auf der Seite Databases (Datenbanken). Diese Eigenschaft können Sie auch der Detailseite für einen DB-Cluster oder eine DB-Instance entnehmen.

Bei bereitgestellten DB-Instances bestimmt die Auswahl der Stufe 0 bis 15 nur die Reihenfolge, in der Aurora entscheidet, welche Reader-DB-Instance während eines Failover-Vorgangs zum Writer hochgestuft werden soll. Für Aurora serverless-Reader-DB-Instances bestimmt die Stufennummer auch, ob die DB-Instance auf die Kapazität der Writer-DB-Instance hochskaliert oder unabhängig und basierend auf ihrer eigenen Workload skaliert wird. Aurora serverless-Reader-DB-Instances in Stufe 0 oder 1 werden auf einer minimalen Kapazität gehalten, die mindestens so hoch ist wie die der Writer-DB-Instance. Auf diese Weise sind sie im Falle eines Failovers zur Übernahme von der Writer-DB-Instance bereit. Wenn die Writer-DB-Instance eine bereitgestellte DB-Instance ist, schätzt Aurora die entsprechende Aurora serverless-Kapazität. Sie verwendet diese Schätzung als Mindestkapazität für die Aurora serverless-Reader-DB-Instance.

Aurora serverless-Reader-DB-Instances der Stufen 2 bis 15 haben nicht die gleiche Einschränkung ihrer minimalen Kapazität. Wenn sie inaktiv sind, können sie auf den minimalen Aurora-Kapazitätseinheitwert (ACU) herunterskaliert werden, der im Kapazitätsbereich des Clusters angegeben ist.

Das folgende AWS CLI Linux-Beispiel zeigt, wie Sie die Upgrade-Stufen aller DB-Instances in Ihrem Cluster untersuchen können. Das letzte Feld enthält den Wert True für die Writer-DB-Instance und False für alle Reader-DB-Instances.

$ aws rds describe-db-clusters --db-cluster-identifier promotion-tier-demo \
  --query 'DBClusters[*].DBClusterMembers[*].[PromotionTier,DBInstanceIdentifier,IsClusterWriter]' \
  --output text

1   instance-192  True
1   tier-01-4840  False
10  tier-10-7425  False
15  tier-15-6694  False

Das folgende AWS CLI Linux-Beispiel zeigt, wie Sie die Upgrade-Stufe einer bestimmten DB-Instance in Ihrem Cluster ändern können. Mit den Befehlen wird zuerst die DB-Instance geändert und eine neue Hochstufungsstufe festgelegt. Dann wird gewartet, bis die DB-Instance wieder verfügbar ist, und die neue Hochstufungsstufe für die DB-Instance bestätigt.

$ aws rds modify-db-instance --db-instance-identifier instance-192 --promotion-tier 0
$ aws rds wait db-instance-available --db-instance-identifier instance-192
$ aws rds describe-db-instances --db-instance-identifier instance-192 \
  --query '*[].[PromotionTier]' --output text
0

Weitere Hilfestellung zum Angeben von Hochstufungsstufen für verschiedene Anwendungsfälle finden Sie unter Aurora serverless-Skalierung.

Verwenden TLS/SSL mit Aurora serverless

Aurora serverlesskann das Transport Layer Security/Secure Sockets Layer (TLS/SSL) -Protokoll verwenden, um die Kommunikation zwischen Clients und Ihren Aurora serverless DB-Instances zu verschlüsseln. Es unterstützt die TLS/SSL Versionen 1.0, 1.1 und 1.2. Allgemeine Informationen zur Verwendung TLS/SSL mit Aurora finden Sie unterTLS-Verbindungen mit DB-Clustern von Aurora MySQL.

Weitere Informationen zum Verbinden mit der Aurora MySQL-Datenbank über den MySQL-Client finden Sie unter Verbinden mit einer DB-Instance, auf der die MySQL-Datenbank-Engine ausgeführt wird.

Aurora serverlessunterstützt alle TLS/SSL Modi, die für den MySQL-Client (mysql) und den PostgreSQL-Client (psql) verfügbar sind, einschließlich der in der folgenden Tabelle aufgeführten.

Aurora serverless nutzt Platzhalter-Zertifikate. Wenn Sie bei der Verwendung die Option „Verify CA“ oder „Verify CA and CA Hostname“ angeben TLS/SSL, laden Sie zuerst den Amazon Root CA 1 Trust Store von Amazon Trust Services herunter. Danach können Sie diese PEM-formatted Datei in Ihrem Client-Befehl identifizieren. Gehen Sie folgendermaßen vor, um diesen Vorgang mit dem PostgreSQL-Client auszuführen.

Für Linux, macOS oder Unix:

psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'

Weitere Informationen zum Arbeiten mit der Aurora PostgreSQL-Datenbank unter Verwendung des Postgres-Clients finden Sie unter Herstellen einer Verbindung zu einer DB-Instance, in der die PostgreSQL-Datenbank-Engine ausgeführt wird.

Weitere Informationen zum Verbinden mit Aurora-DB-Clustern im Allgemeinen finden Sie unter Herstellen einer Verbindung mit einem Amazon Aurora-DB-Cluster.

Unterstützte Verschlüsselungssammlungen für Verbindungen mit Aurora serverless-DB-Clustern

Durch die Verwendung von konfigurierbaren Chiffrier-Suiten können Sie mehr Kontrolle über die Sicherheit Ihrer Datenbankverbindungen haben. Sie können eine Liste von Cipher Suites angeben, denen Sie erlauben möchten, TLS/SSL Client-Verbindungen zu Ihrer Datenbank zu sichern. Mit konfigurierbaren Chiffrier-Suiten können Sie die Verbindungsverschlüsselung steuern, die Ihr Datenbankserver akzeptiert. Dadurch wird die Verwendung von Verschlüsselungsverfahren verhindert, die nicht sicher sind oder nicht mehr verwendet werden.

Aurora serverless-DB-Cluster, die auf Aurora MySQL basieren, unterstützen dieselben Verschlüsselungssammlungen wie von Aurora MySQL bereitgestellte DB-Cluster. Weitere Informationen über diese Verschlüsselungssammlungen finden Sie unter Konfigurieren von Cipher-Suites für Verbindungen mit Aurora-MySQL-DB-Clustern.

Aurora serverless-DB-Cluster, die auf Aurora MySQL basieren, unterstützen dieselben Verschlüsselungssammlungen wie von Aurora PostgreSQL bereitgestellte DB-Cluster. Weitere Informationen über diese Verschlüsselungssammlungen finden Sie unter Konfigurieren von Chiffrier-Suiten für Verbindungen mit Aurora-PostgreSQL-DB-Clustern.

Anzeigen von Aurora serverless-Writern und -Readern

Sie können sich die Details von Aurora serverless-DB-Instances auf die gleiche Weise anzeigen lassen wie für bereitgestellte DB-Instances. Befolgen Sie hierzu das allgemeine Verfahren unter Anzeigen eines DB-Clusters von Amazon Aurora. Ein Cluster könnte alle Aurora serverless-DB-Instances, alle bereitgestellten DB-Instances oder jeweils einige davon enthalten.

Nachdem Sie eine oder mehrere Aurora serverless-DB-Instances erstellt haben, können Sie anzeigen, welche DB-Instances den Typ Serverless (Serverlos) und welche den Typ Instance haben. Außerdem können Sie die minimalen und maximalen Aurora-Kapazitätseinheiten (ACUs) anzeigen, die die Aurora serverless-DB-Instance verwenden kann. Jede ACU ist eine Kombination aus Rechenkapazität (CPU) und Arbeitsspeicherkapazität (RAM). Dieser Kapazitätsbereich gilt für jede Aurora serverless-DB-Instance im Cluster. Informationen zum Verfahren zur Überprüfung des Kapazitätsbereichs eines Clusters oder einer Aurora serverless-DB-Instance im Cluster finden Sie unter Überprüfen des Kapazitätsbereichs für Aurora serverless.

In der AWS-Managementkonsole sind Aurora serverless DB-Instances in der Spalte Größe auf der Datenbankseite markiert. Bei bereitgestellten DB-Instances wird der Name einer DB-Instance-Klasse wie r6g.xlarge angezeigt. Die Aurora Serverless-DB-Instances zeigen Serverless (Serverlos) für die DB-Instance-Klasse sowie die minimale und maximale Kapazität der DB-Instance an. Es wird beispielsweise Serverless v2 (4–64 ACUs) oder Serverless v2 (1–40 ACUs) angezeigt.

Die gleichen Informationen finden Sie auf dem Tab Configuration (Konfiguration) für jede Aurora serverless-DB-Instance in der Konsole. Sie sehen beispielsweise einen Abschnitt Instance type (Instance-Typ) wie den folgenden. Hier ist der Wert Instance type (Instance-Typ) Serverless v2, der Wert Minimum capacity (Minimale Kapazität) beträgt 2 ACUs (4 GiB) und der Wert Maximum capacity (Maximale Kapazität) ist auf 64 ACUs (128 GiB) festgelegt.

Sie können die Kapazität jeder einzelnen Aurora serverless-DB-Instance im Zeitverlauf überwachen. Auf diese Weise können Sie die minimalen, maximalen und durchschnittlichen ACUs überprüfen, die von jeder DB-Instance verbraucht werden. Sie können auch überprüfen, wie nahe die DB-Instance an ihre minimale oder maximale Kapazität gekommen ist. Um solche Details in der zu sehen AWS-Managementkonsole, sehen Sie sich die Diagramme der CloudWatch Amazon-Metriken auf der Registerkarte Überwachung für die DB-Instance an. Weitere Informationen über die angezeigten Metriken und ihre Interpretation finden Sie unter Wichtige CloudWatch Amazon-Metriken für Aurora serverless.

Protokollierung für Aurora serverless

Wenn Sie die Datenbankprotokollierung aktivieren möchten, geben Sie die Protokolle an, die mithilfe von Konfigurationsparametern in Ihrer benutzerdefinierten Parametergruppe aktiviert werden sollen.

Für Aurora MySQL können Sie die folgenden Protokolle aktivieren.

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

Für Aurora PostgreSQL können Sie die folgenden Protokolle auf Ihren Aurora serverless-DB-Instances aktivieren.

Protokollierung mit Amazon CloudWatch

Nachdem Sie das Verfahren unter verwendet haben, Protokollierung für Aurora serverless um auszuwählen, welche Datenbankprotokolle aktiviert werden sollen, können Sie auswählen, welche Protokolle auf Amazon hochgeladen („veröffentlicht“) werden sollen CloudWatch.

Sie können Amazon verwenden CloudWatch , um Protokolldaten zu analysieren, Alarme zu erstellen und Metriken anzuzeigen. Standardmäßig sind Fehlerprotokolle für aktiviert und Aurora serverless werden automatisch in hochgeladen CloudWatch. Sie können auch andere Protokolle von Aurora serverless DB-Instances in hochladen CloudWatch.

Dann wählen Sie aus, in welche dieser Protokolle Sie hochladen möchten CloudWatch, indem Sie die Einstellungen für Protokollexporte in AWS-Managementkonsole oder die --enable-cloudwatch-logs-exports Option in der verwenden AWS CLI.

Sie können wählen, in welche Ihrer Aurora serverless Protokolle Sie hochladen möchten CloudWatch. Weitere Informationen finden Sie unter Verwenden von Advanced Auditing in einem Amazon Aurora MySQL DB-Cluster.

Wie bei jedem Typ von Aurora-DB-Cluster können Sie die standardmäßige DB-Cluster-Parametergruppe nicht ändern. Erstellen Sie stattdessen Ihre eigene DB-Cluster-Parametergruppe basierend auf einem Standardparameter für Ihren DB-Cluster und Engine-Typ. Sie sollten Ihre benutzerdefinierte DB-Cluster-Parametergruppe erstellen, bevor Sie Ihren Aurora serverless-DB-Cluster erstellen, damit Sie diese auswählen können, wann Sie eine Datenbank in der Konsole erstellen.

Aurora serverlessLogs in Amazon anzeigen CloudWatch

Nachdem Sie das Verfahren unter Protokollierung mit Amazon CloudWatch verwendet haben, um auszuwählen, welche Datenbankprotokolle aktiviert werden sollen, können Sie den Inhalt der Protokolle anzeigen.

Weitere Informationen zur Verwendung CloudWatch mit Aurora MySQL- und Aurora PostgreSQL-Protokollen finden Sie unter Überwachen von Protokollereignissen in Amazon CloudWatch und. Veröffentlichen von Aurora PostgreSQL-Protokollen in Amazon Logs CloudWatch

Kapazität mit Amazon überwachen CloudWatch

Mit Aurora serverless CloudWatch können Sie die Kapazität und Auslastung aller Aurora serverless DB-Instances in Ihrem Cluster überwachen. Sie können Metriken auf Instance-Ebene anzeigen, um die Kapazität jeder einzelnen Aurora serverless-DB-Instance beim Hoch- und Herunterskalieren zu überprüfen. Sie können die kapazitätsbezogenen Metriken auch mit anderen Metriken vergleichen, um zu sehen, wie sich Änderungen an Workloads auf den Ressourcenverbrauch auswirken. Sie können beispielsweise ServerlessDatabaseCapacity mit DatabaseUsedMemory, DatabaseConnections und DMLThroughput vergleichen, um einzuschätzen, wie Ihr DB-Cluster während des Betriebs reagiert. Weitere Informationen zu den kapazitätsbezogenen Metriken, die für Aurora serverless gelten, finden Sie unter Wichtige CloudWatch Amazon-Metriken für Aurora serverless.

Wir empfehlen Ihnen, ein CloudWatch Dashboard einzurichten, um Ihre Aurora serverless DB-Cluster-Kapazität anhand der kapazitätsbezogenen Metriken zu überwachen. Wie das geht, erfahren Sie unter Dashboards erstellen mit. CloudWatch

Weitere Informationen zur Verwendung von Amazon CloudWatch mit Amazon Aurora finden Sie unterVeröffentlichen von Amazon Aurora MySQL-Protokollen in Amazon CloudWatch Logs.

Überwachen von Aurora serverless-Aktivitäten zum Anhalten und Fortsetzen

Aurora schreibt eine separate Protokolldatei für Aurora serverless-DB-Instances mit aktivierter Auto-Pause-Funktion. Aurora schreibt für jedes 10-Minuten-Intervall, in dem die Instance nicht angehalten wurde, in das Protokoll. Aurora speichert bis zu sieben dieser Protokolle, die täglich rotiert werden. Die aktuelle Protokolldatei hat den Namen instance.log und ältere Protokolle werden nach dem Muster instance.YYYY-MM-DD.N.log benannt.

Dieses Protokoll ist für Aurora serverless-DB-Instances standardmäßig aktiviert, bei denen die Auto-Pause-Funktion aktiviert ist. Sie können den Inhalt dieses Protokolls in AWS-Managementkonsole oder mithilfe der AWS CLI oder RDSP-API anzeigen. Derzeit können Sie dieses Protokoll nicht hochladen. CloudWatch

Die unter DB-Instance-Ereignisse aufgeführten Ereignisse bieten einen allgemeinen Überblick über die Aktivitäten zum Anhalten und Fortsetzen, u. a. folgende:

instance.log bietet detailliertere Informationen zu den Gründen, warum eine Aurora serverless-Instance angehalten oder nicht angehalten werden kann.

Das Protokoll könnte darauf hinweisen, dass eine Instance aus verschiedenen Gründen fortgesetzt wurde:

Wenn Aurora keine Bedingungen feststellt, die verhindern würden, dass die Instance nach Ablauf des Auto-Pause-Intervalls angehalten wird, wird regelmäßig eine Informationsmeldung in das Protokoll geschrieben. Bei Clustern mit nur einer DB-Instance enthält das Protokoll die folgende Meldung:

[INFO] No auto-pause blockers registered since time

Bei Clustern mit mehreren DB-Instances unterscheidet sich die Meldung geringfügig. Das liegt daran, dass ein Writer aufgrund von Aktivitäten auf einer der Reader-Instances möglicherweise nicht angehalten werden kann. Wenn die Aktivität auf dem Reader beendet wird, bevor das Auto-Pause-Intervall auf dem Writer abläuft, kann der Writer zur erwarteten Zeit angehalten werden.

[INFO] No auto-pause blockers registered since time.
Database might be required to maintain compute capacity for high availability.

Wenn eine Operation zum Anhalten gestartet wird, aber eine neue Datenbankverbindungsanforderung eingeht, bevor die Instance das Anhalten beendet hat, enthält das Protokoll die folgende Meldung:

[INFO] Unable to pause database due to a new database activity

Wenn Aurora Bedingungen feststellt, die definitiv verhindern, dass die Instance angehalten werden kann, enthält das Protokoll die folgende Meldung mit einer Auflistung aller dieser Bedingungen:

[INFO] Auto-pause blockers registered since time: list_of_conditions

Auf diese Weise verhindert Aurora nicht, dass Sie Replikation, Null-ETL-Integration, Aurora Global Database usw. in Kombination mit der Auto-Pause-Funktion aktivieren. Das Protokoll informiert Sie darüber, wenn die Verwendung solcher Funktionen möglicherweise verhindert, dass die Auto-Pause-Funktion wirksam wird.

Aus den folgenden Gründen kann eine Aurora serverless-Instance das Timeout-Intervall für das automatische Anhalten überschreiten, aber daran gehindert werden, anzuhalten: