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, l'archiviazione del volume del cluster si espande fino a un massimo di 128 tebibyte (TiB) o 64 TiB. La dimensione massima dipende dalla versione del motore di database. 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 Mia SQL -
Versione 3 (compatibile con My SQL 8.0): tutte le versioni supportate
-
Versione 2 (compatibile con My SQL 5.7): 2.11 e successive
Aurora Postger SQL Tutte le versioni supportate Aurora Serverless v2 Tutte le versioni supportate Aurora Serverless v1 Tutte le versioni supportate -
-
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.
-
Questa funzionalità viene distribuita gradualmente nelle AWS regioni in cui Aurora è disponibile. A seconda della regione in cui si trova il cluster, questa funzionalità potrebbe non essere ancora disponibile.
Il ridimensionamento dinamico si applica alle operazioni che rimuovono o ridimensionano fisicamente i tablespace all'interno del volume del cluster. Pertanto, si applica a SQL dichiarazioni comeDROP TABLE, DROP DATABASETRUNCATE TABLE, e. ALTER TABLE ... DROP PARTITION Non si applica all'eliminazione di righe con l'istruzione DELETE. Se si elimina un numero elevato di righe da una tabella, è possibile eseguire l'SQLOPTIMIZE TABLEistruzione Aurora My o utilizzare l'SQLpg_repackestensione Aurora Postgre 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, lo spazio che viene successivamente liberato da determinate SQL istruzioni, 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 varie dimensioni. 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, assicurati di impostare su 1innodb_file_per_tableper i cluster Aurora My SQL DB per sfruttare appieno 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 controllare la quantità di spazio di archiviazione utilizzata da un cluster monitorando la metrica in. VolumeBytesUsed CloudWatch Per ulteriori informazioni sulla fatturazione dello storage, consulta Come viene fatturato lo storage dei dati Aurora.
-
In AWS Management Console, puoi vedere 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 archiviazione Aurora a volte continuano per qualche tempo in background dopo il completamento dell'SQListruzione pertinente.
Il primo esempio restituisce l'output nel JSON formato predefinito. I punti dati vengono restituiti in ordine arbitrario, non in base al timestamp. È possibile importare questi JSON dati in uno strumento di creazione 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 -k parametro del sort comando ordina l'output in base al terzo campo, che è il timestamp in formato Universal Coordinated Time (). UTC
$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 My SQL versione 2.09 o successiva o Aurora PostgreSQL, la dimensione gratuita 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 My SQL versione 2.09 o successiva o Aurora PostgreSQL, la dimensione libera riportata da riflette il limite di dimensione di 128 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"127 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 My SQL |
Consulta la sezione Scalabilità delle istanze Aurora My DB SQL |
|
Amazon Aurora Poster SQL |
Per informazioni, consulta Scalabilità delle istanze DB di Aurora SQL Postgree |
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 My SQL |
Consulta la sezione Numero massimo di connessioni a un'istanza Aurora My DB SQL |
|
Amazon Aurora Poster SQL |
Consulta la sezione Numero massimo di connessioni a un'istanza Aurora SQL Postgree DB |
Suggerimento
Se le tue applicazioni aprono e chiudono spesso connessioni o mantengono aperte un gran numero di connessioni di lunga durata, ti consigliamo di utilizzare Amazon RDS Proxy. RDSProxy è un proxy di database completamente gestito e ad alta disponibilità che utilizza il pool di connessioni per condividere le connessioni al database in modo sicuro ed efficiente. Per ulteriori informazioni su RDS Proxy, consulta. Utilizzo di Amazon RDS Proxy per Aurora
Gestione dei piani di esecuzione delle query
Se si utilizza la gestione dei piani di query per Aurora PostgreSQL, si ottiene il controllo sui piani eseguiti dall'ottimizzatore. Per ulteriori informazioni, consulta Gestione dei piani di esecuzione delle query per Aurora Postgre SQL.
