Prestazioni e dimensionamento per Aurora Serverless v2

Le seguenti procedure ed esempi mostrano come impostare l'intervallo di capacità per i cluster Aurora Serverless v2 e le istanze database associate. È inoltre possibile utilizzare le procedure seguenti per monitorare il livello di utilizzo delle istanze database. Sarà quindi possibile utilizzare i risultati per determinare se è necessario aumentare o ridurre l'intervallo di capacità.

Prima di utilizzare queste procedure, assicurati di conoscere bene il funzionamento del dimensionamento in Aurora Serverless v2. Il funzionamento del dimensionamento è diverso da quello in Aurora Serverless v1. Per informazioni dettagliate, vedi Dimensionamento di Aurora Serverless v2.

Indice

• Scelta dell'intervallo di capacità di Aurora Serverless v2 per un cluster Aurora
  • Scelta dell'impostazione Aurora Serverless v2 minima della capacità per un cluster
  • Scelta dell'impostazione Aurora Serverless v2 massima della capacità per un cluster
  • Esempio: modificare l'intervallo di capacità Aurora Serverless v2 di un cluster Aurora MySQL
  • Esempio: modificare l'Intervallo di capacità Aurora Serverless v2 di un cluster Aurora PostgreSQL
• Uso di gruppi di parametri per Aurora Serverless v2
  • Valori di parametro predefiniti
  • Numero massimo connessioni per Aurora Serverless v2
  • Parametri che Aurora adegua in caso di riduzione verticale e dimensionamento verso l'alto di Aurora Serverless v2
  • Parametri calcolati da Aurora in base alla capacità massima di Aurora Serverless v2
• Evitare gli errori out-of-memory
• CloudWatch Parametri Amazon importanti per Aurora Serverless v2
  • In che modo le Aurora Serverless v2 metriche si applicano alla fattura AWS
  • Esempi di CloudWatch comandi per Aurora Serverless v2 le metriche
• Monitoraggio delle prestazioni di Aurora Serverless v2 con Approfondimenti sulle prestazioni
• Risoluzione dei problemi di capacità di Aurora Serverless v2

Scelta dell'intervallo di capacità di Aurora Serverless v2 per un cluster Aurora

Con le istanze database Aurora Serverless v2, è possibile impostare l'intervallo di capacità applicabile a tutte le istanze database nel cluster di database mentre aggiungi la prima Istanza database Aurora Serverless v2 al cluster di database. Per eseguire questa procedura, consulta Impostazione dell'intervallo di capacità di Aurora Serverless v2 per un cluster.

È inoltre possibile modificare l'intervallo di capacità per un cluster esistente. Nelle sezioni seguenti viene descritto più dettagliatamente come scegliere i valori minimi e massimi appropriati e cosa succede quando si modifica l'intervallo di capacità. Ad esempio, la modifica dell'intervallo di capacità può modificare i valori di default di alcuni parametri di configurazione. L'applicazione di tutte le modifiche ai parametri può richiedere il riavvio di ciascuna istanza database Aurora Serverless v2.

Argomenti

• Scelta dell'impostazione Aurora Serverless v2 minima della capacità per un cluster
• Scelta dell'impostazione Aurora Serverless v2 massima della capacità per un cluster
• Esempio: modificare l'intervallo di capacità Aurora Serverless v2 di un cluster Aurora MySQL
• Esempio: modificare l'Intervallo di capacità Aurora Serverless v2 di un cluster Aurora PostgreSQL

Scelta dell'impostazione Aurora Serverless v2 minima della capacità per un cluster

Si potrebbe essere portati a scegliere sempre 0,5 come impostazione minima della capacità per Aurora Serverless v2. Questo valore consente infatti la riduzione verticale massima dell'istanza database quando è completamente inattiva. Tuttavia, a seconda di come si utilizza il cluster e delle altre impostazioni configurate, un valore diverso potrebbe essere il più efficace. Considera i seguenti fattori nella scelta dell'impostazione della capacità minima:

• La velocità di dimensionamento per un'istanza database Aurora Serverless v2 dipende dalla sua capacità attuale. Maggiore è la capacità attuale, più veloce sarà il relativo dimensionamento verso l'alto. Se è necessario disporre di un rapido dimensionamento verso l'alto in modo che l'istanza database raggiunga capacità molto elevate, è consigliabile impostare la capacità minima su un valore in cui la velocità di dimensionamento soddisfi le esigenze specifiche.

• Se in genere si modifica la classe delle istanze database in previsione di un carico di lavoro particolarmente elevato o ridotto, è possibile utilizzare tale esperienza per calcolare una stima approssimativa dell'equivalente intervallo di capacità per Aurora Serverless v2. Per determinare la dimensione della memoria da utilizzare in periodi di traffico ridotto, consulta Specifiche hardware per le classi di istanza database per Aurora.

  Ad esempio, supponiamo di utilizzare la classe di istanza database db.r6g.xlarge quando il cluster ha un carico di lavoro ridotto. Questa classe di istanza database dispone di 32 GiB di memoria. Pertanto, è possibile specificare un'impostazione minima dell'unità di capacità Aurora (ACU) pari a 16 per impostare un'istanza database Aurora Serverless v2 in grado di supportare un dimensionamento verticale avente all'incirca la stessa capacità. Questo perché ogni ACU corrisponde a circa 2 GiB di memoria. È possibile specificare un valore leggermente inferiore per consentire all'istanza database un'ulteriore riduzione verticale in caso di sottoutilizzo dell'istanza databse db.r6g.xlarge.

• Se l'applicazione funziona in modo più efficiente quando le istanze database contengono una certa quantità di dati nella cache del buffer, valuta la possibilità di specificare un'impostazione ACU minima in cui la memoria è sufficientemente grande da contenere i dati a cui si accede più di frequente. In caso contrario, alcuni dati vengono cancellati dalla cache del buffer quando le istanze database Aurora Serverless v2 vengono ridotte verticalmente a una dimensione di memoria inferiore. Quando le istanze database vengono successivamente dimensionate verso l'alto, le informazioni vengono lette nuovamente nella cache del buffer. Se la quantità di I/O per riportare i dati nella cache del buffer è rilevante, potrebbe essere più efficace scegliere un valore ACU minimo più alto.

• Se per la maggior parte del tempo le istanze database Aurora Serverless v2 vengono eseguite a una determinata capacità, valuta la possibilità di specificare un'impostazione di capacità minima inferiore, ma non di molto, a quella di base. Le istanze database Aurora Serverless v2 possono calcolare in modo più efficace una stima della quantità e velocità del dimensionamento verso l'alto (aumento) quando la capacità corrente non è sensibilmente inferiore alla capacità richiesta.

• Se il carico di lavoro con provisioning ha requisiti di memoria troppo elevati per classi di istanze database di piccole dimensioni come T3 o T4g, scegli un'impostazione ACU minima che fornisca memoria paragonabile a un'istanza database R5 o R6g.

  In particolare, raccomandiamo la seguente capacità minima per l'utilizzo con le caratteristiche specificate (queste raccomandazioni sono soggette a modifiche):

  • Approfondimenti sulle prestazioni: 2 ACU

  • Database globali Aurora: 8 ACU (si applica solo alla Regione AWS principale)

• In alcuni casi, il cluster potrebbe contenere istanze database Aurora Serverless v2 di lettura il cui dimensionamento è indipendente dalle istanze di scrittura. In questo caso, scegli un'impostazione di capacità minima sufficientemente elevata che quando l'istanza database di scrittura è occupata con un carico di lavoro a uso intensivo di scrittura, le istanze database del lettura possono applicare le modifiche dall'istanza di scrittura senza ritardi. Se rilevi un ritardo di replica nelle istanze di lettura che si trovano nei livelli di promozione 2—15, è consigliabile aumentare l'impostazione della capacità minima per il cluster. Per informazioni dettagliate in merito alla decisione se le istanze database di lettura vengono dimensionate assieme alle istanze di scrittura oppure in modo indipendente, consulta Scelta del livello di promozione per un'istanza Aurora Serverless v2 di lettura.

• Se disponi di un cluster DB con istanze DB Aurora Serverless v2 reader, i lettori non scalano insieme all'istanza DB writer quando il livello di promozione dei lettori non è 0 o 1. In tal caso, l'impostazione di una capacità minima ridotta può comportare un eccessivo ritardo nella replica. Ciò è dovuto al fatto che le istanze di lettura potrebbero non avere capacità sufficiente per applicare le modifiche dell'istanza di scrittura quando il database è occupato. Ti consigliamo di impostare la capacità minima su un valore che rappresenti una quantità di memoria e CPU paragonabile a quella dell'istanza Writer DB.

• Il valore del parametro max_connections per le istanze database Aurora Serverless v2 si basa sulla dimensione della memoria derivata dal numero massimo di ACU. Se specifichi una capacità minima di 0,5 ACU per le istanze database compatibili con PostgreSQL, il valore massimo di max_connections è limitato a 2000.

  Se vuoi utilizzare il cluster Aurora PostgreSQL per un carico di lavoro con un numero elevato di connessioni, è consigliabile utilizzare un'impostazione ACU minima pari a 1 o superiore. Per informazioni dettagliate su come Aurora Serverless v2 gestisce il parametro di configurazione max_connections, consulta Numero massimo connessioni per Aurora Serverless v2.

• Il tempo necessario a un'istanza database Aurora Serverless v2 per il dimensionamento dalla capacità minima alla capacità massima dipende dalla differenza tra i valori ACU minimi e massimi. Quando la capacità corrente dell'istanza database è elevata, il dimensionamento verso l'alto di Aurora Serverless v2 avviene con incrementi più grandi rispetto a quando l'istanza database inizia da una capacità ridotta. Pertanto, se specifichi una capacità massima relativamente grande e l'istanza database rimane per la maggior parte del tempo vicino a tale capacità, è consigliabile aumentare l'impostazione ACU minima. In questo modo, un'istanza database inattiva può usufruire del dimensionamento verso l'alto e raggiungere più rapidamente la capacità massima.

Scelta dell'impostazione Aurora Serverless v2 massima della capacità per un cluster

Si potrebbe essere tentati di scegliere sempre un valore elevato per l'impostazione della capacità Aurora Serverless v2 massima. Un valore elevato per la capacità massima consente all'istanza database un dimensionamento massimo verso l'alto quando è in esecuzione un carico di lavoro con un uso intensivo di risorse. Un valore basso evita il rischio di dover sostenere di addebiti imprevisti. A seconda di come si utilizza il cluster e delle altre impostazioni configurate, il valore più efficace potrebbe essere maggiore o minore basso rispetto a quello originariamente individuato. Considera i seguenti fattori nella scelta dell'impostazione della capacità massima:

• La capacità massima deve essere almeno pari alla capacità minima. Puoi impostare lo stesso valore per la capacità minima e la capacità massima. Tuttavia, in questo caso la capacità non aumenta né diminuisce mai. Pertanto, a parte gli scenari di test, l'uso di valori identici per la capacità minima e massima non è appropriato.

• La capacità massima deve essere maggiore di 0,5 ACU. Nella maggior parte dei casi è possibile impostare la capacità minima e massima su un valore identico. Tuttavia, non è possibile specificare 0,5 sia per la capacità minima che per la la capacità massima. Utilizza un valore pari o superiore a 1 per la capacità massima.

• Se in genere modifichi la classe delle istanze database in previsione di un carico di lavoro particolarmente elevato o ridotto, è possibile utilizzare tale esperienza per calcolare la stima dell'equivalente intervallo di capacità Aurora Serverless v2. Per determinare la dimensione della memoria da utilizzare in periodi di traffico elevato, consulta Specifiche hardware per le classi di istanza database per Aurora.

  Ad esempio, supponiamo di utilizzare la classe di istanza database db.r6g.4xlarge quando il cluster ha un carico di lavoro elevato. Questa classe di istanza database dispone di 128 GiB di memoria. Pertanto, è possibile specificare un'impostazione ACU massima di 64 per impostare un'istanza database Aurora Serverless v2 in grado di eseguire un dimensionamento verso l'alto fino a circa la stessa capacità. Questo perché ogni ACU corrisponde a circa 2 GiB di memoria. È possibile specificare un valore leggermente più alto per consentire all'istanza database un ulteriore dimensionamento verso l'alto nel caso in cui l'istanza database db.r6g.4xlarge a volte non abbia capacità sufficiente per gestire efficacemente il carico di lavoro.

• Se hai un limite di budget per l'utilizzo del database, scegli un valore compreso in tale limite anche se tutte le istanze database Aurora Serverless v2 vengono eseguite sempre alla capacità massima. Ricorda che quando hain istanze database Aurora Serverless v2 nel cluster, la capacità Aurora Serverless v2 massima teorica che il cluster può consumare in qualsiasi momento è nvolte l'impostazione ACU massima per il cluster. La quantità effettiva consumata potrebbe essere inferiore, ad esempio se alcune istanze di lettura vengono dimensionate in modo indipendente rispetto all'istanza di scrittura.

• Se si utilizzano istanze database Aurora Serverless v2 di lettura per alleggerire parte del carico di lavoro di sola lettura dell'istanza database di scrittura, è possibile scegliere un'impostazione di capacità massima inferiore. Si procede in questo senso se il dimensionamento di ogni istanza database di lettura non deve raggiungere un valore così alto, come se il cluster contenga solo un'unica istanza database.

• Supponiamo di voler evitare un uso eccessivo a causa di parametri del database configurati in modo errato o di query inefficienti nell'applicazione. In tal caso, è possibile evitare un uso eccessivo accidentale scegliendo un'impostazione di capacità massima inferiore a quella più alta possibile.

• Se i picchi dovuti alla reale attività degli utenti sono rari ma si verificano, è possibile tenerne conto quando si sceglie l'impostazione della capacità massima. Se è prioritario che l'applicazione continui a funzionare con prestazioni e scalabilità complete, è possibile specificare un'impostazione di capacità massima superiore a quella osservata durante il normale utilizzo. Se l'applicazione può essere eseguita con una capacità di throughput effettiva ridotta durante picchi di attività molto estremi, è possibile scegliere un'impostazione di capacità massima leggermente inferiore. Assicurati di scegliere un'impostazione che disponga ancora di memoria e risorse CPU sufficienti per mantenere l'applicazione in esecuzione.

• Se attivi impostazioni nel cluster che aumentano l'utilizzo della memoria per ogni istanza database, considera tale capacità di memoria quando decidi il valore ACU massimo. Tali impostazioni includono quelle per Approfondimenti sulle prestazioni, le query parallele Aurora MySQL, lo schema di prestazioni Aurora MySQL e la replica del registro binario Aurora MySQL. Assicurati che il valore ACU massimo consenta un dimensionamento verso l'alto delle istanze di database Aurora Serverless v2 tale da gestire il carico di lavoro quando vengono utilizzate queste funzionalità. Per informazioni sulla risoluzione dei problemi causati dalla combinazione di un'impostazione ACU massima bassa e le funzionalità Aurora che impongono il sovraccarico della memoria, consulta Evitare gli errori out-of-memory .

Esempio: modificare l'intervallo di capacità Aurora Serverless v2 di un cluster Aurora MySQL

L' AWS CLI esempio seguente mostra come aggiornare l'intervallo ACU per le istanze Aurora Serverless v2 DB in un cluster Aurora MySQL esistente. Inizialmente, l'intervallo di capacità per il cluster è compreso tra 8 e 32 ACU.

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

L'istanza database è inattiva e ridotta fino a 8 ACU. A questo punto, le seguenti impostazioni relative alla capacità si applicano all'istanza database. Per rappresentare la dimensione del pool di buffer in unità facilmente leggibili, si divide questo valore per 2 elevato alla 30, ottenendo in questo modo una misurazione in gibibyte (GiB). Ciò è dovuto al fatto che le misurazioni relative alla memoria per Aurora utilizzano unità basate su potenze di 2, non potenze di 10.

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)

Successivamente, si modifica l'intervallo di capacità per il cluster. Al termine dell'esecuzione del comando modify-db-cluster, l'intervallo ACU per il cluster è 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
}

La modifica dell'intervallo di capacità ha causato modifiche ai valori di default di alcuni parametri di configurazione. Aurora può applicare immediatamente alcuni di questi nuovi valori di default. Tuttavia, alcune modifiche ai parametri hanno effetto solo dopo il riavvio. Lo stato pending-reboot indica che è necessario un riavvio per applicare alcune modifiche ai parametri.

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"
        }
    ]
}

A questo punto, il cluster è inattivo e l'istanza database serverless-v2-instance-1 sta consumando 12,5 ACU. Il parametro innodb_buffer_pool_size è già modificato in base alla capacità corrente dell'istanza database. Il parametro max_connections riflette ancora il valore della capacità massima precedente. La reimpostazione di questo valore richiede il riavvio dell'istanza database.

Nota

Se si imposta il max_connections parametro direttamente in un gruppo di parametri DB personalizzato, non è necessario il riavvio.

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)

L'istanza viene riavviata e si attende che torni di nuovo disponibile.

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

Lo stato pending-reboot viene cancellato. Il valore in-sync conferma che Aurora ha applicato tutte le modifiche dei parametri in sospeso.

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"
        }
    ]
}

Il parametro innodb_buffer_pool_size è aumentato fino alla sua dimensione finale per un'istanza database inattiva. Il parametro max_connections è aumentato in base a un valore derivato dal valore ACU massimo. La formula usata da Aurora per max_connections comporta un aumento di 1.000 quando la dimensione della memoria raddoppia.

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)

Impostiamo l'intervallo di capacità su 0,5-128 ACU e riavviamo l'istanza DB. A questo punto, l'istanza database inattiva ha una dimensione della cache del buffer inferiore a 1 GiB, quindi la misurazione viene eseguita in mebibyte (MiB). Il valore di 5000 del parametro max_connections è derivato dalla dimensione della memoria dell'impostazione di capacità massima.

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)

Esempio: modificare l'Intervallo di capacità Aurora Serverless v2 di un cluster Aurora PostgreSQL

L'esempio per l'interfaccia della linea di comando seguente illustra come aggiornare l'intervallo ACU per le istanze database Aurora Serverless v2 in un cluster Aurora PostgreSQL esistente.

1. L'intervallo di capacità del cluster iniziale è compreso tra 0,5 e 1 ACU.

2. Cambia l'intervallo di capacità compreso tra 8 e 32 ACU.

3. Cambia l'intervallo di capacità compreso tra 12,5 e 80 ACU.

4. Cambia l'intervallo di capacità compreso tra 0,5 e 128 ACU.

5. Riporta la capacità all'intervallo iniziale compreso tra 0,5 e 1 ACU.

La figura seguente mostra le variazioni di capacità in Amazon CloudWatch.

L'istanza database è inattiva e ridotta fino a 0,5 ACU. A questo punto, le seguenti impostazioni relative alla capacità si applicano all'istanza database.

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

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

Successivamente, si modifica l'intervallo di capacità per il cluster. Al termine dell'esecuzione del comando modify-db-cluster, l'intervallo ACU per il cluster è 8.0-32.

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

La modifica dell'intervallo di capacità comporta modifiche ai valori di default di alcuni parametri di configurazione. Aurora può applicare immediatamente alcuni di questi nuovi valori di default. Tuttavia, alcune modifiche ai parametri hanno effetto solo dopo il riavvio. Lo stato pending-reboot indica che è necessario un riavvio per applicare le modifiche ad alcuni parametri.

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"
        }
    ]
}

A questo punto, il cluster è inattivo e l'istanza database serverless-v2-instance-1 sta consumando 8,0 ACU. Il parametro shared_buffers è già modificato in base alla capacità corrente dell'istanza database. Il parametro max_connections riflette ancora il valore della capacità massima precedente. La reimpostazione di questo valore richiede il riavvio dell'istanza database.

Nota

Se si imposta il max_connections parametro direttamente in un gruppo di parametri DB personalizzato, non è necessario il riavvio.

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

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

L'istanza database viene riavviata e si attende che torni di nuovo disponibile.

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

Dopo il riavvio dell'istanza, lo stato pending-reboot è cancellato. Il valore in-sync conferma che Aurora ha applicato tutte le modifiche dei parametri in sospeso.

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"
        }
    ]
}

Dopo il riavvio, max_connections mostra il valore della nuova capacità massima.

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

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

Successivamente, si imposta l'intervallo di capacità per il cluster compreso tra 12,5 e 80 ACU.

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
}

A questo punto, il cluster è inattivo e l'istanza database serverless-v2-instance-1 sta consumando 12,5 ACU. Il parametro shared_buffers è già modificato in base alla capacità corrente dell'istanza database. Il valore max_connections è ancora 5000.

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

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

Si esegue nuovamente il riavvio, ma i valori del parametro rimangono invariati. Questo perché max_connections ha un valore massimo di 5000 per un cluster di database Aurora Serverless v2 che esegue Aurora PostgreSQL.

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

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

Ora impostiamo l'intervallo di capacità compreso tra 0,5 e 128 ACU. Il cluster di database viene ridotto a 10 ACU e quindi a 2. Riavviamo l'istanza database.

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

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

Il valore di max_connections per le istanze database Aurora Serverless v2 si basa sulla dimensione della memoria derivata dal numero massimo di ACU. Se specifichi una capacità minima di 0,5 ACU per le istanze database compatibili con PostgreSQL, il valore massimo di max_connections è limitato a 2000.

Ora riportiamo la capacità all'intervallo iniziale compreso tra 0,5 e 1 ACU e riavviamo l'istanza database. Il parametro max_connections è tornato al suo valore originale.

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

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

Uso di gruppi di parametri per Aurora Serverless v2

Quando crei il tuo cluster di database Aurora Serverless v2, è possibile scegliere un motore del database Aurora specifico e un gruppo di parametri del cluster di database associato. Se non si ha familiarità con il modo in cui Aurora utilizza i gruppi di parametri per applicare le impostazioni di configurazione in modo coerente tra cluster, consulta Utilizzo di gruppi di parametri. Tutte queste procedure per la creazione, la modifica, l'applicazione e altre azioni per i gruppi di parametri sono valide per Aurora Serverless v2.

La funzione del gruppo di parametri funziona in genere allo stesso modo tra cluster con provisioning e cluster contenenti istanze database Aurora Serverless v2:

• Il gruppo di parametri del cluster di database include anche i valori di default per tutti i parametri a livello di istanza.

• È possibile sovrascrivere alcuni parametri per istanze database specifiche specificando un gruppo personalizzato di parametri del database per tali istanze database. È possibile eseguire questa operazione durante il debug o l'ottimizzazione delle prestazioni per istanze database specifiche. Ad esempio, supponiamo di avere un cluster contenente alcune istanze database Aurora Serverless v2 e alcune istanze database con provisioning. In questo caso, è possibile specificare alcuni parametri diversi per le istanze database con provisioning utilizzando un gruppo personalizzato di parametri del database.

• Per Aurora Serverless v2, è possibile utilizzare tutti i parametri con il valore provisioned nell'attributo SupportedEngineModes nel gruppo di parametri. In Aurora Serverless v1, è possibile utilizzare solo il sottoinsieme di parametri con serverless nellì'attributo SupportedEngineModes.

Argomenti

• Valori di parametro predefiniti
• Numero massimo connessioni per Aurora Serverless v2
• Parametri che Aurora adegua in caso di riduzione verticale e dimensionamento verso l'alto di Aurora Serverless v2
• Parametri calcolati da Aurora in base alla capacità massima di Aurora Serverless v2

Valori di parametro predefiniti

La sostanziale differenza tra le istanze database con provisioning e le istanze database Aurora Serverless v2 risiede nel fatto che Aurora sovrascrive tutti i valori dei parametri personalizzati per determinati parametri correlati alla capacità dell'istanza database. I valori dei parametri personalizzati si applicano ancora a tutte le istanze database con provisioning nel cluster. Per ulteriori informazioni su come le istanze database Aurora Serverless v2 interpretano i parametri dei gruppi di parametri Aurora, consulta Parametri di configurazione per i cluster Aurora. Per i parametri specifici sostituiti da Aurora Serverless v2, consulta Parametri che Aurora adegua in caso di riduzione verticale e dimensionamento verso l'alto di Aurora Serverless v2 e Parametri calcolati da Aurora in base alla capacità massima di Aurora Serverless v2.

È possibile ottenere un elenco di valori predefiniti per i gruppi di parametri predefiniti per i vari motori Aurora DB utilizzando il comando describe-db-cluster-parametersCLI e interrogando il. Regione AWS Di seguito sono riportati i valori che è possibile utilizzare per le opzioni --db-parameter-group-family e -db-parameter-group-name per le versioni del motore compatibili con Aurora Serverless v2.

Motore del database e versione	Famiglia di gruppi di parametri	Nome del gruppo di parametri di default
Aurora MySQL versione 3	aurora-mysql8.0	default.aurora-mysql8.0
Aurora PostgreSQL versione 13.x	aurora-postgresql13	default.aurora-postgresql13
Aurora PostgreSQL versione 14.x	aurora-postgresql14	default.aurora-postgresql14
Aurora PostgreSQL versione 15.x	aurora-postgresql15	default.aurora-postgresql15
Aurora PostgreSQL versione 16.x	aurora-postgresql16	default.aurora-postgresql16

Nell'esempio seguente viene recuperato un elenco di parametri dal gruppo di cluster di database di default per Aurora MySQL versione 3 e Aurora PostgreSQL 13. Queste sono le versioni di Aurora MySQL e Aurora PostgreSQL usate con Aurora Serverless v2.

Per, o: Linux macOS 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

Per 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

Numero massimo connessioni per Aurora Serverless v2

Per Aurora MySQL e Aurora PostgreSQL, le istanze database Aurora Serverless v2 contengono la costante del parametro max_connections in modo che le connessioni non vengano interrotte in caso di riduzione verticale dell'istanza database. Il valore predefinito per questo parametro è derivato da una formula che si basa sulle dimensioni della memoria dell'istanza database. Per informazioni dettagliate sulla formula e sui valori di default per le classi di istanza database con provisioning, consulta Numero massimo di connessioni a un'istanza database Aurora MySQL e Numero massimo di connessioni a un'istanza database Aurora PostgreSQL.

Quando valuta la formula, Aurora Serverless v2 utilizza la dimensione della memoria in base alle unità di capacità Aurora (ACU) massime per l'istanza database e non il valore ACU corrente. Se modifichi il valore di default, si consiglia di utilizzare una variante della formula anziché specificare un valore costante. In questo modo, Aurora Serverless v2 può utilizzare un'impostazione adeguata in base alla capacità massima.

Quando si modifica la capacità massima di un cluster di database Aurora Serverless v2, è necessario riavviare le istanze database Aurora Serverless v2 per aggiornare il valore max_connections. Questo perché max_connections è un parametro statico per Aurora Serverless v2.

La tabella seguente mostra i valori predefiniti di max_connections per Aurora Serverless v2 in base al valore ACU massimo.

Numero massimo di ACU	Numero massimo di connessioni predefinito in Aurora MySQL	Numero massimo di connessioni predefinito in Aurora PostgreSQL
1	90	189
4	135	823
8	1.000	1.669
16	2.000	3.360
32	3.000	5.000
64	4.000	5.000
128	5.000	5.000

Nota

Il valore di max_connections per le istanze database Aurora Serverless v2 si basa sulla dimensione della memoria derivata dal numero massimo di ACU. Se specifichi una capacità minima di 0,5 ACU per le istanze database compatibili con PostgreSQL, il valore massimo di max_connections è limitato a 2000.

Per esempi specifici che mostrano come max_connections cambia con il valore ACU massimo, consulta Esempio: modificare l'intervallo di capacità Aurora Serverless v2 di un cluster Aurora MySQL e Esempio: modificare l'Intervallo di capacità Aurora Serverless v2 di un cluster Aurora PostgreSQL.

Parametri che Aurora adegua in caso di riduzione verticale e dimensionamento verso l'alto di Aurora Serverless v2

Quando viene eseguita la scalabilità automatica, Aurora Serverless v2 deve essere in grado di modificare i parametri affinché ciascuna istanza database funzioni in modo ottimale in base all'incremento o al decremento della capacità. Pertanto, non è possibile sovrascrivere alcuni parametri relativi alla capacità. Per alcuni parametri che è possibile sovrascrivere, evita di codificare valori fissi. Le seguenti considerazioni si applicano a queste impostazioni relative alla capacità.

Per Aurora MySQL, Aurora Serverless v2 esegue il dimensionamento dinamico di alcuni parametri durante il dimensionamento. Per i seguenti parametri, Aurora Serverless v2 non utilizza i valori di parametro personalizzati specificati:

• innodb_buffer_pool_size

• innodb_purge_threads

• table_definition_cache

• table_open_cache

Per Aurora PostgreSQL, Aurora Serverless v2 esegue il dimensionamento dinamico del seguente parametro durante il dimensionamento. Per i seguenti parametri, Aurora Serverless v2 non utilizza i valori di parametro personalizzati specificati:

• shared_buffers

Per tutti i parametri diversi da quelli elencati qui, le istanze database Aurora Serverless v2 hanno lo stesso funzionamento delle istanze database con provisioning. Il valore di default del parametro viene ereditato dal gruppo di parametri del cluster. È possibile modificare il valore di default per l'intero cluster utilizzando un gruppo di parametri personalizzato per il cluster. In alternativa, è possibile modificare il valore di default per alcune istanze database utilizzando un gruppo di parametri personalizzato per il database. I parametri dinamici vengono aggiornati immediatamente. Le modifiche apportate ai parametri statici hanno effetto solo dopo il riavvio dell'istanza database.

Parametri calcolati da Aurora in base alla capacità massima di Aurora Serverless v2

Per i seguenti parametri, Aurora PostgreSQL utilizza i valori predefiniti derivati dalle dimensioni della memoria in base all'impostazione ACU massima, in modo analogo a quanto avviene con max_connections:

• autovacuum_max_workers

• autovacuum_vacuum_cost_limit

• autovacuum_work_mem

• effective_cache_size

• maintenance_work_mem

Evitare gli errori out-of-memory

Se una delle istanze database Aurora Serverless v2 raggiunge costantemente il limite della capacità massima, Aurora indica questa condizione impostando l'istanza datanase sullo stato incompatible-parameters. Se lo stato dell'istanza database è incompatible-parameters, alcune operazioni sono bloccate. Ad esempio, non è possibile aggiornare la versione del motore.

In genere, l'istanza DB assume questo stato quando si riavvia frequentemente a causa di out-of-memory errori. Aurora registra un evento quando si verifica questo tipo di riavvio. È possibile visualizzare l'evento seguendo la procedura descritta in Visualizzazione di eventi Amazon RDS. Un utilizzo della memoria insolitamente elevato può verificarsi a causa del sovraccarico dovuto all'attivazione di impostazioni come Approfondimenti sulle prestazioni e l'autenticazione IAM. Può anche essere causato da un carico di lavoro rilevante sull'istanza database o dalla gestione dei metadati associati a un gran numero di oggetti dello schema.

Se il sovraccarico sulla memoria diminuisce e pertanto l'istanza database non raggiunge la sua capacità massima molto spesso, Aurora imposta automaticamente lo stato dell'istanza database su available.

Per gestire in modo ottimale questa situazione, è possibile eseguire alcune o tutte le seguenti azioni:

• Aumentare il limite inferiore della capacità per le istanze database Aurora Serverless v2 modificando il valore minimo dell'unità di capacità Aurora (ACU) per il cluster. In questo modo si evitano i problemi in cui un database inattivo viene ridotto a una capacità di memoria inferiore a quella necessaria per le funzionalità attivate nel cluster. Dopo aver modificato le impostazioni ACU per il cluster, riavviare l'istanza database Aurora Serverless v2. In questo modo Aurora valuta se è in grado di ripristinare lo stato available.

• Aumentare il limite superiore della capacità per le istanze database Aurora Serverless v2 modificando il valore ACU massimo per il cluster. Ciò consente di evitare problemi nel caso in cui un database occupato non sia in grado di eseguire il dimensionamento verso l'alto fino a una capacità con memoria sufficiente per le funzionalità attivate nel cluster e nel carico di lavoro del database. Dopo aver modificato le impostazioni ACU per il cluster, riavviare l'istanza database Aurora Serverless v2. In questo modo Aurora valuta se è in grado di ripristinare lo stato available.

• Disattivare le impostazioni di configurazione che richiedono un sovraccarico di memoria. Ad esempio, supponiamo di avere funzionalità come AWS Identity and Access Management (IAM), Performance Insights o la replica binaria dei log MySQL di Aurora attivate ma non le utilizzi. In questo caso, è possibile disattivarle. In alternativa, è possibile adeguare i valori di capacità minima e massima per il cluster in modo da considerare la memoria utilizzata da tali funzionalità. Per le linee guida sulla scelta delle impostazioni di capacità minima e massima, consulta Scelta dell'intervallo di capacità di Aurora Serverless v2 per un cluster Aurora.

• Ridurre il carico di lavoro sull'istanza database. Ad esempio, è possibile aggiungere istanze database di lettura al cluster per distribuire il carico dalle query di sola lettura su più istanze database.

• Ottimizzare il codice SQL utilizzato dall'applicazione in modo da usare meno risorse. Ad esempio, è possibile esaminare i piani di query, controllare il registro delle query caratterizzate da un'esecuzione lenta o modificare gli indici nelle tabelle. È inoltre possibile eseguire altri tipi comuni di sintonizzazione SQL.

CloudWatch Parametri Amazon importanti per Aurora Serverless v2

Per iniziare a usare Amazon CloudWatch per la tua istanza Aurora Serverless v2 DB, consultaVisualizzazione dei Aurora Serverless v2 log in Amazon CloudWatch. Per ulteriori informazioni su come monitorare i cluster Aurora DB, consulta CloudWatch. Monitoraggio degli eventi di registro in Amazon CloudWatch

Puoi visualizzare le tue istanze Aurora Serverless v2 DB CloudWatch per monitorare la capacità consumata da ciascuna istanza DB con la metrica. ServerlessDatabaseCapacity Puoi anche monitorare tutte le CloudWatch metriche Aurora standard, come e. DatabaseConnections Queries Per l'elenco completo delle CloudWatch metriche che puoi monitorare per Aurora, consulta. CloudWatch Parametri Amazon per Amazon Aurora I parametri metriche sono suddivise in parametri a livello di cluster e parametri a livello di istanza in Parametri a livello di cluster per Amazon Aurora e Parametri a livello di istanza per Amazon Aurora.

Le seguenti metriche a CloudWatch livello di istanza sono importanti da monitorare per consentirti di capire in che modo le tue istanze Aurora Serverless v2 DB si stanno scalando verso l'alto e verso il basso. Tutti questi parametri vengono calcolati ogni secondo. In questo modo, puoi monitorare lo stato corrente delle istanze database Aurora Serverless v2. È possibile impostare allarmi per avvisarti se i parametri relativi alla capacità di una delle istanze database Aurora Serverless v2 stanno raggiungendo la soglia limite. È possibile determinare se le impostazioni di capacità minima e massima sono appropriate o se è necessario adeguarle. È possibile individuare le aree da valutare con maggiore attenzione per ottimizzare l'efficienza del database.

• ServerlessDatabaseCapacity. Come parametro a livello di istanza, restituisce il numero di ACU rappresentato dalla capacità corrente dell'istanza database. Come parametro a livello di cluster, restituisce la media dei valori di ServerlessDatabaseCapacity di tutte le istanze database Aurora Serverless v2 nel cluster. Questo parametro è un parametro solo a livello di cluster in Aurora Serverless v1. In Aurora Serverless v2, è disponibile a livello di istanza database e a livello di cluster.

• ACUUtilization. Questo parametro è nuovo in Aurora Serverless v2. Questo valore è rappresentato come percentuale. Viene calcolato come il valore del parametro ServerlessDatabaseCapacity diviso per il valore ACU massimo del cluster di database. Considera le seguenti linee guida per l'interpretazione di questo parametro e per valutare quale azione eseguire:

  • Se questo parametro si avvicina al valore 100.0, il dimensionamento verso l'alto dell'istanza database ha raggiunto il valore massimo possibile. Valuta la possibilità di aumentare l'impostazione ACU massima per il cluster. In questo modo, sia le istanze database di scrittura che quelle di lettura possono essere dimensionate in base a una capacità superiore.

  • Supponiamo che un carico di lavoro di sola lettura faccia sì che il valore del parametro ACUUtilization di un'istanza database di lettura si avvicini 100.0, mentre l'istanza database di scrittura non raggiunge la relativa capacità massima. In questo caso, considera di aggiungere istanze database di lettura al cluster. In questo modo, puoi distribuire la parte di sola lettura del carico di lavoro su più istanze database e ridurre conseguentemente il carico su ogni istanza database di lettura.

  • Supponiamo di eseguire un'applicazione di produzione, in cui prestazioni e scalabilità sono fattori di primaria importanza. In questo caso, puoi impostare il valore ACU massimo per il cluster su un numero elevato. Il tuo obiettivo è avere il parametro ACUUtilization su un valore sempre inferiore a 100.0. Con un valore ACU massimo elevato, puoi essere certo di disporre di spazio sufficiente in caso di picchi imprevisti a livello di attività del database. Dovrai sostenere solo i costi relativi al consumo effettivo di capacità del database.

• CPUUtilization. Questo parametro viene interpretato in modo diverso in Aurora Serverless v2 rispetto a quanto avviene per le istanze database con provisioning. Per Aurora Serverless v2, questo valore è una percentuale calcolata come la quantità di CPU attualmente utilizzata divisa per la capacità della CPU disponibile sotto il valore ACU massimo del cluster di database. Aurora monitora automaticamente questo valore e dimensiona verso l'alto l'istanza database Aurora Serverless v2 quando questa utilizza costantemente una percentuale elevata della capacità della CPU.

  Se il valore di questo parametro si avvicina a 100.0, l'istanza database ha raggiunto la capacità massima della CPU. Valuta la possibilità di aumentare l'impostazione ACU massima per il cluster. Se il valore di questo parametro si avvicina a 100.0 per un'istanza database di lettura, valuta la possibilità di aggiungere altre istanze database di lettura al cluster. In questo modo, puoi distribuire la parte di sola lettura del carico di lavoro su più istanze database e ridurre conseguentemente il carico su ogni istanza database di lettura.

• FreeableMemory. Questo valore rappresenta la quantità di memoria inutilizzata disponibile quando viene eseguito il dimensionamento dell'istanza database Aurora Serverless v2 fino alla sua capacità massima. Per ogni ACU la cui capacità corrente è inferiore alla capacità massima, questo valore aumenta di circa 2 GiB. Pertanto, questo parametro non si avvicina a zero finché non viene eseguito il dimensionamento verso l'alto dell'istanza database fino al valore più alto possibile.

  Se il valore di questo parametro si avvicina a 0, viene eseguito il dimensionamento verso l'alto dell'istanza database al valore massimo possibile, ovvero al valore più prossimo al limite di memoria disponibile. Valuta la possibilità di aumentare l'impostazione ACU massima per il cluster. Se il valore di questo parametro si avvicina a 0 per un'istanza database di lettura, valuta la possibilità di aggiungere altre istanze database di lettura al cluster. In questo modo, puoi distribuire la parte di sola lettura del carico di lavoro su più istanze database e ridurre conseguentemente l'utilizzo della memoria su ogni istanza database di lettura.

• TempStorageIops. Il numero di IOPS eseguiti sull'archiviazione locale collegata all'istanza database. Include gli IOPS per le operazioni sia di letture che di scrittura. Questo parametro rappresenta un conteggio e viene misurato una volta al secondo. Questo è un nuovo parametro per Aurora Serverless v2. Per informazioni dettagliate, vedi Parametri a livello di istanza per Amazon Aurora.

• TempStorageThroughput. Quantità di dati trasferiti da e verso l'archiviazione locale associata all'istanza database. Questo parametro rappresenta i byte e viene misurato una volta al secondo. Questo è un nuovo parametro per Aurora Serverless v2. Per informazioni dettagliate, vedi Parametri a livello di istanza per Amazon Aurora.

In genere, la maggior parte del dimensionamento verso l'alto delle istanze database Aurora Serverless v2 è causato dall'utilizzo della memoria e dall'attività della CPU. I parametri TempStorageIops e TempStorageThroughput possono aiutarti a diagnosticare i rari casi in cui l'attività di rete relativa ai trasferimenti tra l'istanza database e i dispositivi di archiviazione locale è responsabile di aumenti imprevisti della capacità. Per monitorare altre attività di rete, puoi utilizzare i seguenti parametri:

• NetworkReceiveThroughput

• NetworkThroughput

• NetworkTransmitThroughput

• StorageNetworkReceiveThroughput

• StorageNetworkThroughput

• StorageNetworkTransmitThroughput

È possibile fare in modo che Aurora pubblichi alcuni o tutti i log del database su. CloudWatch Puoi selezionare i registri da pubblicare attivando i parametri di configurazione, ad esempio general_log e slow_query_log, nel gruppo di parametri del cluster di database associato al cluster contenente le istanze database Aurora Serverless v2. Quando disattivate un parametro di configurazione del registro, la pubblicazione di quel registro su si interrompe. CloudWatch Puoi anche eliminare i log in CloudWatch se non sono più necessari.

In che modo le Aurora Serverless v2 metriche si applicano alla fattura AWS

Gli Aurora Serverless v2 addebiti sulla AWS fattura vengono calcolati in base alla stessa ServerlessDatabaseCapacity metrica che puoi monitorare. Il meccanismo di fatturazione può differire dalla CloudWatch media calcolata per questa metrica nei casi in cui si utilizza la Aurora Serverless v2 capacità solo per una parte dell'ora. Può anche differire se i problemi di sistema rendono la CloudWatch metrica non disponibile per brevi periodi. Pertanto, sulla fattura potresti vedere un valore di ore ACU leggermente diverso rispetto al calcolo fatto sulla base del valore medio del parametro ServerlessDatabaseCapacity.

Esempi di CloudWatch comandi per Aurora Serverless v2 le metriche

AWS CLI Gli esempi seguenti mostrano come monitorare le CloudWatch metriche più importanti relative a. Aurora Serverless v2 In ogni caso, sostituire la stringa Value= per il parametro --dimensions con l'identificativo dell'istanza database Aurora Serverless v2 in uso.

Nell'esempio Linux seguente vengono visualizzati i valori di capacità minima, massima e media per un'istanza database, misurati ogni 10 minuti ogni ora. Il comando Linux date specifica l'ora di inizio e l'ora di fine rispetto alla data e all'ora correnti. La funzione sort_by nel parametro --query ordina i risultati cronologicamente in base al campo 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

Gli esempi di Linux riportati di seguito illustrano il monitoraggio della capacità di ogni istanza database in un cluster. Misurano l'utilizzo minimo, massimo e medio della capacità di ciascuna istanza database. Le misurazioni vengono effettuate una volta ogni ora per un periodo di tre ore. Questi esempi utilizzano il parametro ACUUtilization che rappresenta una percentuale del limite superiore delle ACU, mentre ServerlessDatabaseCapacity rappresenta un numero fisso di ACU. In questo modo, non è necessario conoscere i numeri effettivi per i valori ACU minimi e massimi nell'intervallo di capacità. Puoi visualizzare percentuali che vanno da 0 a 100.

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

Il seguente esempio Linux esegue misurazioni simili a quelle precedenti. In questo caso, le misure fanno riferimento al parametro CPUUtilization. Le misurazioni vengono effettuate ogni 10 minuti per un periodo di 1 ora. I numeri rappresentano la percentuale di CPU disponibile utilizzata, in base alle risorse della CPU disponibili per l'impostazione di capacità massima per l'istanza database.

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

Il seguente esempio Linux esegue misurazioni simili a quelle precedenti. In questo caso, le misure fanno riferimento al parametro FreeableMemory. Le misurazioni vengono effettuate ogni 10 minuti per un periodo di 1 ora.

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

Monitoraggio delle prestazioni di Aurora Serverless v2 con Approfondimenti sulle prestazioni

Puoi utilizzare Approfondimenti sulle prestazioni per monitorare le prestazioni di istanze database Aurora Serverless v2. Per le procedure di Approfondimenti sulle prestazioni, consulta Monitoraggio del carico DB con Performance Insights su Amazon Aurora.

I seguenti nuovi contatori di Approfondimenti sulle prestazioni si applicano alle istanze database Aurora Serverless v2:

• os.general.serverlessDatabaseCapacity: capacità attuale, in ACU, dell'istanza database. Il valore corrisponde alla ServerlessDatabaseCapacity CloudWatch metrica per l'istanza DB.

• os.general.acuUtilization: percentuale di capacità attuale oltre la capacità massima configurata. Il valore corrisponde alla ACUUtilization CloudWatch metrica per l'istanza DB.

• os.general.maxConfiguredAcu: capacità massima configurata per l'istanza database Aurora Serverless v2 corrente. Viene misurata in ACU.

• os.general.minConfiguredAcu: capacità minima configurata per l'istanza database Aurora Serverless v2 corrente. Viene misurata in ACU

Per l'elenco completo dei contatori di Approfondimenti sulle prestazioni, consulta Parametri contatore di Performance Insights.

Quando in Approfondimenti sulle prestazioni vengono visualizzati i valori vCPU per un'istanza database Aurora Serverless v2, tali valori rappresentano stime basate sul valore ACU per l'istanza database. Per intervalli di default di un minuto, tutti i valori vCPU frazionari vengono arrotondati al numero intero più vicino. Per intervalli più lunghi, il valore vCPU visualizzato è la media dei valori vCPU interi per ogni minuto.

Risoluzione dei problemi di capacità di Aurora Serverless v2

In alcuni casi, Aurora Serverless v2 non viene ridotto fino alla capacità minima, anche in assenza di carico sul database. Questo può accadere per i seguenti motivi:

• Alcune funzionalità possono aumentare l'utilizzo delle risorse e impedire il dimensionamento del database fino alla capacità minima. Le caratteristiche principali comprendono:

  • Database globali di Aurora

  • Esportazione dei log CloudWatch

  • Abilitazione di pg_audit nei cluster database compatibili con Aurora PostgreSQL

  • Enhanced Monitoring

  • Approfondimenti sulle prestazioni

  Per ulteriori informazioni, consulta Scelta dell'impostazione Aurora Serverless v2 minima della capacità per un cluster.

• Se un'istanza di lettura non si riduce fino alla capacità minima e mantiene la capacità uguale o superiore dell'istanza di scrittura, controlla il livello di priorità dell'istanza di scrittura. Le istanze database di lettura Aurora Serverless v2 di livello 0 o 1 vengono mantenute a una capacità minima pari ad almeno quella dell'istanza database di scrittura. Imposta il livello di priorità dell'istanza di lettura almeno su 2 in modo che possa essere aumentata o ridotta indipendentemente dall'istanza di scrittura. Per ulteriori informazioni, consulta Scelta del livello di promozione per un'istanza Aurora Serverless v2 di lettura.

• Imposta i valori predefiniti dei parametri del database che influiscono sulla dimensione della memoria condivisa. L'impostazione di un valore superiore a quello predefinito aumenta la richiesta di memoria condivisa e impedisce la riduzione del database fino alla capacità minima. Alcuni esempi sono max_connections e max_locks_per_transaction.

  Nota

  L'aggiornamento dei parametri della memoria condivisa richiede il riavvio del database per rendere effettive le modifiche.

• I carichi di lavoro di database gravosi possono aumentare l'utilizzo delle risorse.

• I volumi di database di grandi dimensioni possono aumentare l'utilizzo delle risorse.

  Amazon Aurora utilizza risorse di memoria e CPU per la gestione dei cluster database. Aurora richiede più CPU e memoria per gestire cluster database con volumi di database più grandi. Se la capacità minima del cluster è inferiore a quella minima richiesta per la gestione dei cluster, il cluster non verrà ridotto fino alla capacità minima.

• Anche i processi in background, come l'eliminazione, possono aumentare l'utilizzo delle risorse.

Se il database non riesce ancora a ridurre fino la capacità minima configurata, interrompi e riavvia il database per recuperare eventuali frammenti di memoria che potrebbero essersi accumulati nel tempo. L'arresto e l'avvio di un database comportano tempi di inattività, quindi consigliamo di farlo raramente.