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 crescono, lo storage del volume del cluster si espande a seconda della versione del motore DB. Per informazioni sulle dimensioni massime dei volumi del cluster Aurora per ogni versione del motore, vedere. 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 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 precedente, il volume del cluster può riutilizzare lo spazio liberato quando si rimuovono i dati, ma le dimensioni del volume stesso 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, valgono le seguenti considerazioni:
-
Dopo aver aggiornato il cluster DB a una versione del motore DB che supporti il ridimensionamento dinamico e quando la funzionalità è abilitata in quella specifica area Regione AWS, qualsiasi spazio che viene successivamente liberato da determinate istruzioni SQL, ad esempio, è recuperabile.
DROP TABLESe 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 DB (1.23.0—1.23.4, 2.09.0—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 dimensioni diverse. Durante l'esecuzione
TRUNCATE TABLEdelle operazioni, lo spazio corrispondente al primo frammento è riutilizzabile e non recuperabile. Gli altri frammenti sono recuperabili. DuranteDROP TABLEle operazioni, lo spazio corrispondente all'intero tablespace è recuperabile. -
Il
innodb_file_per_tableparametro influisce sul modo in cui è organizzata la memorizzazione delle tabelle. 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. -
Nella versione 2.11 e successive, il tablespace temporaneo InnoDB viene eliminato e ricreato al riavvio. In questo modo lo spazio occupato dal tablespace temporaneo viene rilasciato al sistema e il volume del cluster viene ridimensionato. Per sfruttare appieno la funzionalità di ridimensionamento dinamico, consigliamo di aggiornare il cluster DB alla versione 2.11 o successiva.
Nota
La funzionalità di ridimensionamento dinamico non recupera spazio immediatamente quando le tabelle nelle tablespace vengono eliminate, ma gradualmente, a una velocità di circa 10 TB al giorno. Lo spazio nel tablespace di sistema non viene recuperato, perché il tablespace di sistema non viene mai rimosso. 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.
-
In AWS Management Console, è possibile visualizzare questa figura in un grafico visualizzando la
Monitoringscheda nella pagina dei dettagli del cluster. -
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_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 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 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
L'esempio seguente mostra come, in un cluster che esegue Aurora PostgreSQL, la dimensione libera riportata da rifletta il limite di 256 TiB. AuroraVolumeBytesLeftTotal
$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 Proxy 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.
