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.

Leistung und Skalierung für Aurora Serverless v2

Die folgenden Verfahren und Beispiele zeigen, wie Sie den Kapazitätsbereich für festlegen können Aurora Serverless v2 Cluster und ihre zugehörigen DB-Instances. Sie können die folgenden Verfahren auch verwenden, um zu überwachen, wie ausgelastet Ihre DB-Instances sind. Anschließend können Sie anhand Ihrer Ergebnisse feststellen, ob Sie den Kapazitätsbereich nach oben oder unten anpassen müssen.

Bevor Sie diese Verfahren anwenden, stellen Sie sicher, dass Sie mit der Vorgehensweise vertraut sind Aurora Serverless v2 Skalierung funktioniert. Der Skalierungsmechanismus ist anders als in Aurora Serverless v1. Einzelheiten finden Sie unterAurora Serverless v2 Skalierung.

Auswahl der Aurora Serverless v2 Kapazitätsbereich für einen Aurora-Cluster

Mit Aurora Serverless v2 DB-Instances legen Sie den Kapazitätsbereich fest, der für alle DB-Instances in Ihrem DB-Cluster gilt, und fügen gleichzeitig die ersten hinzu Aurora Serverless v2 DB-Instance für den DB-Cluster. Weitere Informationen zum entsprechenden Verfahren finden Sie unter Einstellung der Aurora Serverless v2 Kapazitätsbereich für einen Cluster.

Sie können den Kapazitätsbereich für einen vorhandenen Cluster auch ändern. In den folgenden Abschnitten wird ausführlicher beschrieben, wie Sie geeignete Mindest- und Höchstwerte auswählen und was passiert, wenn Sie den Kapazitätsbereich ändern. Durch Ändern des Kapazitätsbereichs können sich beispielsweise die Standardwerte einiger Konfigurationsparameter ändern. Das Anwenden aller Parameteränderungen kann einen Neustart der einzelnen Änderungen erfordern Aurora Serverless v2 DB-Instance.

Wählen Sie das Minimum Aurora Serverless v2 Kapazitätseinstellung für einen Cluster

Es ist verlockend, immer 0,5 als Minimum zu wählen Aurora Serverless v2 Kapazitätseinstellung. Dieser Wert ermöglicht es der DB-Instance, am meisten herunterzuskalieren, wenn sie vollständig inaktiv ist. Je nachdem, wie Sie diesen Cluster verwenden und wie die anderen Einstellungen konfiguriert sind, ist jedoch ein anderer Wert ggf. am effektivsten. Berücksichtigen Sie bei der Auswahl der Mindestkapazitätseinstellung die folgenden Faktoren:

Wählen Sie das Maximum Aurora Serverless v2 Kapazitätseinstellung für einen Cluster

Es ist verlockend, immer einen hohen Wert für das Maximum zu wählen Aurora Serverless v2 Kapazitätseinstellung. Eine große maximale Kapazität ermöglicht es der DB-Instance, bei intensiver Workload am stärksten hochzuskalieren. Mit einem niedrigen Wert entfällt die Möglichkeit unerwarteter Gebühren. Je nachdem, wie Sie diesen Cluster verwenden und die anderen Einstellungen konfigurieren, kann der effektivste Wert höher oder niedriger sein, als Sie ursprünglich dachten. Berücksichtigen Sie bei der Auswahl der maximalen Kapazitätseinstellung die folgenden Faktoren:

Beispiel: Ändern Sie den Aurora Serverless v2 Kapazitätsbereich eines Aurora My SQL Clusters

Das folgende AWS CLI Beispiel zeigt, wie der ACU Bereich aktualisiert wird für Aurora Serverless v2 DB-Instances in einem bestehenden Aurora SQL My-Cluster. Anfänglich liegt der Kapazitätsbereich für den Cluster zwischen 8 und 32. ACUs

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 8.0,
    "MaxCapacity": 32.0
}

Die DB-Instance befindet sich im Leerlauf und wurde auf 8 herunterskaliert. ACUs Die folgenden kapazitätsbezogenen Einstellungen gelten zu diesem Zeitpunkt für die DB-Instance. Zum Darstellen der Größe des Pufferpools in leicht lesbaren Einheiten teilen wir ihn durch 2 hoch 30, was zu einer Messung in Gibibyte (GiB) führt. Das liegt daran, dass speicherbezogene Messungen für Aurora Einheiten verwenden, die auf Zweierpotenzen und nicht auf Zehnerpotenzen basieren.

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              3000 |
+-------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                9294577664 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
|   8.65625 |
+-----------+
1 row in set (0.00 sec)

Als Nächstes ändern wir den Kapazitätsbereich für den Cluster. Nach Abschluss des modify-db-cluster Befehls liegt der ACU Bereich für den Cluster zwischen 12,5 und 80.

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 12.5,
    "MaxCapacity": 80.0
}

Durch Ändern des Kapazitätsbereichs können sich die Standardwerte einiger Konfigurationsparameter ändern. Aurora kann einige dieser neuen Standardwerte sofort anwenden. Einige der Parameteränderungen werden jedoch erst nach einem Neustart wirksam. Der Status pending-reboot gibt an, dass ein Neustart erforderlich ist, um einige Parameteränderungen anzuwenden.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "pending-reboot"
        }
    ]
}

Zu diesem Zeitpunkt befindet sich der Cluster im Leerlauf und die DB-Instance verbraucht 12,5serverless-v2-instance-1. ACUs Der innodb_buffer_pool_size-Parameter ist bereits basierend auf der aktuellen Kapazität der DB-Instance angepasst. Der max_connections-Parameter spiegelt immer noch den Wert der früheren maximalen Kapazität wider. Das Zurücksetzen dieses Werts erfordert einen Neustart der DB-Instance.

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              3000 |
+-------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               15572402176 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+---------------+
| gibibytes     |
+---------------+
| 14.5029296875 |
+---------------+
1 row in set (0.00 sec)

Jetzt starten wir die DB-Instance neu und warten darauf, dass sie wieder verfügbar ist.

aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBInstanceStatus": "rebooting"
}

aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

Der pending-reboot-Status ist gelöscht. Der Wert in-sync bestätigt, dass Aurora alle ausstehenden Parameteränderungen übernommen hat.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "in-sync"
        }
    ]
}

Der innodb_buffer_pool_size-Parameter hat sich auf seine endgültige Größe für eine inaktive DB-Instance erhöht. Der max_connections Parameter wurde erhöht, um einen vom ACU Maximalwert abgeleiteten Wert widerzuspiegeln. Die Formel, die Aurora für max_connections verwendet, führt zu einem Anstieg von 1.000, wenn sich die Speichergröße verdoppelt.

mysql> select @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|               16139681792 |
+---------------------------+
1 row in set (0.00 sec)

mysql> select @@innodb_buffer_pool_size / pow(2,30) as gibibytes;
+-----------+
| gibibytes |
+-----------+
|  15.03125 |
+-----------+
1 row in set (0.00 sec)

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|              4000 |
+-------------------+
1 row in set (0.00 sec)

Wir setzen den Kapazitätsbereich auf 0,5—128 ACUs und starten die DB-Instance neu. Jetzt hat die inaktive DB-Instance eine Puffer-Cache-Größe von weniger als 1 GiB. Daher messen wir sie nun in Mebibyte (MiB). Der max_connections-Wert 5.000 wird von der Speichergröße der maximalen Kapazitätseinstellung abgeleitet.

mysql> select @@innodb_buffer_pool_size / pow(2,20) as mebibytes, @@max_connections;
+-----------+-------------------+
| mebibytes | @@max_connections |
+-----------+-------------------+
|       672 |              5000 |
+-----------+-------------------+
1 row in set (0.00 sec)

Beispiel: Ändern Sie den Aurora Serverless v2 Kapazitätsbereich eines Aurora Postgre-Clusters SQL

Die folgenden CLI Beispiele zeigen, wie der ACU Bereich aktualisiert wird für Aurora Serverless v2 DB-Instances in einem vorhandenen Aurora SQL Postgre-Cluster.

Die folgende Abbildung zeigt die Kapazitätsänderungen in Amazon CloudWatch.

Die DB-Instance befindet sich im Leerlauf und wurde auf 0,5 ACUs herunterskaliert. Die folgenden kapazitätsbezogenen Einstellungen gelten zu diesem Zeitpunkt für die DB-Instance.

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

Als Nächstes ändern wir den Kapazitätsbereich für den Cluster. Nach Abschluss des modify-db-cluster Befehls liegt der ACU Bereich für den Cluster zwischen 8,0 und 32.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 8.0,
    "MaxCapacity": 32.0
}

Durch Ändern des Kapazitätsbereichs können sich die Standardwerte einiger Konfigurationsparameter ändern. Aurora kann einige dieser neuen Standardwerte sofort anwenden. Einige der Parameteränderungen werden jedoch erst nach einem Neustart wirksam. Der Status pending-reboot gibt an, dass ein Neustart erforderlich ist, um einige Parameteränderungen anzuwenden.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "pending-reboot"
        }
    ]
}

Zu diesem Zeitpunkt befindet sich der Cluster im Leerlauf und die DB-Instance verbraucht 8,0serverless-v2-instance-1. ACUs Der shared_buffers-Parameter ist bereits basierend auf der aktuellen Kapazität der DB-Instance angepasst. Der max_connections-Parameter spiegelt immer noch den Wert der früheren maximalen Kapazität wider. Das Zurücksetzen dieses Werts erfordert einen Neustart der DB-Instance.

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)

Wir starten die DB-Instance neu und warten darauf, dass sie wieder verfügbar ist.

aws rds reboot-db-instance --db-instance-identifier serverless-v2-instance-1
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBInstanceStatus": "rebooting"
}

aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1

Nachdem die DB-Instance neu gestartet wurde, ist der Status pending-reboot gelöscht. Der Wert in-sync bestätigt, dass Aurora alle ausstehenden Parameteränderungen übernommen hat.

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query '*[].{DBClusterMembers:DBClusterMembers[*].{DBInstanceIdentifier:DBInstanceIdentifier,DBClusterParameterGroupStatus:DBClusterParameterGroupStatus}}|[0]'
{
    "DBClusterMembers": [
        {
            "DBInstanceIdentifier": "serverless-v2-instance-1",
            "DBClusterParameterGroupStatus": "in-sync"
        }
    ]
}

Nach dem Neustart zeigt max_connections den Wert der neuen maximalen Kapazität an.

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 1425408
(1 row)

Als Nächstes ändern wir den Kapazitätsbereich für den Cluster auf ACUs 12,5—80.

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=12.5,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 12.5,
    "MaxCapacity": 80.0
}

Zu diesem Zeitpunkt befindet sich der Cluster im Leerlauf und die DB-Instance verbraucht 12,5serverless-v2-instance-1. ACUs Der shared_buffers-Parameter ist bereits basierend auf der aktuellen Kapazität der DB-Instance angepasst. Der max_connections-Wert beträgt immer noch 5 000.

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)

Wir führen einen weiteren Neustart durch, aber die Parameterwerte bleiben gleich. Das liegt daran, max_connections dass es einen Maximalwert von 5000 für einen hat Aurora Serverless v2 DB-Cluster, auf dem Aurora Postgre SQL ausgeführt wird.

postgres=> show max_connections;
 max_connections
-----------------
 5000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 2211840
(1 row)

Jetzt legen wir den Kapazitätsbereich von 0,5 bis 128 ACUs fest. Der DB-Cluster wird auf 10 ACUs und dann auf 2 herunterskaliert. Wir starten die DB-Instance neu.

postgres=> show max_connections;
 max_connections
-----------------
 2000
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

Der max_connections Wert für Aurora Serverless v2 DB-Instances basieren auf der Speichergröße, die sich aus dem Maximum ergibtACUs. Wenn Sie jedoch eine Mindestkapazität von 0,5 für SQL Postgre-kompatible DB-Instances angeben, max_connections ist der Höchstwert von ACUs auf 2.000 begrenzt.

Jetzt setzen wir die Kapazität auf ihren ursprünglichen Bereich von 0,5—1 zurück ACU und starten die DB-Instance neu. Der max_connections-Parameter ist auf seinen ursprünglichen Wert zurückgekehrt.

postgres=> show max_connections;
 max_connections
-----------------
 189
(1 row)

postgres=> show shared_buffers;
 shared_buffers
----------------
 16384
(1 row)

Arbeiten mit Parametergruppen für Aurora Serverless v2

Wenn Sie Ihre erstellen Aurora Serverless v2 DB-Cluster, Sie wählen eine bestimmte Aurora-DB-Engine und eine zugehörige DB-Cluster-Parametergruppe aus. Wenn Sie nicht damit vertraut sind, wie Aurora Parametergruppen verwendet, um Konfigurationseinstellungen konsistent auf Cluster anzuwenden, finden Sie weitere Informationen unter Parametergruppen für Amazon Aurora. Alle diese Verfahren zum Erstellen, Ändern, Anwenden und anderen Aktionen für Parametergruppen gelten für Aurora Serverless v2.

Die Parametergruppenfunktion funktioniert im Allgemeinen auf dieselbe Weise zwischen bereitgestellten Clustern und Clustern, die Folgendes enthalten Aurora Serverless v2 DB-Instances:

Standard-Parameterwerte

Der entscheidende Unterschied zwischen bereitgestellten DB-Instances und Aurora Serverless v2 Bei DB-Instances überschreibt Aurora alle benutzerdefinierten Parameterwerte für bestimmte Parameter, die sich auf die DB-Instance-Kapazität beziehen. Die benutzerdefinierten Parameterwerte gelten weiterhin für alle bereitgestellten DB-Instances in Ihrem Cluster. Weitere Informationen darüber, wie Aurora Serverless v2 DB-Instances interpretieren die Parameter aus Aurora-Parametergruppen, sieheKonfigurationsparameter für Aurora-Cluster. Für die spezifischen Parameter, die Aurora Serverless v2 überschreibt, siehe Parameter, die Aurora anpasst als Aurora Serverless v2 skaliert nach oben und unten undParameter, auf deren Grundlage Aurora berechnet Aurora Serverless v2 maximale Kapazität.

Sie können eine Liste der Standardwerte für die Standardparametergruppen für die verschiedenen Aurora-DB-Engines abrufen, indem Sie den describe-db-cluster-parametersCLIBefehl verwenden und die AWS-Region abfragen. Die folgenden Werte können Sie für die --db-parameter-group-family und -db-parameter-group-name Optionen für Engine-Versionen verwenden, die kompatibel sind mit Aurora Serverless v2.

Im folgenden Beispiel wird eine Liste von Parametern aus der Standard-DB-Clustergruppe für Aurora My SQL Version 3 und Aurora Postgre SQL 13 abgerufen. Dies sind die SQL Versionen Aurora My SQL und Aurora Postgre, die Sie mit verwenden Aurora Serverless v2.

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

aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name default.aurora-mysql8.0 \
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
  --output text

aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name default.aurora-postgresql13 \
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' \
  --output text

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

aws rds describe-db-cluster-parameters ^
  --db-cluster-parameter-group-name default.aurora-mysql8.0 ^
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
  --output text

aws rds describe-db-cluster-parameters ^
  --db-cluster-parameter-group-name default.aurora-postgresql13 ^
  --query 'Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | 
    [?contains(SupportedEngineModes, `provisioned`) == `true`] | [*].[ParameterName]' ^
  --output text

Maximale Anzahl an Verbindungen für Aurora Serverless v2

Sowohl für Aurora My als SQL auch für Aurora Postgre SQL Aurora Serverless v2 DB-Instances halten den max_connections Parameter konstant, sodass Verbindungen nicht unterbrochen werden, wenn die DB-Instance herunterskaliert wird. Der Standardwert für diesen Parameter leitet sich von einer Formel ab, die auf der Speichergröße der DB-Instance beruht. Weitere Informationen zur Formel und zu den Standardwerten für bereitgestellte DB-Instance-Klassen finden Sie unter Maximale Anzahl an Verbindungen zu einer Aurora My SQL DB-Instance und Maximale Anzahl an Verbindungen zu einer Aurora SQL Postgre-DB-Instance.

Wann Aurora Serverless v2 wertet die Formel aus und verwendet die Speichergröße auf der Grundlage der maximalen Aurora-Kapazitätseinheiten (ACUs) für die DB-Instance, nicht auf dem aktuellen ACU Wert. Wenn Sie den Standardwert ändern, empfehlen wir, eine Variante der Formel zu verwenden, anstatt einen konstanten Wert anzugeben. Auf diese Weise Aurora Serverless v2 kann eine geeignete Einstellung verwenden, die auf der maximalen Kapazität basiert.

Wenn Sie die maximale Kapazität eines ändern Aurora Serverless v2 DB-Cluster, Sie müssen den neu starten Aurora Serverless v2 DB-Instances, um den max_connections Wert zu aktualisieren. Das liegt daran, dass max_connections es sich um einen statischen Parameter handelt für Aurora Serverless v2.

Die folgende Tabelle zeigt die Standardwerte max_connections für Aurora Serverless v2 basierend auf dem ACU Maximalwert.

Konkrete Beispiele, die zeigen, wie max_connections sich der ACU Maximalwert ändert, finden Sie unter und. Beispiel: Ändern Sie den Aurora Serverless v2 Kapazitätsbereich eines Aurora My SQL Clusters Beispiel: Ändern Sie den Aurora Serverless v2 Kapazitätsbereich eines Aurora Postgre-Clusters SQL

Parameter, die Aurora anpasst als Aurora Serverless v2 skaliert nach oben und unten

Während der automatischen Skalierung Aurora Serverless v2 muss in der Lage sein, die Parameter für jede DB-Instance so zu ändern, dass sie für die erhöhte oder verringerte Kapazität am besten funktionieren. Daher können Sie einige Parameter im Zusammenhang mit der Kapazität nicht außer Kraft setzen. Vermeiden Sie bei einigen Parametern, die Sie außer Kraft setzen können, eine Hartcodierung fester Werte. Die folgenden Überlegungen gelten für diese Einstellungen, die sich auf die Kapazität beziehen.

Für Aurora My SQL Aurora Serverless v2 passt die Größe einiger Parameter während der Skalierung dynamisch an. Für die folgenden Parameter Aurora Serverless v2 verwendet keine benutzerdefinierten Parameterwerte, die Sie angeben:

Für Aurora Postgre SQL Aurora Serverless v2 ändert die Größe des folgenden Parameters dynamisch während der Skalierung. Für die folgenden Parameter Aurora Serverless v2 verwendet keine benutzerdefinierten Parameterwerte, die Sie angeben:

Für alle Parameter außer den hier aufgeführten Aurora Serverless v2 DB-Instances funktionieren genauso wie bereitgestellte DB-Instances. Der Standardparameterwert wird von der Cluster-Parametergruppe geerbt. Sie können den Standardwert für den gesamten Cluster mit einer benutzerdefinierten Cluster-Parametergruppe ändern. Den Standardwert für bestimmte DB-Instances können Sie auch mithilfe einer benutzerdefinierten DB-Parametergruppe ändern. Die dynamischen Parameter werden sofort aktualisiert. Änderungen an statischen Parametern werden erst wirksam, nachdem Sie die DB-Instance neu gestartet haben.

Parameter, auf deren Grundlage Aurora berechnet Aurora Serverless v2 maximale Kapazität

Für die folgenden Parameter SQL verwendet Aurora Postgre Standardwerte, die von der Speichergröße basierend auf der ACU Maximaleinstellung abgeleitet werden, genau wie beimax_connections:

Fehler vermeiden out-of-memory

Wenn einer deiner Aurora Serverless v2 DB-Instances erreichen ständig die Grenze ihrer maximalen Kapazität. Aurora weist auf diesen Zustand hin, indem sie die DB-Instance auf den Status von setztincompatible-parameters. Während die DB-Instance den Status incompatible-parameters aufweist, sind einige Operationen blockiert. Beispielsweise können Sie die Engine-Version nicht aktualisieren.

In der Regel wechselt Ihre DB-Instance in diesen Status, wenn sie aufgrund von out-of-memory Fehlern häufig neu gestartet wird. Aurora zeichnet ein Ereignis auf, wenn diese Art von Neustart stattfindet. Sie können das Ereignis anzeigen, indem Sie die Vorgehensweise unter RDSAmazon-Ereignisse anzeigen befolgen. Eine ungewöhnlich hohe Speicherauslastung kann aufgrund des Mehraufwands beim Aktivieren von Einstellungen wie Performance Insights und IAM Authentifizierung auftreten. Sie kann auch durch eine hohe Workload Ihrer DB-Instance oder durch die Verwaltung der Metadaten entstehen, die mit einer großen Anzahl von Schemaobjekten verknüpft sind.

Wenn die Speicherauslastung sinkt, sodass die DB-Instance ihre maximale Kapazität nicht sehr oft erreicht, ändert Aurora den Status der DB-Instance automatisch wieder in available.

Zur Wiederherstellung nach diesem Zustand können Sie einige oder alle der folgenden Aktionen ausführen:

Wichtige CloudWatch Amazon-Metriken für Aurora Serverless v2

Um mit Amazon zu beginnen CloudWatch für Ihren Aurora Serverless v2 DB-Instance, sieheWird angezeigt Aurora Serverless v2 loggt sich bei Amazon ein CloudWatch. Weitere Informationen zur Überwachung von Aurora-DB-Clustern finden CloudWatch Sie unterÜberwachen von Protokollereignissen in Amazon CloudWatch.

Sie können Ihre ansehen Aurora Serverless v2 DB-Instances in CloudWatch , um die von jeder DB-Instance verbrauchte Kapazität anhand der ServerlessDatabaseCapacity Metrik zu überwachen. Sie können auch alle CloudWatch Aurora-Standardmetriken wie DatabaseConnections und überwachenQueries. Die vollständige Liste der CloudWatch Metriken, die Sie für Aurora überwachen können, finden Sie unter CloudWatch Amazon-Metriken für Amazon Aurora. Die Metriken sind in Metriken auf Clusterebene für Amazon Aurora und Metriken auf Instance-Ebene für Amazon Aurora in Metriken auf Cluster-Ebene und auf Instance-Ebene unterteilt.

Es ist wichtig, die folgenden Metriken CloudWatch auf Instanzebene zu überwachen, damit Sie verstehen, wie Aurora Serverless v2 DB-Instances werden nach oben und unten skaliert. Alle diese Metriken werden jede Sekunde berechnet. Auf diese Weise können Sie den aktuellen Status Ihrer Aurora Serverless v2 DB-Instances. Sie können Alarme so einstellen, dass Sie bei Bedarf benachrichtigt werden Aurora Serverless v2 Die DB-Instance nähert sich einem Schwellenwert für Kapazitätsmetriken. Sie können feststellen, ob die minimalen und maximalen Kapazitätseinstellungen angemessen sind oder ob Sie sie anpassen müssen. Sie können bestimmen, worauf Sie sich konzentrieren müssen, um die Effizienz Ihrer Datenbank zu optimieren.

In der Regel skalieren die meisten für Aurora Serverless v2 DB-Instances werden durch Speichernutzung und CPU Aktivität verursacht. Die Metriken TempStorageIops und TempStorageThroughput können Ihnen helfen, die seltenen Fälle zu diagnostizieren, in denen die Netzwerkaktivität für Übertragungen zwischen Ihrer DB-Instance und lokalen Speichergeräten für unerwartete Kapazitätssteigerungen verantwortlich ist. Wenn Sie andere Netzwerkaktivitäten überwachen möchten, können Sie diese vorhandenen Metriken verwenden:

Sie können Aurora einige oder alle Datenbankprotokolle veröffentlichen lassen CloudWatch. Sie wählen die zu veröffentlichenden Protokolle aus, indem Sie die Konfigurationsparameter wie general_log und slow_query_log in der DB-Cluster-Parametergruppe aktivieren, die dem Cluster zugeordnet ist, der Ihre Aurora Serverless v2 DB-Instances. Wenn Sie einen Protokollkonfigurationsparameter deaktivieren, wird die Veröffentlichung dieses Protokolls CloudWatch beendet. Sie können die Logs auch löschen CloudWatch , wenn sie nicht mehr benötigt werden.

Wie Aurora Serverless v2 Die Metriken gelten für Ihre AWS Rechnung

Das Tool Aurora Serverless v2 Die Gebühren auf Ihrer AWS Rechnung werden auf der Grundlage derselben ServerlessDatabaseCapacity Kennzahl berechnet, die Sie überwachen können. Der Abrechnungsmechanismus kann in Fällen, in denen Sie Folgendes verwenden, vom berechneten CloudWatch Durchschnitt für diese Kennzahl abweichen Aurora Serverless v2 Kapazität nur für einen Teil einer Stunde. Es kann auch unterschiedlich sein, ob die CloudWatch Metrik aufgrund von Systemproblemen für kurze Zeit nicht verfügbar ist. Daher wird auf Ihrer Rechnung möglicherweise ein etwas anderer Wert für ACU -Stunden angezeigt, als wenn Sie die Zahl selbst anhand des ServerlessDatabaseCapacity Durchschnittswerts berechnen würden.

Beispiele für CloudWatch Befehle für Aurora Serverless v2 Kennzahlen

Die folgenden AWS CLI Beispiele zeigen, wie Sie die wichtigsten CloudWatch Kennzahlen im Zusammenhang mit folgenden Themen überwachen können Aurora Serverless v2. Ersetzen Sie in jedem Fall die Value= Zeichenfolge für den --dimensions Parameter durch Ihren eigenen Bezeichner Aurora Serverless v2 DB-Instance.

Im folgenden Linux-Beispiel werden die minimalen, maximalen und durchschnittlichen Kapazitätswerte für eine DB-Instance angezeigt, die alle 10 Minuten über einen Zeitraum von einer Stunde gemessen werden. Der Linux-Befehl date gibt die Start- und Endzeiten relativ zum aktuellen Datum und zur aktuellen Uhrzeit an. Die sort_by-Funktion im --query-Parameter sortiert die Ergebnisse chronologisch basierend auf dem Feld Timestamp.

aws cloudwatch get-metric-statistics --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

Die folgenden Linux-Beispiele veranschaulichen die Überwachung der Kapazität jeder DB-Instance in einem Cluster. Sie messen die minimale, maximale und durchschnittliche Kapazitätsauslastung jeder DB-Instance. Die Messungen werden einmal pro Stunde über einen Zeitraum von drei Stunden durchgeführt. In diesen Beispielen wird die ACUUtilization Metrik verwendet, die einen Prozentsatz der Obergrenze für ServerlessDatabaseCapacity darstelltACUs, anstatt eine feste Zahl vonACUs. Auf diese Weise müssen Sie die tatsächlichen Zahlen für die Mindest- und ACU Höchstwerte im Kapazitätsbereich nicht kennen. Sie können Prozentsätze zwischen 0 und 100 sehen.

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
  --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_writer_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

aws cloudwatch get-metric-statistics --metric-name "ACUUtilization" \
  --start-time "$(date -d '3 hours ago')" --end-time "$(date -d 'now')" --period 3600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_reader_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

Im folgenden Linux-Beispiel werden ähnliche Messungen wie die vorherigen ausgeführt. In diesem Fall gelten die Messungen für die CPUUtilization-Metrik Die Messungen werden alle zehn Minuten über einen Zeitraum von einer Stunde durchgeführt. Die Zahlen stellen den Prozentsatz der CPU verwendeten verfügbaren Ressourcen dar, basierend auf den CPU Ressourcen, die bei der Einstellung für die maximale Kapazität für die DB-Instance verfügbar sind.

aws cloudwatch get-metric-statistics --metric-name "CPUUtilization" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

Im folgenden Linux-Beispiel werden ähnliche Messungen wie die vorherigen ausgeführt. In diesem Fall gelten die Messungen für die FreeableMemory-Metrik Die Messungen werden alle zehn Minuten über einen Zeitraum von einer Stunde durchgeführt.

aws cloudwatch get-metric-statistics --metric-name "FreeableMemory" \
  --start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 600 \
  --namespace "AWS/RDS" --statistics Minimum Maximum Average \
  --dimensions Name=DBInstanceIdentifier,Value=my_instance \
  --query 'sort_by(Datapoints[*].{min:Minimum,max:Maximum,avg:Average,ts:Timestamp},&ts)' --output table

Überwachen Aurora Serverless v2 Leistung mit Performance Insights

Sie können Performance Insights verwenden, um die Leistung von zu überwachen Aurora Serverless v2 DB-Instances. Informationen zu Performance-Insights-Verfahren finden Sie unter Überwachen der Datenbanklast mit Performance Insights auf Amazon Aurora.

Die folgenden neuen Performance Insights Insights-Zähler gelten für Aurora Serverless v2 DB-Instances:

Eine vollständige Liste der Performance-Insights-Zähler finden Sie unter Performance-Insights-Zählermetriken.

Wenn vCPU Werte für ein angezeigt werden Aurora Serverless v2 DB-Instance In Performance Insights stellen diese Werte Schätzungen dar, die auf dem ACU Wert für die DB-Instance basieren. Im Standardintervall von einer Minute werden alle gebrochenen CPU V-Werte auf die nächste ganze Zahl aufgerundet. Bei längeren Intervallen ist der angezeigte CPU V-Wert der Durchschnitt der ganzzahligen CPU V-Werte für jede Minute.

Fehlerbehebung Aurora Serverless v2 Kapazitätsprobleme

In einigen Fällen Aurora Serverless v2 wird nicht auf die Mindestkapazität herunterskaliert, auch wenn die Datenbank nicht belastet wird. Dies kann aus einem der folgenden Gründe geschehen:

Wenn die Datenbank immer noch nicht auf die konfigurierte Mindestkapazität herunterskaliert wird, beenden Sie die Datenbank und starten Sie sie neu, um alle Speicherfragmente zurückzugewinnen, die sich im Laufe der Zeit angesammelt haben könnten. Das Stoppen und Starten einer Datenbank führt zu Ausfallzeiten, daher empfehlen wir, achtsam vorzugehen.