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 di Amazon Aurora MySQL
Nelle sezioni seguenti viene descritta la gestione di un cluster database Amazon Aurora MySQL.
**Topics**
+ [Gestione delle prestazioni e del dimensionamento per Amazon Aurora MySQL](AuroraMySQL.Managing.Performance.md)
+ [Backtrack di un cluster database Aurora](AuroraMySQL.Managing.Backtrack.md)
+ [Test di Amazon Aurora MySQL mediante query Fault Injection](AuroraMySQL.Managing.FaultInjectionQueries.md)
+ [Alterazione delle tabelle in Amazon Aurora mediante Fast DDL](AuroraMySQL.Managing.FastDDL.md)
+ [Visualizzazione dello stato del volume per un cluster DB Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md)
# Gestione delle prestazioni e del dimensionamento per Amazon Aurora MySQL
## Dimensionamento delle istanze database Aurora MySQL
È possibile dimensionare le istanze database Aurora MySQL in due diversi modi, ovvero tramite il dimensionamento delle istanze e il dimensionamento della lettura. Per ulteriori informazioni sul dimensionamento della lettura, consulta [Dimensionamento della lettura](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling).
Puoi dimensionare il cluster database Aurora MySQL in base alle necessità, modificando la classe di istanza database per ogni istanza database nel cluster database. Aurora MySQL supporta diverse classi di istanza database ottimizzate per Aurora. Non utilizzare classi di istanza db.t2 o db.t3 per cluster Aurora più grandi di dimensioni maggiori di 40 TB. Per le specifiche delle classi di istanza database supportate da Aurora MySQL, consulta [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md).
**Nota**
Consigliamo di utilizzare le classi di istanza database T solo per i server di sviluppo e test o altri server non di produzione. Per ulteriori informazioni sulle classi di istanza T, consulta [Utilizzo delle classi di istanza T per lo sviluppo e i test](AuroraMySQL.BestPractices.Performance.md#AuroraMySQL.BestPractices.T2Medium).
## Numero massimo di connessioni a un'istanza database Aurora MySQL
Il numero massimo di connessioni consentite a un'istanza database di Aurora MySQL è determinato dal parametro `max_connections` nel gruppo di parametri a livello di istanza per l'istanza database.
La tabella seguente elenca il valore predefinito risultante di `max_connections` per ciascuna classe di istanza database disponibile per Aurora MySQL. È possibile aumentare il numero massimo di connessioni all'istanza database Aurora MySQL eseguendo il dimensionamento dell'istanza a una classe di istanza database con più memoria oppure impostando un valore maggiore per il parametro `max_connections` nel gruppo di parametri DB per l'istanza, fino a 16.000.
**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).
Per informazioni dettagliate su come le istanze Aurora Serverless v2 gestiscono questo parametro, vedi [Numero massimo connessioni per Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections).
| Classe di istanza | Valore predefinito di max\$1connections |
| --- | --- |
| db.t2.small | 45 |
| db.t2.medium | 90 |
| db.t3.small | 45 |
| db.t3.medium | 90 |
| db.t3.large | 135 |
| db.t4g.medium | 90 |
| db.t4g.large | 135 |
| db.r3.large | 1000 |
| db.r3.xlarge | 2000 |
| db.r3.2xlarge | 3000 |
| db.r3.4xlarge | 4000 |
| db.r3.8xlarge | 5000 |
| db.r4.large | 1000 |
| db.r4.xlarge | 2000 |
| db.r4.2xlarge | 3000 |
| db.r4.4xlarge | 4000 |
| db.r4.8xlarge | 5000 |
| db.r4.16xlarge | 6000 |
| db.r5.large | 1000 |
| db.r5.xlarge | 2000 |
| db.r5.2xlarge | 3000 |
| db.r5.4xlarge | 4000 |
| db.r5.8xlarge | 5000 |
| db.r5.12xlarge | 6000 |
| db.r5.16xlarge | 6000 |
| db.r5.24xlarge | 7000 |
| db.r6g.large | 1000 |
| db.r6g.xlarge | 2000 |
| db.r6g.2xlarge | 3000 |
| db.r6g.4xlarge | 4000 |
| db.r6g.8xlarge | 5000 |
| db.r6g.12xlarge | 6000 |
| db.r6g.16xlarge | 6000 |
| db.r6i.large | 1000 |
| db.r6i.xlarge | 2000 |
| db.r6i.2xlarge | 3000 |
| db.r6i.4xlarge | 4000 |
| db.r6i.8xlarge | 5000 |
| db.r6i.12xlarge | 6000 |
| db.r6i.16xlarge | 6000 |
| db.r6i.24xlarge | 7000 |
| db.r6i.32xlarge | 7000 |
| db.r7g.large | 1000 |
| db.r7g.xlarge | 2000 |
| db.r7g.2xlarge | 3000 |
| db.r7g.4xlarge | 4000 |
| db.r7g.8xlarge | 5000 |
| db.r7g.12xlarge | 6000 |
| db.r7g.16xlarge | 6000 |
| db.r7i.large | 1000 |
| db.r7i.xlarge | 2000 |
| db.r7i.2xlarge | 3000 |
| db.r7i.4xlarge | 4000 |
| db.r7i.8xlarge | 5000 |
| db.r7i.12xlarge | 6000 |
| db.r7i.16xlarge | 6000 |
| db.r7i.24xlarge | 7000 |
| db.r7i.48xlarge | 8000 |
| db.r8g.large | 1000 |
| db.r8g.xlarge | 2000 |
| db.r8g.2xlarge | 3000 |
| db.r8g.4xlarge | 4000 |
| db.r8g.8xlarge | 5000 |
| db.r8g.12xlarge | 6000 |
| db.r8g.16xlarge | 6000 |
| db.r8g.24xlarge | 7000 |
| db.r8g.48xlarge | 8000 |
| db.x2g.large | 2000 |
| db.x2g.xlarge | 3000 |
| db.x2g.2xlarge | 4000 |
| db.x2g.4xlarge | 5000 |
| db.x2g.8xlarge | 6000 |
| db.x2g.12xlarge | 7000 |
| db.x2g.16xlarge | 7000 |
**Suggerimento**
Il calcolo del parametro `max_connections` utilizza il logaritmo in base 2 (diverso dal logaritmo naturale) e il valore `DBInstanceClassMemory` in byte per la classe di istanza Aurora MySQL selezionata. Il parametro accetta solo valori interi, con parti decimali troncate dai calcoli. La formula implementa i limiti di connessione come segue:
Incremento di connessione 1.000 per istanze R3, R4 e R5 di dimensioni superiori
Incremento di connessione 45 per le varianti di memoria delle istanze T2 e T3
Esempio: per db.r6g.large, mentre la formula calcola 1.069,2, il sistema implementa 1.000 per mantenere modelli incrementali coerenti.
Se crei un nuovo gruppo di parametri per personalizzare il valore predefinito del limite di connessioni, verificherai che il limite di connessioni predefinito deriva da una formula basata sul valore `DBInstanceClassMemory`. Come illustrato nella precedente tabella, la formula produce limiti di connessione che aumentano di 1000 al raddoppio della memoria tra istanze R3, R4 e R5 sempre più grandi e di 45 per dimensioni di memoria diverse delle istanze T2 e T3.
Consultare [Specifica dei parametri del database](USER_ParamValuesRef.md) per ulteriori informazioni su come è calcolato `DBInstanceClassMemory`.
Le istanze database Aurora MySQL e RDS for MySQL hanno quantità di sovraccarico della memoria differenti. Pertanto, il valore `max_connections` può essere diverso per istanze database Aurora MySQL e RDS MySQL che utilizzano la stessa classe di istanza. I valori nella tabella si applicano solo alle istanze database Aurora MySQL.
**Nota**
I limiti di connettività sensibilmente inferiori per le istanze T2 e T3 sono dovute al fatto che con Aurora queste classi di istanze sono destinate solo a scenari di test e sviluppo e non ai carichi di lavoro di produzione.
I limiti di connessione predefiniti si adattano ai sistemi che utilizzano i valori predefiniti per altre funzioni ad alto consumo di memori, come il pool di buffer e la cache delle query. Se modifichi queste altre impostazioni per il cluster, pensa a regolare il limite di connessione in base alla possibilità di aumento o diminuzione della memoria disponibile nelle istanze database.
## Limiti di storage temporaneo per Aurora MySQL
Aurora MySQL memorizza tabelle e indici nel sottosistema di archiviazione Aurora. Aurora MySQL utilizza l’archiviazione locale o temporanea separata per i file temporanei non persistenti e le tabelle temporanee non InnoDB. Inoltre, sono inclusi i file utilizzati per scopi quali l'ordinamento di set di dati di grandi dimensioni durante l'elaborazione delle query o per le operazioni di creazione dell'indice. Non include le tabelle temporanee InnoDB.
Per ulteriori informazioni sulle tabelle temporanee in Aurora MySQL versione 3, consulta [Nuovo comportamento della tabella temporanea in Aurora MySQL versione 3](ams3-temptable-behavior.md). Per ulteriori informazioni sulle tabelle temporanee nella versione 2, consulta [Comportamento del tablespace temporaneo in Aurora MySQL versione 2](AuroraMySQL.CompareMySQL57.md#AuroraMySQL.TempTables57).
I dati e i file temporanei su questi volumi vengono persi all’avvio e all’arresto dell’istanza database e durante la sostituzione dell’host.
Questi volumi di archiviazione locale sono supportati da Amazon Elastic Block Store (Amazon EBS) e possono essere estesi utilizzando una classe di istanza database più grande. Per ulteriori informazioni sullo storage, consultare [Archiviazione Amazon Aurora](Aurora.Overview.StorageReliability.md).
L’archiviazione locale viene utilizzata anche per importare dati da Amazon S3 utilizzando `LOAD DATA FROM S3` o `LOAD XML FROM S3` e per esportare dati in S3 utilizzando SELECT INTO OUTFILE S3. Per ulteriori informazioni sull’importazione e l’esportazione in S3, consulta quanto segue:
+ [Caricamento dei dati in un cluster DB Amazon Aurora MySQL da file di testo in un bucket Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md)
+ [Salvataggio dei dati da un cluster DB Amazon Aurora MySQL nei file di testo in un bucket Amazon S3](AuroraMySQL.Integrating.SaveIntoS3.md)
Aurora MySQL utilizza un’archiviazione permanente separata per i log degli errori, i log generali, i log delle query lente e i log di audit per la maggior parte delle classi di istanza database Aurora MySQL (esclusi i tipi di classi di istanza a prestazioni espandibili come db.t2, db.t3 e db.t4g). I dati su questo volume vengono mantenuti all’avvio e all’arresto dell’istanza database e durante la sostituzione dell’host.
Questo volume di archiviazione permanente è supportato anche da Amazon EBS e ha dimensioni fisse in base alla classe di istanza database. Non può essere esteso utilizzando una classe di istanza database più grande.
La tabella seguente mostra la quantità massima di spazio di archiviazione temporanea e permanente disponibile per ogni classe di istanza database Aurora MySQL. Per ulteriori informazioni sul supporto della classe di istanza database per Aurora, consultare [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md).
| DB instance class (Classe istanza database) | Spazio di archiviazione locale/temporanea massimo disponibile (GiB) | Spazio di archiviazione massimo aggiuntivo disponibile per i file di log (GiB) |
| --- | --- | --- |
| db.x2g.16xlarge | 1280 | 500 |
| db.x2g.12xlarge | 960 | 500 |
| db.x2g.8xlarge | 640 | 500 |
| db.x2g.4xlarge | 320 | 500 |
| db.x2g.2xlarge | 160 | 60 |
| db.x2g.xlarge | 80 | 60 |
| db.x2g.large | 40 | 60 |
| db.r8g.48xlarge | 3840 | 500 |
| db.r8g.24xlarge | 1920 | 500 |
| db.r8g.16xlarge | 1280 | 500 |
| db.r8g.12xlarge | 960 | 500 |
| db.r8g.8xlarge | 640 | 500 |
| db.r8g.4xlarge | 320 | 500 |
| db.r8g.2xlarge | 160 | 60 |
| db.r8g.xlarge | 80 | 60 |
| db.r8g.large | 32 | 60 |
| db.r7i.48xlarge | 3840 | 500 |
| db.r7i.24xlarge | 1920 | 500 |
| db.r7i.16xlarge | 1280 | 500 |
| db.r7i.12xlarge | 960 | 500 |
| db.r7i.8xlarge | 640 | 500 |
| db.r7i.4xlarge | 320 | 500 |
| db.r7i.2xlarge | 160 | 60 |
| db.r7i.xlarge | 80 | 60 |
| db.r7i.large | 32 | 60 |
| db.r7g.16xlarge | 1280 | 500 |
| db.r7g.12xlarge | 960 | 500 |
| db.r7g.8xlarge | 640 | 500 |
| db.r7g.4xlarge | 320 | 500 |
| db.r7g.2xlarge | 160 | 60 |
| db.r7g.xlarge | 80 | 60 |
| db.r7g.large | 32 | 60 |
| db.r6i.32xlarge | 2560 | 500 |
| db.r6i.24xlarge | 1920 | 500 |
| db.r6i.16xlarge | 1280 | 500 |
| db.r6i.12xlarge | 960 | 500 |
| db.r6i.8xlarge | 640 | 500 |
| db.r6i.4xlarge | 320 | 500 |
| db.r6i.2xlarge | 160 | 60 |
| db.r6i.xlarge | 80 | 60 |
| db.r6i.large | 32 | 60 |
| db.r6g.16xlarge | 1280 | 500 |
| db.r6g.12xlarge | 960 | 500 |
| db.r6g.8xlarge | 640 | 500 |
| db.r6g.4xlarge | 320 | 500 |
| db.r6g.2xlarge | 160 | 60 |
| db.r6g.xlarge | 80 | 60 |
| db.r6g.large | 32 | 60 |
| db.r5.24xlarge | 1920 | 500 |
| db.r5.16xlarge | 1280 | 500 |
| db.r5.12xlarge | 960 | 500 |
| db.r5.8xlarge | 640 | 500 |
| db.r5.4xlarge | 320 | 500 |
| db.r5.2xlarge | 160 | 60 |
| db.r5.xlarge | 80 | 60 |
| db.r5.large | 32 | 60 |
| db.r4.16xlarge | 1280 | 500 |
| db.r4.8xlarge | 640 | 500 |
| db.r4.4xlarge | 320 | 500 |
| db.r4.2xlarge | 160 | 60 |
| db.r4.xlarge | 80 | 60 |
| db.r4.large | 32 | 60 |
| db.t4g.large | 32 | – |
| db.t4g.medium | 32 | – |
| db.t3.large | 32 | – |
| db.t3.medium | 32 | – |
| db.t3.small | 32 | – |
| db.t2.medium | 32 | – |
| db.t2.small | 32 | – |
**Importante**
Questi valori rappresentano la quantità massima teorica di spazio di archiviazione libero su ogni istanza database. Lo spazio di archiviazione locale effettivo disponibile potrebbe essere inferiore. Aurora utilizza una parte dello spazio di archiviazione locale per i processi di gestione e l'istanza database utilizza una parte dello spazio di archiviazione locale anche prima che vengano caricati i dati. È possibile monitorare lo storage temporaneo disponibile per un'istanza database specifica con il parametro `FreeLocalStorage` CloudWatch, come descritto in [CloudWatch Parametri Amazon per Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). Al momento è possibile verificare la quantità di spazio di archiviazione gratuito. È inoltre possibile tracciare la quantità di spazio di archiviazione gratuito nel tempo. Il monitoraggio dello spazio di archiviazione gratuito nel tempo consente di determinare se il valore è in aumento o in diminuzione o di trovare i valori minimi, massimi o medi.
(Non valido per Aurora Serverless v2)
# Backtrack di un cluster database Aurora
Con Amazon Aurora edizione compatibile con MySQL, puoi eseguire il backtrack di un cluster database a un orario specifico, senza ripristinare i dati da un backup.
**Contents**
+ [Panoramica del backtrack](#AuroraMySQL.Managing.Backtrack.Overview)
+ [Finestra di backtrack](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackWindow)
+ [Orario di backtrack](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackTime)
+ [Limiti del backtrack](#AuroraMySQL.Managing.Backtrack.Limitations)
+ [Disponibilità di regioni e versioni](#AuroraMySQL.Managing.Backtrack.Availability)
+ [Considerazioni sull'aggiornamento per i cluster abilitati per backtrack](#AuroraMySQL.Managing.Backtrack.Upgrade)
+ [Configurazione del backtrack di un cluster di database Aurora MySQL](AuroraMySQL.Managing.Backtrack.Configuring.md)
+ [Esecuzione di un backtrack per un cluster di database Aurora MySQL](AuroraMySQL.Managing.Backtrack.Performing0.md)
+ [Monitoraggio del backtrack per un cluster di database Aurora MySQL](AuroraMySQL.Managing.Backtrack.Monitoring.md)
+ [Abbonamento a un evento di backtrack con la console](#AuroraMySQL.Managing.Backtrack.Event.Console)
+ [Recupero di backtrack esistenti](#AuroraMySQL.Managing.Backtrack.Retrieving)
+ [Disabilitazione del backtrack per un cluster di database Aurora MySQL](AuroraMySQL.Managing.Backtrack.Disabling.md)
## Panoramica del backtrack
Il backtrack "riavvolge" il cluster database all'orario che specifichi. Il backtrack non è un'operazione sostitutiva del backup del cluster database che consente di eseguire un ripristino point-in-time dello stesso. Fornisce tuttavia i seguenti vantaggi rispetto alle operazioni di backup e ripristino tradizionali:
+ Puoi annullare facilmente eventuali errori. Se esegui accidentalmente un'operazione distruttiva, come DELETE senza una clausola WHERE, puoi eseguire il backtrack del cluster database a un orario antecedente all'operazione distruttiva con un'interruzione minima del servizio.
+ Puoi eseguire il backtrack di un cluster database rapidamente. Il ripristino point-in-time di un cluster database avvia un nuovo cluster database e lo ripristina a partire dai dati di backup o da uno snapshot e questa operazione può durare varie ore. Il backtrack di un cluster database non richiede un nuovo cluster database e "riavvolge" il cluster all'orario specificato in pochi minuti.
+ Puoi esplorare le modifiche ai dati precedenti. Puoi eseguire ripetutamente il backtrack di un cluster database avanti e indietro nel tempo per determinare quando si è verificata una determinata modifica. Ad esempio, puoi eseguire il backtrack di un cluster database tre ore indietro e quindi un'ora avanti. In questo caso, l'orario di backtrack è due ore prima l'orario di origine.
**Nota**
Per informazioni sul ripristino point-in-time di un cluster database, consulta [Panoramica di backup e ripristino di un cluster di database Aurora](Aurora.Managing.Backups.md).
### Finestra di backtrack
Con il backtrack, si ha una finestra di backtrack target e una finestra di backtrack effettiva:
+ La *finestra di backtrack target* è il periodo di tempo durante il quale desideri eseguire il backtrack del cluster di database. Quando abiliti il backtrack, specifichi una *finestra di backtrack target*. Ad esempio, potresti specificare una finestra di backtrack target di 24 ore se desideri eseguire un backtrack di un giorno per il cluster di database.
+ La *finestra di backtrack effettiva* è il periodo di tempo effettivo durante il quale puoi eseguire il backtrack del cluster di database, che può essere inferiore alla finestra di backtrack target. La finestra di backtrack effettiva è basata sul carico di lavoro e sullo storage disponibile per archiviare le informazioni relative alle modifiche del database denominate *record di modifica.*
Quando aggiorni il cluster di database Aurora con il backtrack abilitato, generi record di modifica. Aurora conserva i record di modifica per la finestra di backtrack di destinazione e per l’archiviazione di questi dati si applica una tariffa oraria. La finestra di backtrack target e il carico di lavoro sul cluster di database determinano il numero di record di modifica che vengono archiviati. Il carico di lavoro è il numero di modifiche che apporti al cluster di database in un determinato periodo di tempo. Il numero di record di modifica archiviati nella finestra di backtrack quando il carico di lavoro è pesante è maggiore rispetto a quello con un carico di lavoro leggero.
Puoi considerare la finestra di backtrack target come l'obiettivo per il periodo di tempo massimo durante il quale desideri eseguire il backtrack del cluster di database. Nella maggior parte dei casi, puoi eseguire un backtrack corrispondente al periodo di tempo massimo specificato. Tuttavia, in alcuni casi, il cluster di database non può archiviare un numero sufficiente di record di modifica per eseguire un backtrack corrispondente al periodo di tempo massimo e la finestra di backtrack effettiva è più piccola della finestra di backtrack target. In genere, la finestra di backtrack effettiva è più piccola di quella target quando il carico di lavoro è estremamente pesante sul cluster di database. Quando la finestra di backtrack effettiva è più piccola di quella target, ti inviamo una notifica.
Quando il backtrack è abilitato per un cluster di database ed elimini una tabella archiviata in quel cluster, Aurora conserva quella tabella nei record di modifica del backtrack. In questo modo, puoi ritornare a un orario antecedente a quello in cui hai eliminato la tabella. Se tuttavia non hai spazio sufficiente nella finestra di backtrack per archiviare la tabella, è possibile che questa venga rimossa dai record di modifica del backtrack.
### Orario di backtrack
Aurora esegue sempre il backtrack a un orario coerente per il cluster di database. In questo modo, viene eliminata la possibilità di transazioni di cui non è stato eseguito il commit al completamento del backtrack. Quando specifichi un orario per un backtrack, Aurora sceglie automaticamente l'orario coerente più vicino possibile. Questo approccio significa che il backtrack completato potrebbe non corrispondere esattamente all'ora specificata, ma è possibile determinare l'ora esatta per un backtrack utilizzando il comando CLI [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) AWS . Per ulteriori informazioni, consulta [Recupero di backtrack esistenti](#AuroraMySQL.Managing.Backtrack.Retrieving).
### Limiti del backtrack
I seguenti limiti si applicano al backtrack:
+ Il backtrack è disponibile solo per i cluster di database creati con la funzionalità di backtrack abilitata. Non puoi modificare un cluster di database per abilitare la funzionalità di backtrack. Puoi abilitare il backtrack quando crei un nuovo cluster di database o ripristini uno snapshot di un cluster di database.
+ Il limite per una finestra di backtrack è 72 ore.
+ Il backtrack influisce sull'intero cluster di database. Ad esempio, non puoi eseguire un backtrack selettivo di una singola tabella o di un singolo aggiornamento di dati.
+ Non puoi creare repliche di lettura tra Regioni da un cluster abilitato al backtrack, ma puoi comunque abilitare la replica dei log binari (binlog) sul cluster. Se tenti di eseguire il backtrack di un cluster di database per il quale è abilitata la registrazione di log binari, in genere si verifica un errore a meno che tu non abbia scelto di forzare il backtrack. Qualsiasi tentativo di forzare un backtrack interromperà le repliche di lettura successive e interferirà con altre operazioni come le distribuzioni. blue/green
+ Non puoi eseguire il backtrack di un clone di database a un orario antecedente a quello di creazione del clone. Puoi tuttavia utilizzare il database originale per eseguire il backtrack a un orario antecedente a quello di creazione del clone. Per ulteriori informazioni sulla creazione di cloni di database, consulta [Clonazione di un volume per un cluster di database Amazon Aurora](Aurora.Managing.Clone.md).
+ Il backtrack comporta una breve interruzione dell'istanza database. Devi arrestare o interrompere le applicazioni prima di avviare un'operazione di backtrack per assicurarti che non vi siano nuove richieste di lettura o scrittura. Durante l'operazione di backtrack, Aurora interrompe il database, chiude tutte le connessioni aperte ed elimina le letture e scritture di cui non è stato eseguito il commit. Attende quindi il completamento dell'operazione di backtrack.
+ Non è possibile ripristinare un'istantanea interregionale di un cluster abilitato al backtrack in una regione che non supporta il backtracking. AWS
+ Se si esegue un aggiornamento locale di un cluster abilitato per il backtrack da Aurora MySQL versione 2 alla versione 3, non è possibile eseguire il backtrack a un punto temporale precedente all'esecuzione dell'aggiornamento.
## Disponibilità di regioni e versioni
Backtrack non è disponibile per Aurora PostgreSQL.
Di seguito sono riportati i motori supportati e la disponibilità nelle regioni per backtrack con Aurora MySQL.
| Region | Aurora MySQL versione 3 | Aurora MySQL versione 2 |
| --- | --- | --- |
| Stati Uniti orientali (Virginia settentrionale) | Tutte le versioni | Tutte le versioni |
| Stati Uniti orientali (Ohio) | Tutte le versioni | Tutte le versioni |
| Stati Uniti occidentali (California settentrionale) | Tutte le versioni | Tutte le versioni |
| Stati Uniti occidentali (Oregon) | Tutte le versioni | Tutte le versioni |
| Africa (Città del Capo) | – | – |
| Asia Pacifico (Hong Kong) | – | – |
| Asia Pacifico (Giacarta) | – | – |
| Asia Pacifico (Malesia) | – | – |
| Asia Pacifico (Melbourne) | – | – |
| Asia Pacifico (Mumbai) | Tutte le versioni | Tutte le versioni |
| Asia Pacifico (Nuova Zelanda) | – | – |
| Asia Pacifico (Osaka-Locale) | Tutte le versioni | Versione 2.07.3 e versioni successive |
| Asia Pacifico (Seul) | Tutte le versioni | Tutte le versioni |
| Asia Pacifico (Singapore) | Tutte le versioni | Tutte le versioni |
| Asia Pacifico (Sydney) | Tutte le versioni | Tutte le versioni |
| Asia Pacifico (Taipei) | – | – |
| Asia Pacifico (Thailandia) | – | – |
| Asia Pacifico (Tokyo) | Tutte le versioni | Tutte le versioni |
| Canada (Centrale) | Tutte le versioni | Tutte le versioni |
| Canada occidentale (Calgary) | – | – |
| Cina (Pechino) | – | – |
| China (Ningxia) | – | – |
| Europa (Francoforte) | Tutte le versioni | Tutte le versioni |
| Europa (Irlanda) | Tutte le versioni | Tutte le versioni |
| Europa (Londra) | Tutte le versioni | Tutte le versioni |
| Europa (Milano) | – | – |
| Europa (Parigi) | Tutte le versioni | Tutte le versioni |
| Europa (Spagna) | – | – |
| Europa (Stoccolma) | – | – |
| Europa (Zurigo) | – | – |
| Israele (Tel Aviv) | – | – |
| Messico (centrale) | – | – |
| Medio Oriente (Bahrein) | – | – |
| Medio Oriente (Emirati Arabi Uniti) | – | – |
| Sud America (San Paolo) | – | – |
| AWS GovCloud (Stati Uniti orientali) | – | – |
| AWS GovCloud (Stati Uniti occidentali) | – | – |
## Considerazioni sull'aggiornamento per i cluster abilitati per backtrack
Puoi aggiornare un cluster di database abilitato per il backtrack da Aurora MySQL versione 2 alla versione 3 perché tutte le versioni secondarie di Aurora MySQL versione 3 sono supportate per il backtrack.
# Configurazione del backtrack di un cluster di database Aurora MySQL
Per utilizzare la funzionalità di backtrack, devi abilitarla e specificare una finestra di backtrack target. In caso contrario, il backtrack è disabilitato.
Nella finestra di backtrack target, specifica il periodo di tempo durante il quale desideri "riavvolgere" il database utilizzando la funzionalità di backtrack. Aurora prova conservare un numero di record di modifica sufficiente per supportare quella finestra temporale.
## Console
Puoi utilizzare la console per configurare il backtrack quando crei un nuovo cluster di database. È inoltre possibile modificare un cluster DB per modificare la finestra di backtrack per un cluster abilitato per backtrack. Se si disattiva completamente il backtracking per un cluster impostando la finestra backtrack su 0, non sarà poi possibile attivare nuovamente il backtrack per quel cluster.
**Topics**
+ [Configurazione del backtrack mediante la console alla creazione di un cluster di database](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Creating)
+ [Configurazione del backtrack mediante la console alla modifica di un cluster database](#AuroraMySQL.Managing.Backtrack.Configuring.Console.Modifying)
### Configurazione del backtrack mediante la console alla creazione di un cluster di database
Quando crei un nuovo cluster di database Aurora MySQL puoi configurare il backtrack scegliendo **Enable Backtrack (Abilita backtrack)** e specificando un valore per **Target Backtrack window (Finestra di backtrack target)** che sia maggiore di zero nella sezione **Backtrack**.
Per creare un cluster database, segui le istruzioni in [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md). L'immagine seguente mostra la sezione **Backtrack**.
![\[Abilitare il backtrack durante la creazione del cluster database con la console\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-create.png)
Quando crei un nuovo cluster database, Aurora non dispone dei dati relativi al carico di lavoro del cluster database. Di conseguenza, non può stimare un costo per il nuovo cluster database. La console indica tuttavia un costo utente standard per la finestra di backtrack target specificata basato su un carico di lavoro tipico. Questo costo standard è un riferimento generale per il costo della funzionalità di backtrack.
**Importante**
Il costo effettivo potrebbe non corrispondere a quello standard in quanto è basato sul carico di lavoro del cluster database.
### Configurazione del backtrack mediante la console alla modifica di un cluster database
Puoi modificare il backtrack per un cluster database mediante la console.
**Nota**
Attualmente, è possibile modificare il backtracking solo per un cluster DB in cui è abilitata la funzionalità Backtrack. La sezione **Backtrack** non viene visualizzata per un cluster DB creato con la funzionalità Backtrack disattivata o se la funzionalità Backtrack è stata disattivata per il cluster DB.
**Per modificare il backtrack per un cluster database mediante la console**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegliere **Databases (Database)**.
1. Scegliere il cluster da modificare, quindi scegliere **Modify (Modifica)**.
1. In **Target Backtrack window (Finestra di backtrack target)**, modificare il periodo di tempo durante il quale si desidera eseguire il backtrack. Il limite è 72 ore.
![\[Modificare il backtrack con la console\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-modify.png)
La console mostra il costo stimato per il periodo di tempo specificato in base al carico di lavoro precedente del cluster database:
+ Se il backtracking è stato disabilitato sul cluster DB, la stima dei costi si basa sulla `VolumeWriteIOPS` metrica per il cluster DB in Amazon. CloudWatch
+ Se il backtracking era stato abilitato in precedenza sul cluster DB, la stima dei costi si basa sulla `BacktrackChangeRecordsCreationRate` metrica per il cluster DB in Amazon. CloudWatch
1. Scegli **Continue (Continua)**.
1. In **Scheduling of Modifications (Pianificazione delle modifiche)**, scegliere una delle seguenti opzioni:
+ **Apply during the next scheduled maintenance window (Applica durante la prossima finestra di manutenzione pianificata)**: –attendere la finestra di manutenzione successiva per applicare la modifica di **Target Backtrack window (Finestra di backtrack target)**.
+ **Apply immediately (Applica immediatamente)**: –applicare la modifica di **Target Backtrack window (Finestra di backtrack target)** appena possibile.
1. Scegliere **Modify cluster (Modifica cluster)**.
## AWS CLI
Quando si crea un nuovo cluster Aurora MySQL DB utilizzando il comando [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI, il backtracking viene configurato quando si specifica un valore maggiore di zero. `--backtrack-window` Il valore `--backtrack-window` specifica la finestra di backtrack target. Per ulteriori informazioni, consulta [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md).
È inoltre possibile specificare il `--backtrack-window` valore utilizzando i seguenti comandi AWS CLI:
+ [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
+ [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html)
+ [restore-db-cluster-from-istantanea](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html)
+ [restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)
La procedura seguente descrive come modificare la finestra di backtrack target per un cluster database mediante l AWS CLI.
**Per modificare la finestra di backtrack di destinazione per un cluster DB utilizzando il AWS CLI**
+ Chiamate il comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI e fornite i seguenti valori:
+ `--db-cluster-identifier`:– il nome del cluster database.
+ `--backtrack-window`:– il numero massimo di secondi durante i quali si desidera eseguire il backtrack del cluster database.
L'esempio seguente imposta la finestra di backtrack target per `sample-cluster` su un giorno (86.400 secondi).
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 86400
```
Per Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 86400
```
**Nota**
Attualmente, è possibile abilitare il backtrack solo per un cluster database creato con la funzionalità di backtrack abilitata.
## API RDS
Quando crei un nuovo cluster Aurora MySQL DB utilizzando l'operazione Create [DBClusterAmazon](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) RDS API, il backtracking viene configurato quando si specifica un valore maggiore di zero. `BacktrackWindow` Il valore `BacktrackWindow` specifica la finestra di backtrack target per il cluster database specificato nel valore `DBClusterIdentifier`. Per ulteriori informazioni, consulta [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md).
Puoi anche specificare il valore `BacktrackWindow` utilizzando le seguenti operazioni API:
+ [ModificaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ [Ripristina da S3 DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html)
+ [RipristinaDBClusterFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [RipristinaDBClusterToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
**Nota**
Attualmente, è possibile abilitare il backtrack solo per un cluster database creato con la funzionalità di backtrack abilitata.
# Esecuzione di un backtrack per un cluster di database Aurora MySQL
Puoi eseguire il backtrack di un cluster database a un timestamp di backtrack specificato. Se il timestamp di backtrack non è anteriore al primo orario di backtrack possibile e non è nel futuro, il backtrack del cluster database viene eseguito a quel timestamp.
In caso contrario, si ha in genere un errore. Inoltre, se cerchi di eseguire il backtrack di un cluster database per il quale la registrazione binaria è abilitata, in genere si verifica un errore a meno che non hai scelto di forzare il backtrack. Forzare un backtrack può interferire con altre operazioni che utilizzano la registrazione binaria.
**Importante**
Il backtrack non genera voci binlog per le modifiche che esegue. Se la registrazione binaria è abilitata per il cluster database, il backtrack potrebbe non essere compatibile con l'implementazione binlog.
**Nota**
Per i cloni di database, non puoi eseguire il backtrack del cluster database a un orario anteriore a quello di creazione del clone. Per ulteriori informazioni sulla creazione di cloni di database, consulta [Clonazione di un volume per un cluster di database Amazon Aurora](Aurora.Managing.Clone.md).
## Console
La procedura seguente descrive come eseguire un'operazione di backtrack per un cluster database mediante la console.
**Per eseguire un'operazione di backtrack mediante la console**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione, scegliere **Instances (Istanze)**.
1. Scegliere l'istanza principale del cluster database per il quale si intende eseguire il backtrack.
1. In **Actions (Operazioni)**, scegliere **Backtrack DB cluster (Esegui backtrack del cluster database)**.
1. Nella pagina **Backtrack DB cluster (Esegui backtrack del cluster database)**, inserire il timestamp di backtrack a cui eseguire il backtrack del cluster database.
![\[Backtrack DB cluster (Esegui backtrack del cluster database)\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-db-cluster.png)
1. Scegliere **Backtrack DB cluster (Esegui backtrack del cluster database)**.
## AWS CLI
La procedura seguente descrive il modo in cui eseguire il backtrack di un cluster database mediante l AWS CLI.
**Per eseguire il backtrack di un cluster database mediante l AWS CLI**
+ Chiamare il comando [backtrack-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/backtrack-db-cluster.html) dell'CLI AWS e specificare i seguenti valori:
+ `--db-cluster-identifier`:– il nome del cluster database.
+ `--backtrack-to`:– il timestamp di backtrack a cui eseguire il backtrack del cluster database, specificato nel formato ISO 8601.
L'esempio seguente esegue il backtrack del cluster database `sample-cluster` con il timestamp 19 marzo 2018, ore 10.
Per Linux, macOS o Unix:
```
aws rds backtrack-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-to 2018-03-19T10:00:00+00:00
```
Per Windows:
```
aws rds backtrack-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-to 2018-03-19T10:00:00+00:00
```
## API RDS
Per eseguire il backtrack di un cluster database mediante l'API Amazon RDS, utilizza l'operazione [BacktrackDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_BacktrackDBCluster.html). Questa operazione esegue il backtrack del cluster database specificato nel valore `DBClusterIdentifier` all'orario specificato.
# Monitoraggio del backtrack per un cluster di database Aurora MySQL
Puoi visualizzare le informazioni relative al backtrack e monitorare i parametri di backtrack per un cluster database.
## Console
**Per visualizzare le informazioni relative al backtrack e monitorare i parametri di backtrack mediante la console**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegliere **Databases (Database)**.
1. Scegliere il nome del cluster database di cui si intende visualizzare le informazioni.
Le informazioni relative al backtrack sono visualizzate nella sezione **Backtrack**.
![\[Informazioni relative al backtrack per un cluster database\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-details.png)
Quando il backtrack è abilitato, sono disponibili le seguenti informazioni:
+ **Target window (Finestra target)**:– il periodo di tempo corrente specificato per la finestra di backtrack target. Il target è il periodo di tempo massimo durante il quale è possibile effettuare il backtrack se lo storage è sufficiente.
+ **Actual window (Finestra effettiva)**:– il periodo di tempo effettivo durante il quale è possibile eseguire il backtrack, che può essere inferiore alla finestra di backtrack target. La finestra di backtrack effettiva è basata sul carico di lavoro e sullo storage disponibile per conservare i record di modifica del backtrack.
+ **Earliest backtrack time (Primo orario di backtrack)**: –specifica il primo orario di backtrack possibile per il cluster database. Non è possibile eseguire il backtrack del cluster database a un orario antecedente a quello visualizzato.
1. Per visualizzare i parametri di backtrack per il cluster database, procedere come segue:
1. Nel riquadro di navigazione, scegliere **Instances (Istanze)**.
1. Scegliere il nome dell'istanza principale per il cluster database di cui si intende visualizzarne i dettagli.
1. Nella **CloudWatch**sezione, digita **Backtrack** nella **CloudWatch**casella per mostrare solo le metriche di Backtrack.
![\[Parametri di backtrack\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-metrics.png)
Sono visualizzati i seguenti parametri:
+ **Backtrack Change Records Creation Rate (Count) (Frequenza di creazione record modifiche backtrack (numero))**:– questo parametro visualizza il numero di record di modifica di backtrack creati in un intervallo di cinque minuti per il cluster database. È possibile utilizzare questo parametro per stimare il costo di backtrack per la finestra di backtrack target.
+ **[Billed] Backtrack Change Records Stored (Count) ([Fatturato] Record modifiche backtrack archiviati (numero))**:– questo parametro visualizza il numero effettivo di record di modifica di backtrack utilizzati dal cluster di database.
+ **Backtrack Window Actual (Minutes) (Finestra di backtrack effettiva) (Minuti)**: –questo parametro indica se c'è una differenza tra la finestra di backtrack target e la finestra di backtrack effettiva. Ad esempio, se la finestra di backtrack target è 2 ore (120 minuti) e questo parametro indica che la finestra di backtrack effettiva è 100 minuti, quest'ultima è più piccola della finestra target.
+ **Backtrack Window Alert (Count) (Avviso finestra di backtrack (numero))**: –questo parametro indica quante volte la finestra di backtrack effettiva è inferiore alla finestra di backtrack target per un determinato periodo di tempo.
**Nota**
I parametri seguenti potrebbero essere indietro rispetto all'orario corrente:
**Backtrack Change Records Creation Rate (Count)** (Frequenza di creazione record modifiche backtrack (numero))
**[Billed] Backtrack Change Records Stored (Count) ([Fatturato] Record modifiche backtrack archiviati (numero))**
## AWS CLI
La procedura seguente descrive come visualizzare informazioni relative al backtrack per un cluster di database mediante l AWS CLI.
**Per visualizzare le informazioni di backtrack per un cluster DB utilizzando il AWS CLI**
+ Chiamate il comando [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) AWS CLI e fornite i seguenti valori:
+ `--db-cluster-identifier`:– il nome del cluster database.
L'esempio seguente elenca le informazioni relative al backtrack per `sample-cluster`.
Per Linux, macOS o Unix:
```
aws rds describe-db-clusters \
--db-cluster-identifier sample-cluster
```
Per Windows:
```
aws rds describe-db-clusters ^
--db-cluster-identifier sample-cluster
```
## API RDS
Per visualizzare le informazioni di backtrack per un cluster DB utilizzando l'API Amazon RDS, utilizza l'operazione [DBClustersDescrivi](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html). Questa operazione restituisce le informazioni relative al backtrack per il cluster database specificato nel valore `DBClusterIdentifier`.
## Abbonamento a un evento di backtrack con la console
La procedura seguente descrive come abbonarsi a un evento di backtrack mediante la console. L'evento ti invia un'email o una notifica di testo quando la finestra di backtrack effettiva è più piccola della finestra di backtrack target.
**Per visualizzare le informazioni di backtrack mediante la console**
1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegliere **Event subscriptions (Abbonamenti a eventi)**.
1. Scegliere **Create event subscription (Crea abbonamento a eventi)**.
1. Nella casella **Name (Nome)**, digitare un nome per l'abbonamento all'evento e assicurarsi che **Yes (Sì)** è selezionato per **Enabled (Abilitato)**.
1. Nella sezione **Target**, scegliere **New email topic (Nuovo argomento e-mail)**.
1. In **Topic name (Nome argomento)**, digitare un nome per l'argomento e in **With these recipients (Con questi destinatari)**, digitare gli indirizzi e-mail o i numeri di telefono per ricevere le notifiche.
1. Nella sezione **Source (origine)**, scegliere **Instances (Istanze)** per **Source type (Tipo origine)**.
1. Per **Instances to include (Istanze da includere)**, scegliere **Select specific instances (Seleziona specifiche istanze)** e scegliere l'istanza database.
1. In **Event categories to include (Categorie di eventi da includere)**, scegliere **Select specific event categories (Seleziona specifiche categorie di eventi)**, quindi scegliere **Backtrack**.
La pagina dovrebbe essere simile alla seguente.
![\[Abbonamento a eventi di backtrack\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-event.png)
1. Scegliere **Create (Crea)**.
## Recupero di backtrack esistenti
Puoi recuperare informazioni relative a backtrack esistenti per un cluster di database. Queste informazioni includono l'identificatore univoco del backtrack, la data e l'ora di inizio e di fine del backtrack, la data e l'ora in cui il backtrack è stato richiesto e lo stato corrente del backtrack.
**Nota**
Non è attualmente possibile recuperare backtrack esistenti mediante la console.
### AWS CLI
La procedura seguente descrive come recuperare backtrack esistenti per un cluster di database mediante l AWS CLI.
**Per recuperare i backtrack esistenti utilizzando il AWS CLI**
+ Chiamate il comando [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) AWS CLI e fornite i seguenti valori:
+ `--db-cluster-identifier`:– il nome del cluster database.
L'esempio seguente recupera i backtrack esistenti per `sample-cluster`.
Per Linux, macOS o Unix:
```
aws rds describe-db-cluster-backtracks \
--db-cluster-identifier sample-cluster
```
Per Windows:
```
aws rds describe-db-cluster-backtracks ^
--db-cluster-identifier sample-cluster
```
### API RDS
Per recuperare informazioni sui backtrack per un cluster DB utilizzando l'API Amazon RDS, utilizza l'operazione [DBClusterDescrivi](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterBacktracks.html) Backtracks. Questa operazione restituisce le informazioni relative ai backtrack per il cluster database specificato nel valore `DBClusterIdentifier`.
# Disabilitazione del backtrack per un cluster di database Aurora MySQL
Puoi disabilitare la funzionalità di backtrack per un cluster di database.
## Console
Puoi disabilitare il backtrack per un cluster di database mediante la console. Dopo aver disattivato completamente il backtracking per un cluster, non sarà possibile attivarlo di nuovo per tale cluster.
**Per disabilitare la funzionalità di backtrack per un cluster di database mediante la console**
1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegliere **Databases (Database)**.
1. Scegliere il cluster da modificare, quindi scegliere **Modify (Modifica)**.
1. Nella sezione **Backtrack**, scegliere **Disable Backtrack (Disabilita backtrack)**.
1. Scegli **Continue (Continua)**.
1. In **Scheduling of Modifications (Pianificazione delle modifiche)**, scegliere una delle seguenti opzioni:
+ **Apply during the next scheduled maintenance window (Applica durante la prossima finestra di manutenzione pianificata)**:– attendere la finestra di manutenzione successiva per applicare la modifica.
+ **Apply immediately (Applica immediatamente)**:– applicare la modifica appena possibile.
1. Scegliere **Modify Cluster (Modifica cluster)**.
## AWS CLI
Puoi disabilitare la funzionalità di backtrack per un cluster di database mediante l'AWS CLI impostando la finestra di backtrack target su `0` (zero). Dopo aver disattivato completamente il backtracking per un cluster, non sarà possibile attivarlo di nuovo per tale cluster.
**Per modificare la finestra di backtrack target per un cluster di database mediante l AWS CLI**
+ Chiamare il comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) della CLI AWS e specificare i seguenti valori:
+ `--db-cluster-identifier`:– il nome del cluster database.
+ `--backtrack-window` – specifica `0` per disattivare il backtracking.
L'esempio seguente disabilita la funzionalità di backtrack per `sample-cluster` impostando `--backtrack-window` su `0`.
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--backtrack-window 0
```
Per Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--backtrack-window 0
```
## API RDS
Per disabilitare la funzionalità di backtrack per un cluster di database mediante l'API Amazon RDS, utilizzare l'operazione [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Imposta il valore `BacktrackWindow` su `0` (zero) e specifica il cluster di database nel valore `DBClusterIdentifier`. Dopo aver disattivato completamente il backtracking per un cluster, non sarà possibile attivarlo di nuovo per tale cluster.
# Test di Amazon Aurora MySQL mediante query Fault Injection
Puoi testare la tolleranza ai guasti del tuo cluster database Aurora MySQL utilizzando query Fault Injection. Le query di errore di iniezione vengono emesse come comandi SQL per un'istanza Amazon Aurora. Queste funzionalità ti consentono di pianificare l'occorrenza simulata di uno dei seguenti eventi:
+ Un arresto anomalo di un'istanza database di lettura o di scrittura
+ Un errore di una replica Aurora
+ Un errore del disco
+ Una congestione del disco
Quando una query Fault Injection specifica un arresto anomalo, impone un arresto anomalo dell'istanza database Aurora MySQL. Le altre query fault injection generano simulazioni di eventi di errore, ma non causano l'evento. Quando invii una query fault injection, specifichi anche la durata della simulazione dell'evento di errore.
Puoi inviare una query fault injection a una delle istanze di replica Aurora eseguendo la connessione all'endpoint per la replica Aurora. Per ulteriori informazioni, consulta [Connessioni degli endpoint Amazon Aurora](Aurora.Overview.Endpoints.md).
L'esecuzione di query fault injection richiede tutti i privilegi dell'utente master. Per ulteriori informazioni, consulta [Privilegi dell'account utente master](UsingWithRDS.MasterAccounts.md).
## Test dell'arresto anomalo di un'istanza
Puoi forzare un arresto anomalo di un'istanza Amazon Aurora utilizzando la query fault injection `ALTER SYSTEM CRASH`.
Per questa query fault injection, non si verificherà un failover. Se desideri testare un failover, puoi scegliere l'azione dell'istanza di **failover** per il tuo cluster DB nella console RDS o utilizzare il [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) AWS CLI comando o l'operazione API [Failover DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) RDS.
### Sintassi
```
1. ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];
```
### Opzioni
Questa query fault injection accetta uno dei seguenti tipi di arresto anomalo:
+ **`INSTANCE`** — Viene simulato un arresto anomalo del database compatibile con MySQL per l'istanza Amazon Aurora.
+ **`DISPATCHER`** — Viene simulato un arresto anomalo del dispatcher sull'istanza di scrittura per il cluster database di Aurora. Il *dispatcher* scrive gli aggiornamenti sul volume del cluster per un cluster di database Amazon Aurora.
+ **`NODE`** — Viene simulato un arresto anomalo del database compatibile con MySQL e del dispatcher per l'istanza Amazon Aurora. Per questa simulazione fault injection, viene inoltre eliminata la cache.
Il tipo di arresto anomalo predefinito è `INSTANCE`.
## Test di un errore di replica Aurora
Puoi simulare l'errore di una replica Aurora mediante la query fault injection `ALTER SYSTEM SIMULATE READ REPLICA FAILURE`.
Un errore di replica Aurora bloccha tutte le richieste da un'istanza di scrittura a una replica Aurora o tutte le repliche Aurora nel cluster di database per un periodo di tempo specificato. Al termine di tale periodo, le repliche Aurora interessate saranno automaticamente sincronizzate con l’istanza di scrittura.
### Sintassi
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT READ REPLICA FAILURE
2. [ TO ALL | TO "replica name" ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Opzioni
Questa query fault injection accetta i seguenti parametri:
+ **`percentage_of_failure`** — La percentuale di richieste da bloccare durante l'evento di errore. Può essere un valore tra 0 e 100. Se specifichi 0, non viene bloccata alcuna richiesta. Se specifichi 100, vengono bloccate tutte le richieste.
+ **Failure type (Tipo di errore)** — Il tipo di errore da simulare. Specifica `TO ALL` per simulare errori per tutte le repliche Aurora nel cluster di database. Specifica `TO` e il nome della replica Aurora per simulare un errore di un'unica replica Aurora. Il tipo di errore predefinito è `TO ALL`.
+ **`quantity`** — L'intervallo di tempo durante il quale simulare l'errore di replica di Aurora. L'intervallo è un numero seguito da un'unità di tempo. Il valore nell'unità specificata indica la durata della simulazione. Ad esempio, con `20 MINUTE` la simulazione durerà 20 minuti.
**Nota**
Fai attenzione quando specifichi l'intervallo di tempo per l'evento di errore della replica Aurora. Se specifichi un intervallo di tempo troppo lungo e l'istanza master scrive una grande quantità di dati durante l'evento di errore, il cluster di database Aurora potrebbe ritenere che si è verificato un arresto anomalo della replica Aurora e quindi sostituirla.
## Test di un errore del disco
Puoi simulare un errore del disco per un cluster database Aurora mediante la query fault injection `ALTER SYSTEM SIMULATE DISK FAILURE`.
Durante la simulazione di un errore del disco, il cluster di database Aurora contrassegna in modo aleatorio i segmenti del disco come difettosi. Le richieste a tali segmenti saranno bloccate per la durata della simulazione.
### Sintassi
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK FAILURE
2. [ IN DISK index | NODE index ]
3. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Opzioni
Questa query fault injection accetta i seguenti parametri:
+ **`percentage_of_failure`** — la percentuale del disco da contrassegnare come difettosa durante l'evento di errore. Può essere un valore tra 0 e 100. Se specifichi 0, nessuna parte del disco è contrassegnata come difettosa. Se specifichi 100, tutto il disco è contrassegnato come difettoso.
+ **`DISK index`** — uno specifico blocco di dati logico per il quale simulare l'evento di errore. Se viene superato l'intervallo di blocchi di dati logici disponibili, viene generato un errore indicante il valore di indice massimo che puoi specificare. Per ulteriori informazioni, consulta [Visualizzazione dello stato del volume per un cluster DB Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md).
+ **`NODE index`** — uno specifico nodo di storage per il quale simulare l'evento di errore. Se viene superato l'intervallo di nodi di storage disponibili, viene generato un errore indicante il valore di indice massimo che puoi specificare. Per ulteriori informazioni, consulta [Visualizzazione dello stato del volume per un cluster DB Aurora MySQL](AuroraMySQL.Managing.VolumeStatus.md).
+ **`quantity`** — l'intervallo di tempo durante il quale simulare l'errore del disco. L'intervallo è un numero seguito da un'unità di tempo. Il valore nell'unità specificata indica la durata della simulazione. Ad esempio, con `20 MINUTE` la simulazione durerà 20 minuti.
## Test di una congestione del disco
Puoi simulare un errore del disco per un cluster database Aurora mediante la query fault injection `ALTER SYSTEM SIMULATE DISK CONGESTION`.
Durante la simulazione della congestione del disco, il cluster di database Aurora contrassegna in modo aleatorio i segmenti del disco come congestionati. Le richieste a tali segmenti saranno ritardate di un periodo di tempo compreso tra il ritardo minimo e quello massimo specificati per la durata della simulazione.
### Sintassi
```
1. ALTER SYSTEM SIMULATE percentage_of_failure PERCENT DISK CONGESTION
2. BETWEEN minimum AND maximum MILLISECONDS
3. [ IN DISK index | NODE index ]
4. FOR INTERVAL quantity { YEAR | QUARTER | MONTH | WEEK | DAY | HOUR | MINUTE | SECOND };
```
### Opzioni
Questa query fault injection accetta i seguenti parametri:
+ **`percentage_of_failure`** — La percentuale del disco da contrassegnare come congestionata durante l'evento di errore. Può essere un valore tra 0 e 100. Se specifichi 0, nessuna parte del disco è contrassegnata come congestionata. Se specifichi 100, tutto il disco è contrassegnato come congestionato.
+ **`DISK index` o `NODE index`** — Uno specifico disco o nodo per il quale simulare l'evento di errore. Se viene superato l'intervallo di indici per il disco o il nodo, viene generato un errore indicante il valore di indice massimo che puoi specificare.
+ **`minimum` e `maximum`** — Il valore minimo e massimo del ritardo di congestione in millisecondi. I segmenti del disco contrassegnati come congestionati saranno ritardati per un periodo di tempo aleatorio compreso tra il valore minimo e quello massimo in millisecondi per la durata della simulazione.
+ **`quantity`** — L'intervallo di tempo durante il quale simulare la congestione del disco. L'intervallo è un numero seguito da un'unità di tempo. Il valore nell'unità specificata indica la durata della simulazione. Ad esempio, con `20 MINUTE` la simulazione durerà 20 minuti.
# Alterazione delle tabelle in Amazon Aurora mediante Fast DDL
Amazon Aurora include ottimizzazioni per eseguire un’operazione `ALTER TABLE` in atto, quasi istantaneamente. L'operazione viene eseguita senza la copia della tabella e senza impatto materiale sulle altre istruzioni DML. Poiché l'operazione non consuma storage temporaneo per la copia della tabella, rende le istruzioni DDL pratiche anche nel caso di tabelle di grandi dimensioni su tipi di classi small.
Aurora MySQL versione 3 è compatibile con la funzionalità MySQL 8.0 chiamata Instant DDL. Aurora MySQL versione 2 utilizza un'implementazione diversa chiamata Fast DDL.
**Topics**
+ [DDL istantaneo (Aurora MySQL versione 3)](#AuroraMySQL.mysql80-instant-ddl)
+ [Fast DDL (Aurora MySQL versione 2)](#AuroraMySQL.Managing.FastDDL-v2)
## DDL istantaneo (Aurora MySQL versione 3)
L'ottimizzazione eseguita da Aurora MySQL versione 3 per migliorare l'efficienza di alcune operazioni DDL è chiamata DDL istantaneo.
Aurora MySQL versione 3 è compatibile con il DDL istantaneo della community MySQL 8.0. Si esegue un'operazione DDL istantanea utilizzando la clausola `ALGORITHM=INSTANT` con l’istruzione `ALTER TABLE`. Per informazioni sulla sintassi e sull'utilizzo del DDL istantaneo, vedere [ALTER TABLE](https://dev.mysql.com/doc/refman/8.0/en/alter-table.html) e [Online DDL Operations](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html) (Operazioni DDL online) nella documentazione MySQL.
I seguenti esempi dimostrano la funzionalità DDL immediata. Le istruzioni `ALTER TABLE` aggiungono colonne e modificano i valori di default delle colonne. Gli esempi includono colonne regolari e virtuali e tabelle regolari e partizionate. In ogni fase, è possibile visualizzare i risultati emettendo `SHOW CREATE TABLE` e istruzioni `DESCRIBE`.
```
mysql> CREATE TABLE t1 (a INT, b INT, KEY(b)) PARTITION BY KEY(b) PARTITIONS 6;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t1 RENAME TO t2, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b SET DEFAULT 100, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.00 sec)
mysql> ALTER TABLE t2 ALTER COLUMN b DROP DEFAULT, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN c ENUM('a', 'b', 'c'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 MODIFY COLUMN c ENUM('a', 'b', 'c', 'd', 'e'), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> ALTER TABLE t2 ADD COLUMN (d INT GENERATED ALWAYS AS (a + 1) VIRTUAL), ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.02 sec)
mysql> ALTER TABLE t2 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t3 (a INT, b INT) PARTITION BY LIST(a)(
-> PARTITION mypart1 VALUES IN (1,3,5),
-> PARTITION MyPart2 VALUES IN (2,4,6)
-> );
Query OK, 0 rows affected (0.03 sec)
mysql> ALTER TABLE t3 ALTER COLUMN a SET DEFAULT 20, ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
mysql> CREATE TABLE t4 (a INT, b INT) PARTITION BY RANGE(a)
-> (PARTITION p0 VALUES LESS THAN(100), PARTITION p1 VALUES LESS THAN(1000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE);
Query OK, 0 rows affected (0.05 sec)
mysql> ALTER TABLE t4 ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
/* Sub-partitioning example */
mysql> CREATE TABLE ts (id INT, purchased DATE, a INT, b INT)
-> PARTITION BY RANGE( YEAR(purchased) )
-> SUBPARTITION BY HASH( TO_DAYS(purchased) )
-> SUBPARTITIONS 2 (
-> PARTITION p0 VALUES LESS THAN (1990),
-> PARTITION p1 VALUES LESS THAN (2000),
-> PARTITION p2 VALUES LESS THAN MAXVALUE
-> );
Query OK, 0 rows affected (0.10 sec)
mysql> ALTER TABLE ts ALTER COLUMN a SET DEFAULT 20,
-> ALTER COLUMN b SET DEFAULT 200, ALGORITHM = INSTANT;
Query OK, 0 rows affected (0.01 sec)
```
## Fast DDL (Aurora MySQL versione 2)
Fast DDL di Aurora MySQL è un’ottimizzazione progettata per migliorare le prestazioni di determinate modifiche allo schema, come l’aggiunta o l’eliminazione di colonne, riducendo i tempi di inattività e l’utilizzo delle risorse. Consente di completare queste operazioni in modo più efficiente rispetto ai metodi DDL tradizionali.
**Importante**
Attualmente, la modalità Lab di Aurora deve essere abilitata per utilizzare Fast DDL. Per ulteriori informazioni su come abilitare la modalità di laboratorio per , consulta [Modalità di laboratorio per Amazon Aurora MySQL](AuroraMySQL.Updates.LabMode.md).
L’ottimizzazione Fast DDL è stata inizialmente introdotta nella modalità Lab di Aurora MySQL versione 2 per migliorare l’efficienza di alcune operazioni DDL. In Aurora MySQL versione 3 la modalità Lab è stata rimossa e Fast DDL è stata sostituita dalla funzionalità Instant DDL di MySQL 8.0.
In MySQL, molte operazioni DDL (Data Definition Language) hanno un impatto considerevole sulle prestazioni.
Ad esempio, supponiamo che utilizzi un'operazione `ALTER TABLE` per aggiungere una colonna a una tabella. A seconda dell'algoritmo specificato per l'operazione, questa può comportare quanto segue:
+ Creazione di una copia completa della tabella
+ Creazione di una tabella temporanea per elaborare operazioni DML (Data Manipulation Language) simultanee
+ Ricostruzione di tutti gli indici per la tabella
+ Applicazione dei blocchi di tabelle durante l'applicazione di modifiche DML simultanee
+ Rallentamento del throughput DML simultaneo
Questo impatto sulle prestazioni può essere particolarmente complesso in ambienti con tabelle di grandi dimensioni o volumi di transazioni elevati. Fast DDL aiuta a mitigare queste sfide ottimizzando le modifiche allo schema, il che consente operazioni più rapide e meno dispendiose in termini di risorse.
### Limiti di Fast DDL
Fast DDL presenta attualmente le seguenti limitazioni:
+ Supporta solo l'aggiunta di una colonna nullable, senza valori predefiniti, alla fine di una tabella esistente.
+ La DDL veloce non funziona per le tabelle partizionate.
+ DDL rapida non funziona per le tabella InnoDB che utilizzano il formato riga REDUNDANT.
+ La DDL veloce non funziona per le tabelle con indici di ricerca full-text.
+ Se la dimensione di record massima possibile per l'operazione DDL è troppo grande, Fast DDL non viene utilizzato. Una dimensione di record è troppo importante se è più grande della metà della dimensione della pagina. La dimensione massima di un record viene calcolata sommando la dimensione massima di ogni colonna. Per le colonne di dimensione variabile, conformemente agli standard InnoDB, i byte extern non sono inclusi nel calcolo.
### Sintassi di Fast DDL
```
ALTER TABLE tbl_name ADD COLUMN col_name column_definition
```
Questa istruzione accetta le seguenti opzioni:
+ **`tbl_name` — **il nome della tabella da modificare.
+ **`col_name` — **il nome della colonna da aggiungere.
+ **`col_definition` — **la definizione della colonna da aggiungere.
**Nota**
Devi specificare una definizione di colonna nullable senza un valore predefinito. In caso contrario, Fast DDL non viene utilizzato.
### Esempi di Fast DDL
Negli esempi seguenti viene illustrata la velocità delle operazioni Fast DDL. Il primo esempio SQL esegue istruzioni `ALTER TABLE` su una tabella di grandi dimensioni senza utilizzare Fast DDL. Questa operazione richiede molto tempo. Un esempio della CLI mostra come abilitare Fast DDL per il cluster. Quindi un altro esempio SQL esegue le stesse istruzioni `ALTER TABLE` su una tabella identica. Con Fast DDL abilitato, l'operazione è molto veloce.
In questo esempio viene utilizzata la tabella `ORDERS` del benchmark TPC-H, contenente 150 milioni di righe. Questo cluster utilizza intenzionalmente una classe di istanza relativamente piccola, per dimostrare quanto tempo possano richiedere le istruzioni `ALTER TABLE` quando non è possibile utilizzare Fast DDL. Nell'esempio viene creato un clone della tabella originale contenente dati identici. Il controllo dell'impostazione `aurora_lab_mode` conferma che il cluster non può utilizzare Fast DDL poiché la modalità lab non è abilitata. Quindi le istruzioni `ALTER TABLE ADD COLUMN` richiedono molto tempo per aggiungere nuove colonne alla fine della tabella.
```
mysql> create table orders_regular_ddl like orders;
Query OK, 0 rows affected (0.06 sec)
mysql> insert into orders_regular_ddl select * from orders;
Query OK, 150000000 rows affected (1 hour 1 min 25.46 sec)
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 0 |
+-------------------+
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (40 min 31.41 sec)
mysql> ALTER TABLE orders_regular_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (40 min 44.45 sec)
```
Questo esempio esegue la stessa preparazione di una tabella di grandi dimensioni dell'esempio precedente. Tuttavia, non è possibile abilitare semplicemente la modalità lab all'interno di una sessione SQL interattiva. Tale impostazione deve essere abilitata in un gruppo di parametri personalizzato. Ciò richiede l'uscita dalla sessione `mysql` e l'esecuzione di alcuni comandi della CLI AWS o l'utilizzo della Console di gestione AWS.
```
mysql> create table orders_fast_ddl like orders;
Query OK, 0 rows affected (0.02 sec)
mysql> insert into orders_fast_ddl select * from orders;
Query OK, 150000000 rows affected (58 min 3.25 sec)
mysql> set aurora_lab_mode=1;
ERROR 1238 (HY000): Variable 'aurora_lab_mode' is a read only variable
```
Per abilitare la modalità lab per il cluster è necessario lavorare con un gruppo di parametri. In questo esempio della CLI AWS viene utilizzato un gruppo di parametri del cluster per garantire che tutte le istanze database nel cluster utilizzino lo stesso valore per l'impostazione della modalità lab.
```
$ aws rds create-db-cluster-parameter-group \
--db-parameter-group-family aurora5.7 \
--db-cluster-parameter-group-name lab-mode-enabled-57 --description 'TBD'
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].[ParameterName,ParameterValue]' \
--output text | grep aurora_lab_mode
aurora_lab_mode 0
$ aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--parameters ParameterName=aurora_lab_mode,ParameterValue=1,ApplyMethod=pending-reboot
{
"DBClusterParameterGroupName": "lab-mode-enabled-57"
}
# Assign the custom parameter group to the cluster that's going to use Fast DDL.
$ aws rds modify-db-cluster --db-cluster-identifier tpch100g \
--db-cluster-parameter-group-name lab-mode-enabled-57
{
"DBClusterIdentifier": "tpch100g",
"DBClusterParameterGroup": "lab-mode-enabled-57",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.10.2",
"Status": "available"
}
# Reboot the primary instance for the cluster tpch100g:
$ aws rds reboot-db-instance --db-instance-identifier instance-2020-12-22-5208
{
"DBInstanceIdentifier": "instance-2020-12-22-5208",
"DBInstanceStatus": "rebooting"
}
$ aws rds describe-db-clusters --db-cluster-identifier tpch100g \
--query '*[].[DBClusterParameterGroup]' --output text
lab-mode-enabled-57
$ aws rds describe-db-cluster-parameters \
--db-cluster-parameter-group-name lab-mode-enabled-57 \
--query '*[*].{ParameterName:ParameterName,ParameterValue:ParameterValue}' \
--output text | grep aurora_lab_mode
aurora_lab_mode 1
```
Nell'esempio seguente vengono illustrati i passaggi rimanenti dopo che la modifica del gruppo di parametri ha effetto. Si verifica l'impostazione `aurora_lab_mode` per assicurarsi che il cluster possa utilizzare Fast DDL. Quindi viene eseguita l'istruzione `ALTER TABLE` per aggiungere colonne alla fine di un'altra tabella di grandi dimensioni. Questa volta, le istruzioni vengono completate molto rapidamente.
```
mysql> select @@aurora_lab_mode;
+-------------------+
| @@aurora_lab_mode |
+-------------------+
| 1 |
+-------------------+
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_refunded boolean;
Query OK, 0 rows affected (1.51 sec)
mysql> ALTER TABLE orders_fast_ddl ADD COLUMN o_coverletter varchar(512);
Query OK, 0 rows affected (0.40 sec)
```
# Visualizzazione dello stato del volume per un cluster DB Aurora MySQL
In Amazon Aurora, un volume di cluster di database è costituito da una raccolta di blocchi logici. Ognuno di questi rappresenta 10 gigabyte di storage allocato. Questi blocchi sono denominati *gruppi di protezione*.
I dati in ogni gruppo di protezione sono replicati su sei dispositivi di storage fisico denominati *nodi di storage*. Questi nodi sono allocati su tre zone di disponibilità (AZ) nella regione AWS in cui si trova il cluster DB. Ogni nodo di storage contiene a sua volta uno o più blocchi di dati logici per il volume di cluster di database. Per ulteriori informazioni sui gruppi di protezione e i nodi di storage, consulta [Introduzione del motore di storage Aurora](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) nel blog AWS Database.
Puoi simulare l'errore di un intero nodo di storage o di un singolo blocco di dati logico in un nodo di storage. A questo proposito, devi utilizzare l'istruzione fault injection `ALTER SYSTEM SIMULATE DISK FAILURE`. Per l'istruzione, specifichi il valore di indice di uno specifico blocco di dati logico o nodo di storage. Tuttavia, se specifichi un valore di indice superiore al numero di blocchi di dati logici o nodi di storage utilizzati dal volume di cluster di database, l'istruzione restituisce un errore. Per ulteriori informazioni sulle query fault injection, consulta [Test di Amazon Aurora MySQL mediante query Fault Injection](AuroraMySQL.Managing.FaultInjectionQueries.md).
Puoi evitare tale errore utilizzando l'istruzione `SHOW VOLUME STATUS`. L'istruzione restituisce due variabili di stato del server, `Disks` e `Nodes`. Queste variabili rappresentano rispettivamente il numero totale di blocchi di dati logici e di nodi di storage per il volume di cluster di database.
## Sintassi
```
SHOW VOLUME STATUS
```
## Esempio
Il seguente esempio illustra un risultato SHOW VOLUME STATUS tipico.
```
mysql> SHOW VOLUME STATUS;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Disks | 96 |
| Nodes | 74 |
+---------------+-------+
```