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:
Argomenti
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. Per informazioni sui tipi di dati inclusi nel volume del cluster, consulta Archiviazione Amazon Aurora. Per informazioni sulla dimensione massima per una versione specifica, consulta Limiti di dimensione Amazon 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
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:
Motore del database Versioni con ridimensionamento dinamico Aurora MySQL -
Versione 3 (compatibile con MySQL 8.0): tutte le versioni supportate
-
Versione 2 (compatibile con MySQL 5.7): 2.11 e versioni successive
Aurora PostgreSQL Tutte le versioni supportate Aurora Serverless v2 Tutte le versioni supportate Aurora Serverless v1 Non disponibile -
-
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 di database a una versione del motore di database che supporta il ridimensionamento dinamico e quando la funzionalità è abilitata nella specifica Regione AWS, lo spazio che viene successivamente liberato tramite determinate istruzioni SQL, ad esempio
DROP TABLE, è recuperabile.Se la funzionalità è esplicitamente disabilitata in una determinata Regione AWS, lo spazio potrebbe essere solo riutilizzabile, e non recuperabile, anche 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 operazioniDROP TABLE, lo spazio corrispondente all’intero tablespace è recuperabile. -
Il parametro
innodb_file_per_tableinfluisce 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 impostareinnodb_file_per_tablesu 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.
-
Nella AWS Management Console puoi vedere questa cifra in un grafico visualizzando la scheda
Monitoringnella pagina dei dettagli del cluster. -
Con l'AWS CLI, puoi 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_identifierQuesto 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 i comandi della AWS CLI 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 3VolumeBytesUsed 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 3AuroraVolumeBytesLeftTotal 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 4VolumeBytesUsed 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.
$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 3AuroraVolumeBytesLeftTotal 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 |
|
Amazon Aurora PostgreSQL |
Per informazioni, consulta Dimensionamento delle istanze database Aurora PostgreSQL |
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.
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_connections |
|---|---|
|
Amazon Aurora MySQL |
Per informazioni, consulta Numero massimo di connessioni a un'istanza database Aurora MySQL |
|
Amazon Aurora PostgreSQL |
Per informazioni, consultare Numero massimo di connessioni a un'istanza database Aurora PostgreSQL. |
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 Server proxy per Amazon RDS per Aurora.
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.
