Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Gestione delle prestazioni e del dimensionamento dei cluster DB Aurora
Puoi utilizzare le seguenti opzioni per gestire le prestazioni e il dimensionamento dei cluster DB e le istanze database Aurora:
**Topics**
+ [Dimensionamento dello storage](#Aurora.Managing.Performance.StorageScaling)
+ [Dimensionamento delle istanze](#Aurora.Managing.Performance.InstanceScaling)
+ [Dimensionamento della lettura](#Aurora.Managing.Performance.ReadScaling)
+ [Gestione delle connessioni](#Aurora.Managing.MaxConnections)
+ [Gestione dei piani di esecuzione delle query](#Aurora.Managing.Optimizing)
## Dimensionamento dello storage
Lo storage Aurora viene automaticamente dimensionato con i dati del volume dei cluster. Man mano che i dati aumentano, lo spazio di archiviazione del volume dei cluster si espande a seconda della versione del motore di database. Per informazioni sulle dimensioni massime dei volumi dei cluster Aurora per ogni versione del motore, consulta [Limiti di dimensione Amazon Aurora](CHAP_Limits.md#RDS_Limits.FileSize.Aurora). Per informazioni sui tipi di dati inclusi nel volume del cluster, consulta [Archiviazione Amazon Aurora](Aurora.Overview.StorageReliability.md). Per informazioni sulla dimensione massima per una versione specifica, consulta [Limiti di dimensione Amazon Aurora](CHAP_Limits.md#RDS_Limits.FileSize.Aurora).
Le dimensioni del volume del cluster vengono valutate ogni ora, per stabilire i costi di storage. Per informazioni sui prezzi, consulta la [pagina dei prezzi di Aurora](https://aws.amazon.com/rds/aurora/pricing).
Anche se un volume del cluster Aurora può aumentare le dimensioni fino a molti tebibyte, solo lo spazio utilizzato nel volume viene addebitato. Il meccanismo per determinare lo spazio di storage fatturato dipende dalla versione del cluster Aurora.
+ Quando i dati Aurora vengono rimossi dal volume del cluster, lo spazio fatturato complessivo diminuisce di una quantità comparabile. Questo comportamento di ridimensionamento dinamico si verifica quando i tablespace sottostanti vengono eliminati o riorganizzati per richiedere meno spazio. Pertanto, puoi ridurre le spese di archiviazione eliminando le tabelle e i database che non sono più necessari. Il ridimensionamento dinamico si applica a determinate versioni di Aurora. Di seguito sono riportate le versioni di Aurora in cui il volume del cluster viene ridimensionato dinamicamente durante la rimozione dei dati:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html)
+ Nelle versioni di Aurora precedenti a quelle dell’elenco, il volume del cluster può riutilizzare lo spazio liberato dalla rimozione dei dati, ma le dimensioni del volume in sé non diminuiscono mai.
Il ridimensionamento dinamico si applica alle operazioni che rimuovono o ridimensionano fisicamente i tablespace all'interno del volume del cluster. Pertanto, si applica alle istruzioni SQL come `DROP TABLE`, `DROP DATABASE`, `TRUNCATE TABLE` e `ALTER TABLE ... DROP PARTITION`. Non si applica all'eliminazione di righe con l'istruzione `DELETE`. Se elimini un numero elevato di righe da una tabella, puoi eseguire l'istruzione Aurora MySQL `OPTIMIZE TABLE` o utilizzare l'estensione Aurora PostgreSQL `pg_repack` in seguito per riorganizzare la tabella e ridimensionare dinamicamente il volume del cluster.
Per Aurora MySQL, si applicano le seguenti considerazioni:
+ Dopo aver aggiornato il cluster DB a una versione del motore DB che supporta il ridimensionamento dinamico e quando la funzionalità è abilitata in quella specifica Regione AWS, qualsiasi spazio che viene successivamente liberato da determinate istruzioni SQL, ad esempio, è recuperabile. `DROP TABLE`
Se la funzionalità è esplicitamente disabilitata in un determinato caso, lo spazio potrebbe essere riutilizzabile Regione AWS, e non recuperabile, solo nelle versioni che supportano il ridimensionamento dinamico.
La funzionalità è stata abilitata per versioni specifiche del motore di database (da 1.23.0 a 1.23.4, da 2.09.0 a 2.09.3 e 2.10.0) tra novembre 2020 e marzo 2022, ed è abilitata per impostazione predefinita su tutte le versioni successive.
+ Una tabella viene archiviata internamente in uno o più frammenti contigui di varie dimensioni. Durante l’esecuzione delle operazioni `TRUNCATE TABLE`, lo spazio corrispondente al primo frammento è riutilizzabile e non recuperabile. Gli altri frammenti sono recuperabili. Durante le operazioni `DROP TABLE`, lo spazio corrispondente all’intero tablespace è recuperabile.
+ Il parametro `innodb_file_per_table` influisce sul modo in cui è organizzata l’archiviazione della tabella. Quando le tabelle fanno parte del tablespace di sistema, l'eliminazione della tabella non riduce le dimensioni del tablespace di sistema. Pertanto, è necessario accertarsi di impostare `innodb_file_per_table` su 1 per i cluster database Aurora MySQL per sfruttare al massimo il ridimensionamento dinamico.
+ Nelle versioni 2.11 e successive, il tablespace temporaneo InnoDB viene eliminato e creato nuovamente al riavvio. In questo modo lo spazio occupato dal tablespace temporaneo viene rilasciato al sistema e il volume del cluster viene ridimensionato. Per utilizzare al meglio la funzionalità di ridimensionamento dinamico, è consigliabile aggiornare il cluster di database alle versioni 2.11 o successiva.
**Nota**
La funzionalità di ridimensionamento dinamico non recupera immediatamente lo spazio quando le tabelle nei tablespace vengono eliminate, ma esegue tale operazione gradualmente, a un ritmo di circa 10 TB al giorno. Lo spazio del tablespace di sistema non viene recuperato perché il tablespace di sistema non viene mai eliminato. Lo spazio libero non reclamato in uno spazio tabella viene riutilizzato quando un'operazione richiede spazio in tale spazio tabella. La funzionalità di ridimensionamento dinamico può recuperare spazio di archiviazione solo quando il cluster è in uno stato disponibile.
Puoi verificare la quantità di spazio di storage utilizzata da un cluster monitorando il parametro `VolumeBytesUsed` in CloudWatch. Per ulteriori informazioni sulla fatturazione dello storage, consulta [Come viene fatturato lo storage dei dati Aurora](Aurora.Overview.StorageReliability.md#aurora-storage-data-billing).
+ In Console di gestione AWS, puoi vedere questa figura in un grafico visualizzando la scheda nella pagina dei dettagli del cluster. `Monitoring`
+ Con AWS CLI, è possibile eseguire un comando simile al seguente esempio di Linux. Sostituisci i tuoi valori per l'ora di inizio e di fine e il nome del cluster.
```
aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
--start-time "$(date -d '6 hours ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" \
--statistics Average Maximum Minimum \
--dimensions Name=DBClusterIdentifier,Value=my_cluster_identifier
```
Questo comando genera un output simile al seguente.
```
{
"Label": "VolumeBytesUsed",
"Datapoints": [
{
"Timestamp": "2020-08-04T21:25:00+00:00",
"Average": 182871982080.0,
"Minimum": 182871982080.0,
"Maximum": 182871982080.0,
"Unit": "Bytes"
}
]
}
```
Gli esempi seguenti mostrano come è possibile tenere traccia dell'utilizzo dello storage per un cluster Aurora nel tempo utilizzando AWS CLI i comandi su un sistema Linux. I parametri `--start-time` e `--end-time` definiscono l'intervallo di tempo complessivo come un giorno. Il parametro `--period` richiede le misurazioni a intervalli di un'ora. Non ha senso scegliere un valore `--period` piccolo perché i parametri vengono raccolti a intervalli, non in modo continuo. Inoltre, le operazioni di storage Aurora a volte continuano per qualche tempo in background al termine dell'istruzione SQL pertinente.
Il primo esempio restituisce l'output nel formato JSON predefinito. I punti dati vengono restituiti in ordine arbitrario, non in base al timestamp. Puoi importare questi dati JSON in uno strumento di grafici per eseguire l'ordinamento e la visualizzazione.
```
$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
--start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600
--namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id
{
"Label": "VolumeBytesUsed",
"Datapoints": [
{
"Timestamp": "2020-08-04T19:40:00+00:00",
"Maximum": 182872522752.0,
"Unit": "Bytes"
},
{
"Timestamp": "2020-08-05T00:40:00+00:00",
"Maximum": 198573719552.0,
"Unit": "Bytes"
},
{
"Timestamp": "2020-08-05T05:40:00+00:00",
"Maximum": 206827454464.0,
"Unit": "Bytes"
},
{
"Timestamp": "2020-08-04T17:40:00+00:00",
"Maximum": 182872522752.0,
"Unit": "Bytes"
},
... output omitted ...
```
In questo esempio vengono restituiti gli stessi dati del precedente. Il parametro `--output` rappresenta i dati in formato testo normale compatto. Il comando `aws cloudwatch ` invia il suo output al comando `sort`. Il parametro `-k` del comando `sort` ordina l'output in base al terzo campo che è il timestamp in formato UTC (Universal Coordinated Time).
```
$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
--start-time "$(date -d '1 day ago')" --end-time "$(date -d 'now')" --period 3600 \
--namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_cluster_id \
--output text | sort -k 3
VolumeBytesUsed
DATAPOINTS 182872522752.0 2020-08-04T17:41:00+00:00 Bytes
DATAPOINTS 182872522752.0 2020-08-04T18:41:00+00:00 Bytes
DATAPOINTS 182872522752.0 2020-08-04T19:41:00+00:00 Bytes
DATAPOINTS 182872522752.0 2020-08-04T20:41:00+00:00 Bytes
DATAPOINTS 187667791872.0 2020-08-04T21:41:00+00:00 Bytes
DATAPOINTS 190981029888.0 2020-08-04T22:41:00+00:00 Bytes
DATAPOINTS 195587244032.0 2020-08-04T23:41:00+00:00 Bytes
DATAPOINTS 201048915968.0 2020-08-05T00:41:00+00:00 Bytes
DATAPOINTS 205368492032.0 2020-08-05T01:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T02:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T03:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T04:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T05:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T06:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T07:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T08:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T09:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T10:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T11:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T12:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T13:41:00+00:00 Bytes
DATAPOINTS 206827454464.0 2020-08-05T14:41:00+00:00 Bytes
DATAPOINTS 206833664000.0 2020-08-05T15:41:00+00:00 Bytes
DATAPOINTS 206833664000.0 2020-08-05T16:41:00+00:00 Bytes
```
L'output ordinato mostra quanto spazio di storage è stato utilizzato all'inizio e alla fine del periodo di monitoraggio. Puoi inoltre trovare i punti durante quel periodo quando Aurora ha allocato più spazio di storage per il cluster. Nell'esempio seguente vengono utilizzati i comandi Linux per riformattare i valori `VolumeBytesUsed` iniziali e finali come gigabyte (GB) e gibibyte (GiB). I gigabyte rappresentano unità misurate in potenze di 10 e sono comunemente utilizzati nelle discussioni di storage per dischi rigidi rotazionali. I gibibyte rappresentano le unità misurate in potenze di 2. Le misurazioni e i limiti di archiviazione di Aurora sono generalmente indicati nelle unità di potenza di 2, come gibibyte e tebibyte.
```
$ GiB=$((1024*1024*1024))
$ GB=$((1000*1000*1000))
$ echo "Start: $((182872522752/$GiB)) GiB, End: $((206833664000/$GiB)) GiB"
Start: 170 GiB, End: 192 GiB
$ echo "Start: $((182872522752/$GB)) GB, End: $((206833664000/$GB)) GB"
Start: 182 GB, End: 206 GB
```
Il parametro `VolumeBytesUsed` indica la quantità di spazio di storage nel cluster che sta causando costi. Quindi, è meglio ridurre al minimo questo numero quando possibile. Tuttavia, questo parametro non include alcune risorse di storage che Aurora utilizza internamente nel cluster senza addebitare alcun costo. Se il cluster si sta avvicinando al limite di storage e potrebbe esaurire lo spazio, è più utile monitorare il parametro `AuroraVolumeBytesLeftTotal` e cercare di massimizzare tale numero. Nell'esempio seguente viene eseguito un calcolo simile a quello precedente, ma per `AuroraVolumeBytesLeftTotal` invece di `VolumeBytesUsed`.
```
$ aws cloudwatch get-metric-statistics --metric-name "AuroraVolumeBytesLeftTotal" \
--start-time "$(date -d '1 hour ago')" --end-time "$(date -d 'now')" --period 3600 \
--namespace "AWS/RDS" --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=my_old_cluster_id \
--output text | sort -k 3
AuroraVolumeBytesLeftTotal
DATAPOINTS 140530528288768.0 2023-02-23T19:25:00+00:00 Count
$ TiB=$((1024*1024*1024*1024))
$ TB=$((1000*1000*1000*1000))
$ echo "$((69797067915264 / $TB)) TB remaining for this cluster"
69 TB remaining for this cluster
$ echo "$((69797067915264 / $TiB)) TiB remaining for this cluster"
63 TiB remaining for this cluster
```
Per un cluster che esegue Aurora MySQL versione 2.09 o successive oppure Aurora PostgreSQL, la dimensione libera riportata da `VolumeBytesUsed` aumenta quando i dati vengono aggiunti e diminuisce quando i dati vengono rimossi. L’esempio seguente mostra come. Questo report mostra le dimensioni massime e minime di storage per un cluster a intervalli di 15 minuti man mano che vengono create ed eliminate le tabelle con dati temporanei. Il report elenca il valore massimo prima del valore minimo. Pertanto, per capire come l'utilizzo dello storage è cambiato nell'intervallo di 15 minuti, interpreta i numeri da destra a sinistra.
```
$ aws cloudwatch get-metric-statistics --metric-name "VolumeBytesUsed" \
--start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
--namespace "AWS/RDS" --statistics Maximum Minimum --dimensions Name=DBClusterIdentifier,Value=my_new_cluster_id
--output text | sort -k 4
VolumeBytesUsed
DATAPOINTS 14545305600.0 14545305600.0 2020-08-05T20:49:00+00:00 Bytes
DATAPOINTS 14545305600.0 14545305600.0 2020-08-05T21:19:00+00:00 Bytes
DATAPOINTS 22022176768.0 14545305600.0 2020-08-05T21:49:00+00:00 Bytes
DATAPOINTS 22022176768.0 22022176768.0 2020-08-05T22:19:00+00:00 Bytes
DATAPOINTS 22022176768.0 22022176768.0 2020-08-05T22:49:00+00:00 Bytes
DATAPOINTS 22022176768.0 15614263296.0 2020-08-05T23:19:00+00:00 Bytes
DATAPOINTS 15614263296.0 15614263296.0 2020-08-05T23:49:00+00:00 Bytes
DATAPOINTS 15614263296.0 15614263296.0 2020-08-06T00:19:00+00:00 Bytes
```
Nell’esempio seguente viene illustrato come, per un cluster che esegue versioni compatibili di Aurora MySQL o Aurora PostgreSQL, le dimensioni libere riportate da `AuroraVolumeBytesLeftTotal` riflettono il limite massimo di 256 TiB. Per ulteriori informazioni sulle versioni compatibili, consulta [Limiti di dimensione Amazon Aurora](CHAP_Limits.md#RDS_Limits.FileSize.Aurora).
```
$ aws cloudwatch get-metric-statistics --region us-east-1 --metric-name "AuroraVolumeBytesLeftTotal" \
--start-time "$(date -d '4 hours ago')" --end-time "$(date -d 'now')" --period 1800 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBClusterIdentifier,Value=pq-57 \
--output text | sort -k 3
AuroraVolumeBytesLeftTotal
DATAPOINTS 140515818864640.0 2020-08-05T20:56:00+00:00 Count
DATAPOINTS 140515818864640.0 2020-08-05T21:26:00+00:00 Count
DATAPOINTS 140515818864640.0 2020-08-05T21:56:00+00:00 Count
DATAPOINTS 140514866757632.0 2020-08-05T22:26:00+00:00 Count
DATAPOINTS 140511020580864.0 2020-08-05T22:56:00+00:00 Count
DATAPOINTS 140503168843776.0 2020-08-05T23:26:00+00:00 Count
DATAPOINTS 140503168843776.0 2020-08-05T23:56:00+00:00 Count
DATAPOINTS 140515818864640.0 2020-08-06T00:26:00+00:00 Count
$ TiB=$((1024*1024*1024*1024))
$ TB=$((1000*1000*1000*1000))
$ echo "$((140515818864640 / $TB)) TB remaining for this cluster"
140 TB remaining for this cluster
$ echo "$((140515818864640 / $TiB)) TiB remaining for this cluster"
256 TiB remaining for this cluster
```
## Dimensionamento delle istanze
Puoi dimensionare il cluster database Aurora in base alle necessità, modificando la classe di istanza database per ogni istanza database nel cluster database. Aurora supporta diverse classi di istanze database ottimizzate per Aurora, a seconda della compatibilità del motore di database.
| Motore di database | Dimensionamento delle istanze |
| --- | --- |
| Amazon Aurora MySQL | Per informazioni, consulta [Dimensionamento delle istanze database Aurora MySQL](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.Performance.InstanceScaling) |
| Amazon Aurora PostgreSQL | Per informazioni, consulta [Dimensionamento delle istanze database Aurora PostgreSQL](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.Performance.InstanceScaling) |
## Dimensionamento della lettura
Puoi ottenere il dimensionamento della lettura per il cluster di database Aurora creando fino a 15 repliche Aurora nel cluster di database. Ogni replica Aurora restituisce gli stessi dati dal volume del cluster con ritardo di replica minimo—, in genere di molto inferiore a 100 millisecondi dopo che l'istanza primaria ha scritto un aggiornamento. Man mano che il traffico di lettura aumenta, puoi creare ulteriori repliche Aurora ed effettuare direttamente una connessione alle stesse per distribuire il carico di lettura del cluster DB. Non è necessario che le repliche Aurora appartengano alla stessa classe di istanze database dell'istanza primaria.
Per informazioni sull'aggiunta di repliche di Aurora a un cluster di database, consulta [Aggiunta di repliche di Aurora a un cluster di database](aurora-replicas-adding.md).
## Gestione delle connessioni
Il numero massimo di connessioni consentite a un'istanza database di Aurora è determinato dal parametro `max_connections` nel gruppo di parametri a livello di istanza per l'istanza database. Il valore predefinito di tale parametro varia in base alla classe di istanze database utilizzata per l'istanza database e alla compatibilità del motore di database.
| Motore di database | Valore predefinito di max\$1connections |
| --- | --- |
| Amazon Aurora MySQL | Per informazioni, consulta [Numero massimo di connessioni a un'istanza database Aurora MySQL](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections) |
| Amazon Aurora PostgreSQL | Per informazioni, consultare [Numero massimo di connessioni a un'istanza database Aurora PostgreSQL](AuroraPostgreSQL.Managing.md#AuroraPostgreSQL.Managing.MaxConnections). |
**Suggerimento**
Se le applicazioni aprono e chiudono frequentemente connessioni o mantengono un numero elevato di connessioni di lunga durata aperte, ti consigliamo di utilizzare Amazon RDS Proxy. Proxy RDS è un proxy di database completamente gestito e ad alta disponibilità che utilizza il pooling di connessioni per condividere connessioni di database in modo sicuro ed efficiente. Per ulteriori informazioni sul Proxy RDS, consulta [Proxy Amazon RDS per Aurora](rds-proxy.md).
## Gestione dei piani di esecuzione delle query
La gestione del piano di query per Aurora PostgreSQL ti consente di controllare quali piani verranno eseguiti dall'ottimizzatore. Per ulteriori informazioni, consulta [Gestione dei piani di esecuzione delle query per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.md).