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à.
# Migrazione di dati a un cluster di database Amazon Aurora MySQL
Hai diverse opzioni per migrare i dati da un database esistente a un cluster database Amazon Aurora MySQL. Le opzioni di migrazione dipendono anche dal database da cui esegui la migrazione e dalle dimensioni dei dati sottoposti a migrazione.
Ci sono due diversi tipi di migrazione: fisica e logica. La migrazione fisica significa che le copie fisiche dei file di database vengono utilizzate per migrare il database. La migrazione logica significa che la migrazione viene effettuata applicando modifiche di database logiche, come inserimenti, aggiornamenti ed eliminazioni.
La migrazione fisica ha i vantaggi seguenti:
+ La migrazione fisica è più veloce della migrazione logica, specialmente per database di grandi dimensioni.
+ Le prestazioni del database non ne risentono quando un backup viene utilizzato per la migrazione fisica.
+ La migrazione fisica può migrare tutto nel database origine, comprese componenti di database complesse.
La migrazione fisica ha i limiti seguenti:
+ Il parametro `innodb_page_size` deve essere impostato al valore predefinito (`16KB`).
+ Il parametro `innodb_data_file_path` deve essere configurato con un solo file di dati che utilizza il nome di file di dati predefinito `"ibdata1:12M:autoextend"`. I database con due file di dati o con un file di dati con un nome diverso non possono essere migrati utilizzando questo metodo.
Di seguito sono riportati esempi di nomi di file che non sono permessi: `"innodb_data_file_path=ibdata1:50M; ibdata2:50M:autoextend"` e `"innodb_data_file_path=ibdata01:50M:autoextend"`.
+ Il parametro `innodb_log_files_in_group` deve essere impostato al valore predefinito (`2`).
La migrazione logica ha i vantaggi seguenti:
+ Puoi migrare i sottoinsiemi del database, come tabelle specifiche o parti di una tabella.
+ I dati possono essere migrati indipendentemente dalla struttura fisica dello storage.
La migrazione logica ha i limiti seguenti:
+ La migrazione logica solitamente è più lenta della migrazione fisica.
+ I componenti di database complessi possono rallentare il processo di migrazione logica. In alcuni casi, i componenti di database complessi possono anche bloccare la migrazione logica.
La tabella seguente descrive le opzioni e il tipo di migrazione per ogni opzione.
| Migrazione da | Tipo di migrazione | Soluzione |
| --- | --- | --- |
| Un'istanza database RDS for MySQL | Fisica | Puoi eseguire la migrazione da un'istanza database RDS for MySQL creando prima di tutto una replica di lettura Aurora MySQL di un'istanza database MySQL. Quando il ritardo di replica tra un'istanza database MySQL e la replica di lettura Aurora MySQL è 0, puoi indirizzare le applicazioni del client a leggere dalla replica di lettura Aurora e poi interrompere la replica per rendere la replica di lettura Aurora MySQL un cluster di database standalone Aurora MySQL per lettura e scrittura. Per informazioni dettagliate, consulta [Migrazione di dati da un'istanza database RDS per MySQL a un cluster database Amazon Aurora MySQL utilizzando una replica di lettura Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md). |
| Una snapshot DB di RDS for MySQL | Fisica | Puoi migrare i dati direttamente da un RDS for MySQL snapshot DB a un cluster database Amazon Aurora MySQL. Per informazioni dettagliate, consultare [Migrazione di una snapshot RDS for MySQL a Aurora](AuroraMySQL.Migrating.RDSMySQL.Snapshot.md). |
| Un database MySQL esterno a Amazon RDS | Logica | Puoi creare un dump dei dati utilizzando l'utilità `mysqldump` e importare i dati in un cluster di database Amazon Aurora MySQL esistente. Per informazioni dettagliate, consultare [Migrazione logica da MySQL ad Amazon Aurora MySQL mediante mysqldump](AuroraMySQL.Migrating.ExtMySQL.mysqldump.md). Per esportare i metadati per gli utenti del database durante la migrazione da un database MySQL esterno, è possibile utilizzare anche il comando MySQL Shell anziché `mysqldump`. Per ulteriori informazioni, consulta [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html#mysql-shell-utilities-dump-about). L’utility [mysqlpump](https://dev.mysql.com/doc/refman/8.0/en/mysqlpump.html) è obsoleta a partire da MySQL 8.0.34. |
| Un database MySQL esterno a Amazon RDS | Fisica | Puoi copiare i file di backup dal database a un bucket Amazon Simple Storage Service (Amazon S3) e quindi ripristinare un cluster di database Amazon Aurora MySQL da tali file. Questa opzione può essere molto più rapida rispetto alla migrazione dei dati con `mysqldump`. Per informazioni dettagliate, consulta [Migrazione fisica da MySQL utilizzando XtraBackup Percona e Amazon S3](AuroraMySQL.Migrating.ExtMySQL.S3.md). |
| Un database MySQL esterno a Amazon RDS | Logica | Puoi salvare i dati dal database come file di testo e copiare tali file in un bucket Amazon S3. Puoi quindi caricare i dati in un cluster di database Aurora MySQL esistente utilizzando il comando MySQL `LOAD DATA FROM S3`. Per ulteriori informazioni, consulta [Caricamento dei dati in un cluster DB Amazon Aurora MySQL da file di testo in un bucket Amazon S3](AuroraMySQL.Integrating.LoadFromS3.md). |
| Un database non compatibile con MySQL | Logica | Puoi utilizzare AWS Database Migration Service (AWS DMS) per eseguire la migrazione dei dati da un database non compatibile con MySQL. Per ulteriori informazioni su AWS DMS, consulta [Che cos'è AWS Database Migration Service?](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) |
**Nota**
Se stai migrando un database MySQL esterno ad Amazon RDS, le opzioni di migrazione descritte nella tabella sono applicabili solo se il database supporta gli spazi tabelle InnoDB o MyISAM.
Se il database MySQL che stai migrando ad Aurora MySQL utilizza `memcached`, rimuovi `memcached` prima di eseguire la migrazione.
Non è possibile migrare ad Aurora MySQL 3.05 e versioni successive da alcune versioni precedenti di MySQL 8.0, tra cui 8.0.11, 8.0.13 e 8.0.15. Si consiglia di eseguire l'aggiornamento a MySQL 8.0.28 prima della migrazione.
# La migrazione di dati da un database MySQL esterno a un cluster database Amazon Aurora MySQL
Se il database supporta gli spazi tabelle InnoDB o MyISAM, hai queste opzioni per migrare i dati a un cluster database Amazon Aurora MySQL:
+ Puoi creare un dump dei dati utilizzando l'utilità `mysqldump` e importare i dati in un cluster di database Amazon Aurora MySQL esistente. Per ulteriori informazioni, consulta [Migrazione logica da MySQL ad Amazon Aurora MySQL mediante mysqldump](AuroraMySQL.Migrating.ExtMySQL.mysqldump.md).
+ Puoi copiare i file di backup completi e incrementali dal database a un bucket Amazon S3 ed eseguire il ripristino su un cluster database Amazon Aurora MySQL da tali file. Questa opzione può essere molto più rapida rispetto alla migrazione dei dati con `mysqldump`. Per ulteriori informazioni, consulta [Migrazione fisica da MySQL utilizzando XtraBackup Percona e Amazon S3](AuroraMySQL.Migrating.ExtMySQL.S3.md).
**Topics**
+ [Migrazione fisica da MySQL utilizzando XtraBackup Percona e Amazon S3](AuroraMySQL.Migrating.ExtMySQL.S3.md)
+ [Migrazione logica da MySQL ad Amazon Aurora MySQL mediante mysqldump](AuroraMySQL.Migrating.ExtMySQL.mysqldump.md)
# Migrazione fisica da MySQL utilizzando XtraBackup Percona e Amazon S3
Puoi copiare i file di backup completi e incrementali dal database MySQL versione 5.7 o 8.0 di origine a un bucket S3. Puoi quindi eseguire il ripristino in un cluster database Amazon Aurora MySQL con la stessa versione principale del motore d9 datahase da tali file.
Questa opzione può essere molto più veloce rispetto alla migrazione dei dati utilizzando `mysqldump`, in quanto l'utilizzo di `mysqldump` riproduce tutti i comandi per ricreare lo schema e i dati dal database di origine nel cluster di database Aurora MySQL. Copiando i file di dati MySQL origine, Aurora MySQL può immediatamente utilizzare quei file come dati per un cluster di database Aurora MySQL.
Puoi anche ridurre al minimo i tempi di inattività utilizzando la replica dei log binari durante il processo di migrazione. Se utilizzi la replica dei log binari, il database MySQL esterno rimane aperto per transazioni mentre i dati sono in fase di migrazione verso il cluster database Aurora MySQL. Dopo la creazione del cluster di database Aurora MySQL utilizza la replica dei log binari per sincronizzare il cluster di database Aurora MySQL con le transazioni avvenute dopo il backup. Quando il cluster di database Aurora MySQL è aggiornato con il database MySQL, la migrazione viene terminata passando completamente al cluster di database Aurora MySQL per le nuove transazioni. Per ulteriori informazioni, consulta [Sincronizzazione del cluster database Amazon Aurora MySQL con il database MySQL utilizzando la replica](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync).
**Contents**
+ [Considerazioni e limitazioni](#AuroraMySQL.Migrating.ExtMySQL.S3.Limits)
+ [Prima di iniziare](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs)
+ [Installazione di Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.XtraBackup)
+ [Autorizzazioni richieste](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.Permitting)
+ [Creazione del ruolo del servizio IAM](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.CreateRole)
+ [Esecuzione del backup di file da ripristinare come un cluster database Amazon Aurora MySQL](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup)
+ [Creazione di un backup completo con Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Full)
+ [Utilizzo di backup incrementali con Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Incr)
+ [Considerazioni sul backup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Considerations)
+ [Ripristino di un cluster di database Amazon Aurora MySQL da un bucket Amazon S3](#AuroraMySQL.Migrating.ExtMySQL.S3.Restore)
+ [Sincronizzazione del cluster database Amazon Aurora MySQL con il database MySQL utilizzando la replica](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync)
+ [Configurazione del database MySQL esterno e del cluster database Aurora MySQL per la replica crittografata](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.ConfigureEncryption)
+ [Sincronizza il cluster database Amazon Aurora MySQL con il database MySQL esterno](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.Synchronizing)
+ [Riduzione dei tempi di migrazione fisica ad Amazon Aurora MySQL](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md)
+ [Tipi di tabella non supportati](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Tables)
+ [Account utente con privilegi non supportati](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Users)
+ [Privilegi dinamici in Aurora MySQL versione 3](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Dynamic)
+ [Oggetti archiviati con 'rdsadmin'@'localhost' come definer](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Objects)
## Considerazioni e limitazioni
Le seguenti limitazioni e considerazioni si applicano al ripristino su un cluster database Amazon Aurora MySQL da un bucket Amazon S3:
+ Puoi eseguire la migrazione dei tuoi dati solo a un nuovo cluster database e non a un cluster database esistente.
+ È necessario utilizzare Percona per eseguire il backup dei dati XtraBackup su S3. Per ulteriori informazioni, consulta [Installazione di Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Prereqs.XtraBackup).
+ Il bucket Amazon S3 e il cluster Aurora MySQL DB devono trovarsi nella stessa regione. AWS
+ Non puoi eseguire il ripristino dai seguenti elementi:
+ Esportazione di uno snapshot cluster database in Amazon S3. Non è possibile eseguire la migrazione dei dati da un'esportazione snapshot del cluster database al bucket S3.
+ Un database di origine crittografato, ma puoi crittografare i dati migrati. Durante il processo di migrazione puoi anche lasciare i dati non crittografati.
+ Un database MySQL 5.5 o 5.6
+ Percona Server per MySQL non è supportato come database di origine, perché può contenere tabelle `compression_dictionary*` nello schema `mysql`.
+ Non è possibile eseguire il ripristino da un cluster database Aurora Serverless.
+ La migrazione alle versioni precedenti non è supportata per le versioni principali e secondarie. Ad esempio, non puoi eseguire la migrazione da MySQL versione 8.0 ad Aurora MySQL versione 2 (compatibile con MySQL 5.7), né da MySQL versione 8.0.32 ad Aurora MySQL versione 3.03, che è compatibile con la versione 8.0.26 della community MySQL.
+ Non è possibile migrare ad Aurora MySQL 3.05 e versioni successive da alcune versioni precedenti di MySQL 8.0, tra cui 8.0.11, 8.0.13 e 8.0.15. Si consiglia di eseguire l'aggiornamento a MySQL 8.0.28 prima della migrazione.
+ L'importazione da Amazon S3 non è supportata sulla classe di istanza database db.t2.micro. Tuttavia, puoi eseguire il ripristino in una classe istanza database diversa e modificare la classe di istanza in seguito. Per maggiori informazioni sulle classi di istanza database, consulta [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md).
+ Amazon S3 limita la dimensione del file caricato in un bucket S3 a 5 TB. Se un file di backup supera i 5 TB, devi dividerlo in file più piccoli.
+ Amazon RDS limita il numero di file caricati in un bucket S3 a 1 milione. Se i dati di backup del database, inclusi tutti i backup completi e incrementali, superano 1 milione di file, utilizza un file Gzip (.gz), tar (.tar.gz) o Percona xbstream (.xbstream) per archiviare i file dei backup completi e incrementali nel bucket S3. Percona XtraBackup 8.0 supporta solo Percona xbstream per la compressione.
+ Per fornire servizi di gestione per ogni cluster database, viene creato l'utente `rdsadmin` al momento della creazione del cluster database. Poiché si tratta di un utente riservato in RDS, si applicano le seguenti limitazioni:
+ Le funzioni, le procedure, le viste, gli eventi e i trigger con il definer `'rdsadmin'@'localhost'` non vengono importati. Per ulteriori informazioni, consultare [Oggetti archiviati con 'rdsadmin'@'localhost' come definer](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Objects) e [Privilegi dell'utente master con Amazon Aurora MySQL.](AuroraMySQL.Security.md#AuroraMySQL.Security.MasterUser).
+ Quando viene creato il cluster database Aurora MySQL, viene creato un utente master con i privilegi massimi supportati. Durante il ripristino dal backup, tutti i privilegi non supportati assegnati agli utenti importati vengono rimossi automaticamente durante l'importazione.
Per identificare gli utenti che potrebbero essere interessati da questo problema, consulta [Account utente con privilegi non supportati](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Users). Per ulteriori informazioni sui privilegi supportati in Aurora MySQL, consulta [Privilegio basato sui ruoli](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
+ Per la versione 3 di Aurora MySQL, i privilegi dinamici non vengono importati. I privilegi dinamici supportati da Aurora possono essere importati dopo la migrazione. Per ulteriori informazioni, consulta [Privilegi dinamici in Aurora MySQL versione 3](AuroraMySQL.Migrating.ExtMySQL.Prechecks.md#AuroraMySQL.Migrating.ExtMySQL.Prechecks.Dynamic).
+ Le tabelle create dall'utente nello schema `mysql` non viene migrato.
+ Il parametro `innodb_data_file_path` deve essere configurato con un solo file di dati che utilizza il nome di file di dati predefinito `ibdata1:12M:autoextend`. I database con due file di dati o con un file di dati con un nome diverso non possono essere migrati utilizzando questo metodo.
Di seguito sono riportati esempi di nomi di file non consentiti: `innodb_data_file_path=ibdata1:50M`, `ibdata2:50M:autoextend` e `innodb_data_file_path=ibdata01:50M:autoextend`.
+ Non puoi eseguire la migrazione da un database di origine con tabelle definite all'esterno della directory dei dati MySQL predefinita.
+ La dimensione massima supportata per i backup non compressi che utilizzano questo metodo è attualmente limitata a 64 TiB. Per i backup compressi, questo limite viene ridotto per tenere conto dei requisiti dello spazio di decompressione. In questi casi, la dimensione massima di backup supportata sarebbe è (`64 TiB – compressed backup size`).
+ Aurora MySQL non supporta l'importazione di MySQL e di altri componenti e plugin esterni.
+ Aurora MySQL non ripristina tutto dal database. È consigliabile salvare lo schema e i valori del database per i seguenti elementi dal database MySQL di origine e quindi aggiungerli al cluster database Aurora MySQL ripristinato dopo che è stato creato:
+ Account utenti
+ Funzioni
+ Procedure archiviate
+ Informazioni fuso orario. Le informazioni sul fuso orario vengono caricate dal sistema operativo locale per il cluster database Aurora MySQL. Per ulteriori informazioni, consulta [Fuso orario locale per i cluster DB Amazon Aurora](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone).
## Prima di iniziare
Prima di poter copiare i dati in un bucket Amazon S3 ed eseguire il ripristino in un cluster database da tali file, devi eseguire quanto segue:
+ Installa Percona sul tuo server locale XtraBackup .
+ Permetti a Aurora MySQL di accedere al bucket Amazon S3 per tuo conto.
### Installazione di Percona XtraBackup
Amazon Aurora può ripristinare un cluster DB da file creati utilizzando Percona. XtraBackup Puoi installare Percona XtraBackup da [Software Downloads](https://www.percona.com/downloads) - Percona.
Per la migrazione a MySQL 5.7, usa Percona 2.4. XtraBackup
Per la migrazione a MySQL 8.0, usa Percona 8.0. XtraBackup Assicurati che la versione di Percona sia compatibile con la XtraBackup versione del motore del tuo database di origine.
### Autorizzazioni richieste
Per migrare i dati MySQL in un cluster database Amazon Aurora MySQL, sono necessarie molte autorizzazioni:
+ L'utente che richiede ad Aurora di creare un nuovo cluster da un bucket Amazon S3 deve avere l'autorizzazione per elencare i bucket per il proprio account. AWS Concedi all'utente questa autorizzazione utilizzando una AWS Identity and Access Management policy (IAM).
+ Aurora richiede l'autorizzazione di agire per tuo conto per accedere al bucket Amazon S3 dove archivi i file utilizzati per creare il cluster di database Amazon Aurora MySQL. Concedi ad Aurora le autorizzazioni necessarie utilizzando un ruolo di servizio IAM.
+ L'utente che effettua la richiesta deve avere anche l'autorizzazione di elencare i ruoli IAM per l'account AWS .
+ Se l'utente che effettua la richiesta deve creare un ruolo di servizio IAM o richiedere che Aurora crei un ruolo di servizio IAM (utilizzando la console), l'utente deve avere l'autorizzazione di creare un ruolo IAM per l'account AWS .
+ Se prevedi di crittografare i dati durante il processo di migrazione, aggiorna la policy IAM dell'utente che eseguirà la migrazione per concedere l'accesso RDS all'utente AWS KMS keys utilizzato per la crittografia dei backup. Per istruzioni, consulta [Creazione di una policy IAM per accedere alle AWS KMS risorse](AuroraMySQL.Integrating.Authorizing.IAM.KMSCreatePolicy.md).
Ad esempio, la seguente policy IAM concede all'utente le autorizzazioni minime necessarie per utilizzare la console per elencare ruoli IAM, creare un ruolo IAM, elencare i bucket Amazon S3 per l'account ed elencare le chiavi KMS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:ListRoles",
"iam:CreateRole",
"iam:CreatePolicy",
"iam:AttachRolePolicy",
"s3:ListBucket",
"kms:ListKeys"
],
"Resource": "*"
}
]
}
```
------
Inoltre, affinché un utente associ un ruolo IAM a un bucket Amazon S3, l'utente IAM deve avere l'autorizzazione `iam:PassRole` per quel ruolo IAM. Quest'autorizzazione permette a un amministratore di limitare quali ruoli IAM un utente può associare a un bucket Amazon S3.
Ad esempio, la policy IAM permette a un utente di associare il ruolo denominato `S3Access` a un bucket Amazon S3.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowS3AccessRole",
"Effect":"Allow",
"Action":"iam:PassRole",
"Resource":"arn:aws:iam::123456789012:role/S3Access"
}
]
}
```
------
Per ulteriori informazioni sulle autorizzazioni utente IAM, consulta [Gestione dell’accesso tramite policy](UsingWithRDS.IAM.md#security_iam_access-manage).
### Creazione del ruolo del servizio IAM
Puoi Console di gestione AWS creare un ruolo per te scegliendo l'opzione **Crea un nuovo ruolo** (illustrata più avanti in questo argomento). Se selezioni questa opzione e specifichi un nome per il nuovo ruolo, Aurora crea il ruolo del servizio IAM necessario affinché Aurora acceda al bucket Amazon S3 con il nome che fornisci.
In alternativa, puoi creare manualmente il ruolo utilizzando la procedura seguente.
**Per creare un ruolo IAM affinché Aurora possa accedere a Amazon S3**
1. Completa le fasi descritte in [Creazione di una policy IAM per l'accesso alle risorse Amazon S3](AuroraMySQL.Integrating.Authorizing.IAM.S3CreatePolicy.md).
1. Completa le fasi descritte in [Creazione di un ruolo IAM per consentire ad Amazon Aurora di accedere ai servizi AWS](AuroraMySQL.Integrating.Authorizing.IAM.CreateRole.md).
1. Completa le fasi descritte in [Associazione di un ruolo IAM a un cluster DB Amazon Aurora MySQL](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md).
## Esecuzione del backup di file da ripristinare come un cluster database Amazon Aurora MySQL
Puoi creare un backup completo dei file del tuo database MySQL utilizzando XtraBackup Percona e caricare i file di backup su un bucket Amazon S3. In alternativa, se utilizzi già Percona XtraBackup per eseguire il backup dei file del tuo database MySQL, puoi caricare le directory e i file di backup completi e incrementali esistenti su un bucket Amazon S3.
**Topics**
+ [Creazione di un backup completo con Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Full)
+ [Utilizzo di backup incrementali con Percona XtraBackup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Incr)
+ [Considerazioni sul backup](#AuroraMySQL.Migrating.ExtMySQL.S3.Backup.Considerations)
### Creazione di un backup completo con Percona XtraBackup
Per creare un backup completo dei file del database MySQL che possono essere ripristinati da Amazon S3 per creare un cluster Aurora MySQL DB, utilizza l'utilità Percona () per eseguire il backup del database. XtraBackup `xtrabackup`
Ad esempio, il comando seguente consente di creare un backup di un database MySQL e memorizzare i file nella cartella `/on-premises/s3-restore/backup`.
```
xtrabackup --backup --user= --password= --target-dir=
```
Se desideri comprimere il backup in un singolo file (che può essere diviso, se necessario), puoi utilizzare l'opzione `--stream` per salvare il backup in uno dei seguenti formati:
+ Gzip (.gz)
+ tar (.tar)
+ Percona xbstream (.xbstream)
Il comando seguente consente di creare un backup del database MySQL diviso in più file Gzip.
```
xtrabackup --backup --user= --password= --stream=tar \
--target-dir= | gzip - | split -d --bytes=500MB \
- .tar.gz
```
Il comando seguente consente di creare un backup del database MySQL diviso in più file tar.
```
xtrabackup --backup --user= --password= --stream=tar \
--target-dir= | split -d --bytes=500MB \
- .tar
```
Il comando seguente consente di creare un backup del database MySQL diviso in più file xbstream.
```
xtrabackup --backup --user= --password= --stream=xbstream \
--target-dir= | split -d --bytes=500MB \
- .xbstream
```
**Nota**
Se viene visualizzato il seguente errore, potrebbe essere causato dalla combinazione di formati di file nel comando:
```
ERROR:/bin/tar: This does not look like a tar archive
```
Dopo aver eseguito il backup del database MySQL utilizzando l'utilità XtraBackup Percona, puoi copiare le directory e i file di backup in un bucket Amazon S3.
Per informazioni sulla creazione e il caricamento di un file in un bucket Amazon S3, consulta [Nozioni di base su Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html) nella *Guida alle operazioni di base di Amazon S3*.
### Utilizzo di backup incrementali con Percona XtraBackup
Amazon Aurora MySQL supporta backup completi e incrementali creati con Percona. XtraBackup Se utilizzi già Percona XtraBackup per eseguire backup completi e incrementali dei file del tuo database MySQL, non è necessario creare un backup completo e caricare i file di backup su Amazon S3. Puoi, invece, risparmiare tempo copiando le directory e i file di backup esistenti per i tuoi backup completi e incrementali in un bucket Amazon S3. Per ulteriori informazioni, consulta [Create an incremental backup](https://docs.percona.com/percona-xtrabackup/8.0/create-incremental-backup.html) (Creazione di un backup incrementale) sul sito Web di Percona.
Durante la copia dei file del backup completo e incrementale in un bucket Amazon S3, devi copiare in modo ricorsivo i contenuti della directory di base. Questi contenuti includono il backup completo e anche tutte le directory e i file del backup incrementale. Questa copia deve mantenere la struttura di directory nel bucket Amazon S3. Aurora esegue l'iterazione di tutti i file e le directory. Aurora usa il file `xtrabackup-checkpoints` incluso con ogni backup incrementale per identificare la directory di base e ordinare i backup incrementali in base all'intervallo dei numeri di sequenza log (LSN).
Per informazioni sulla creazione e il caricamento di un file in un bucket Amazon S3, consulta [Nozioni di base su Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html) nella *Guida alle operazioni di base di Amazon S3*.
### Considerazioni sul backup
Aurora non supporta i backup parziali creati utilizzando Percona. XtraBackup Non puoi usare le opzioni seguenti per creare un backup parziale quando esegui il backup dei file di origine per il database: `--tables`, `--tables-exclude`, `--tables-file`, `--databases`, `--databases-exclude` o `--databases-file`.
Per ulteriori informazioni sul backup del database con Percona XtraBackup, consulta Percona [ XtraBackup - Documentation and [Work with binary](https://docs.percona.com/percona-xtrabackup/8.0/working-with-binary-logs.html) logs sul sito Web di Percona](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html).
Aurora supporta i backup incrementali creati utilizzando Percona. XtraBackup Per ulteriori informazioni, consulta [Create an incremental backup](https://docs.percona.com/percona-xtrabackup/8.0/create-incremental-backup.html) (Creazione di un backup incrementale) sul sito Web di Percona.
Aurora consuma i file di backup in base al nome del file. Assicurati di assegnare un nome ai file di backup con l'estensione file appropriata in base al formato file,— ad esempio, `.xbstream` per i file archiviati utilizzando il formato Percona xbstream.
Aurora consuma i file di backup in ordine alfabetico e anche in ordine numerico naturale. Utilizza sempre l'opzione `split` quando invii il comando `xtrabackup` per assicurarti che i file di backup vengano scritti e denominati nell'ordine corretto.
Amazon S3 limita la dimensione del file caricato in un bucket Amazon S3 a 5 TB. Se i dati di backup per il database eccedono 5 TB, utilizza il comando `split` per suddividere i file di backup in file multipli che hanno meno di 5 TB ciascuno.
Aurora limita il numero di file di origine caricati in un bucket Amazon S3 a 1 milione di file. In alcuni casi, i dati di backup per il database, compresi i backup completi e incrementali, possono ammontare a un numero alto di file. In questi casi, utilizza un file tarball (.tar.gz) per archiviare i file di backup completi e incrementali in un bucket Amazon S3.
Quando carichi un file in un bucket Amazon S3, puoi utilizzare la crittografia lato server per crittografare i dati. Puoi ripristinare un cluster database Amazon Aurora MySQL da quei file crittografati. Amazon Aurora MySQL può ripristinare un cluster di database con file crittografati utilizzando i seguenti tipi di crittografia lato server:
+ Crittografia lato server con chiavi gestite da Amazon S3–, (SSE-S3): –ogni oggetto viene crittografato con una chiave unica che utilizza una crittografia avanzata a più fattori.
+ Crittografia lato server con chiavi AWS KMS gestite (SSE-KMS): simile a SSE-S3, ma è possibile creare e gestire autonomamente le chiavi di crittografia e altre differenze.
Per informazioni sull'utilizzo della crittografia lato server durante il caricamento di file in un bucket Amazon S3, consulta [Protezione dei dati con la crittografia lato server](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) nella *Guida per sviluppatori Amazon S3*.
## Ripristino di un cluster di database Amazon Aurora MySQL da un bucket Amazon S3
Puoi ripristinare i file di backup dal bucket Amazon S3 per creare un nuovo cluster di database Amazon Aurora MySQL utilizzando la console Amazon RDS.
**Per ripristinare un cluster di database Amazon Aurora MySQL da file in un bucket Amazon S3**
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. Nell'angolo in alto a destra della console Amazon RDS, scegli la AWS regione in cui creare il tuo cluster DB. Scegli la stessa AWS regione del bucket Amazon S3 che contiene il backup del database.
1. Nel riquadro di navigazione, scegliere **Databases (Database)** e **Restore from S3 (Ripristina da S3)**.
1. Seleziona **Ripristina da S3**.
Sarà visualizzata la pagina **Crea database ripristinando da S3** .
![\[La pagina in cui si specificano i dettagli per il ripristino di un cluster database da S3\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/AuroraMigrateS3_01.png)
1. In **Destinazione S3**:
1. Selezionare il **bucket S3** che contiene i file di backup.
1. (Facoltativo) Per **S3 folder path prefix (Prefisso percorso cartella S3)** inserire un prefisso del percorso per i file archiviati nel bucket Amazon S3.
Se non si specifica un prefisso, RDS crea l'istanza database utilizzando tutti i file e le cartelle nella cartella root del bucket S3. Se si specifica un prefisso, RDS crea l'istanza database utilizzando tutti i file e le cartelle nel bucket S3 in cui il percorso del file inizia con il prefisso specificato.
Ad esempio, si supponga di archiviare i file di backup su S3 in una sottocartella denominata backups e di disporre di più set di file di backup, ciascuno nella sua directory (gzip\$1backup1, gzip\$1backup2 e così via). In questo caso, specificare un prefisso di backups/gzip\$1backup1 per eseguire il ripristino dai file nella cartella gzip\$1backup1.
1. In **Opzioni motore**:
1. Per **Engine type (Tipo di motore)**, seleziona **Amazon Aurora**.
1. Per **Version (Versione)**, scegliere la versione del motore Aurora MySQL per l'istanza database ripristinata.
1. Per **Ruolo IAM**, puoi scegliere un ruolo IAM esistente.
1. (Facoltativo) Puoi anche creare un nuovo ruolo IAM selezionando **Crea un nuovo ruolo**. In tal caso:
1. Specifica il **nome del ruolo IAM**.
1. Specifica se **consentire l'accesso alla chiave KMS**:
+ Se non hai crittografato i file di backup, seleziona **No**.
+ Se hai crittografato i file di backup con AES-256 (SSE-S3) quando li hai caricati su Amazon S3, seleziona **No**. In questo caso, i dati vengono decrittati automaticamente.
+ **Se hai crittografato i file di backup con la crittografia lato server AWS KMS (SSE-KMS) quando li hai caricati su Amazon S3, scegli Sì.** In seguito, scegli la chiave corretta per **AWS KMS key**.
Console di gestione AWS Crea una policy IAM che consente ad Aurora di decrittografare i dati.
Per ulteriori informazioni, consulta [Protezione dei dati con la crittografia lato server](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html) nella *Guida per sviluppatori Amazon S3*.
1. Scegliere le impostazioni per il cluster database, ad esempio la configurazione dell'archiviazione del cluster database, la classe di istanza database, l'identificatore del cluster database e le credenziali di accesso. Per informazioni su ciascuna impostazione, consulta [Impostazioni per cluster di database Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings).
1. Personalizzare le impostazioni aggiuntive per il cluster database Aurora MySQL in base alle esigenze.
1. Scegliere **Create database (Crea database)** per avviare l'istanza database Aurora.
Nella console Amazon RDS la nuova istanza database viene visualizzata nell'elenco delle istanze database. L'istanza database rimane nello stato **creating (creazione in corso)** fino a quando non è stata creata e non è pronta per l'uso. Quando lo stato passa su **available (disponibile)**, puoi connetterti all'istanza principale per il cluster database. A seconda della classe di istanza database e dello store allocato, potrebbero trascorrere diversi minuti prima che la nuova istanza sia disponibile.
Per visualizzare il cluster appena creato, seleziona la visualizzazione **Databases (Database)** nella console Amazon RDS quindi seleziona il cluster di database. Per ulteriori informazioni, consulta [Visualizzazione di un cluster di database Amazon Aurora](accessing-monitoring.md#Aurora.Viewing).
![\[Amazon Aurora Elenco delle istanze database\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/AuroraLaunch04.png)
Prendi nota della porta e dell'endpoint di scrittura del cluster database. Utilizza la porta e l'endpoint di scrittura del cluster database nelle stringhe di connessione JDBC e ODBC per un'applicazione che esegue operazioni di scrittura o lettura.
## Sincronizzazione del cluster database Amazon Aurora MySQL con il database MySQL utilizzando la replica
Per fare in modo che ci sia poco o nessun tempo di inattività durante la migrazione, puoi replicare le transazioni eseguite sul database MySQL nel cluster database Aurora MySQL. La replica permette al cluster database di essere aggiornato con le transazioni nel database MySQL avvenute durante la migrazione. Quando il cluster database è completamente aggiornato, puoi fermare la replica e terminare la migrazione su Aurora MySQL.
**Topics**
+ [Configurazione del database MySQL esterno e del cluster database Aurora MySQL per la replica crittografata](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.ConfigureEncryption)
+ [Sincronizza il cluster database Amazon Aurora MySQL con il database MySQL esterno](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.Synchronizing)
### Configurazione del database MySQL esterno e del cluster database Aurora MySQL per la replica crittografata
Per replicare i dati in maniera sicura, puoi utilizzare la replica crittografata.
**Nota**
Se non hai bisogno di utilizzare la replica crittografata, puoi saltare queste fasi e passare alle istruzioni in [Sincronizza il cluster database Amazon Aurora MySQL con il database MySQL esterno](#AuroraMySQL.Migrating.ExtMySQL.S3.RepSync.Synchronizing).
Seguono i prerequisiti per l'utilizzo della replica crittografata:
+ Secure Sockets Layer (SSL) deve essere abilitato su un database primario MySQL esterno.
+ Una chiave e un certificato client devono essere preparati per il cluster database Aurora MySQL.
Durante la replica crittografata, il cluster di database Aurora MySQL agisce come un client per il server di database MySQL. I certificati e le chiavi per il client Aurora MySQL sono in file in formato .pem.
**Per configurare il database MySQL esterno e il cluster database Aurora MySQL per la replica crittografata**
1. Assicurati di essere preparato per la replica crittografata:
+ Se SSL non è abilitato sul database MySQL primario esterno e non disponi di una chiave client e di un certificato client preparato, abilita SSL sul server di database MySQL e genera la chiave client e il certificato client necessari.
+ Se SSL è abilitato sul primario esterno, fornisci un certificato e una chiave client per il cluster database Aurora MySQL. Se non disponi di questi elementi, genera una nuova chiave e un nuovo certificato per il cluster di database Aurora MySQL. Per firmare il certificato client, devi avere la chiave autorità certificato che hai utilizzato per configurare SSL nel database primario esterno MySQL.
Per ulteriori informazioni, consulta [Creating SSL Certificates and Keys Using openssl](https://dev.mysql.com/doc/refman/5.6/en/creating-ssl-files-using-openssl.html) nella documentazione MySQL.
Hai bisogno del certificato autorità certificato, della chiave client e del certificato client.
1. Esegui la connessione al cluster database Aurora MySQL come primario utilizzando SSL.
Per informazioni sulla connessione a un cluster di database Aurora MySQL con SSL, consulta [Connessioni TLS a cluster di database Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
1. Esegui la procedura archiviata [mysql.rds\$1import\$1binlog\$1ssl\$1material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material) per importare le informazioni SSL nel cluster di database Aurora MySQL.
Per il parametro `ssl_material_value` inserisci le informazioni dai file in formato .pem per il cluster di database Aurora MySQL nel payload JSON corretto.
L'esempio seguente importa le informazioni SSL in un cluster di database Aurora MySQL. Nei file in formato .pem, il codice del corpo è in genere più lungo del codice del corpo riportato nell'esempio.
```
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');
```
Per ulteriori informazioni, consultare [mysql.rds\$1import\$1binlog\$1ssl\$1material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material) e [Connessioni TLS a cluster di database Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
**Nota**
Dopo aver eseguito la procedura, i segreti vengono archiviati in file. Per eliminare i file in un secondo momento, puoi eseguire la stored procedure [mysql.rds\$1remove\$1binlog\$1ssl\$1material](mysql-stored-proc-replicating.md#mysql_rds_remove_binlog_ssl_material).
### Sincronizza il cluster database Amazon Aurora MySQL con il database MySQL esterno
Puoi sincronizzare i cluster database Amazon Aurora MySQL con il database MySQL utilizzando la replica.
**Per sincronizzare il cluster database Aurora MySQL con il database MySQL utilizzando la replica**
1. Assicurati che il file /etc/my.cnf per il database MySQL esterno abbia le voci rilevanti.
Se la replica crittografata non è necessaria, assicurati che il database MySQL esterno venga avviato con i bin binari (binlog) abilitati e SSL disabilitato. Seguono le voci rilevanti nel file /etc/my.cnf per dati crittografati.
```
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1
```
Se la replica crittografata è necessaria, assicurati che il database MySQL esterno venga avviato con SSL e i binlog abilitati. Le voci rilevanti nel file /etc/my.cnf includono le posizioni del file .pem per il server di database MySQL.
```
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1
# Setup SSL.
ssl-ca=/home/sslcerts/ca.pem
ssl-cert=/home/sslcerts/server-cert.pem
ssl-key=/home/sslcerts/server-key.pem
```
Puoi verificare l'abilitazione di SSL utilizzando il seguente comando.
```
mysql> show variables like 'have_ssl';
```
L'output deve essere simile a quanto segue.
```
+~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
| Variable_name | Value |
+~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
| have_ssl | YES |
+~-~-~-~-~-~-~-~-~-~-~-~-~-~--+~-~-~-~-~-~--+
1 row in set (0.00 sec)
```
1. Determina la posizione iniziale del log binario per la replica: Specifichi la posizione per avviare la replica in una fase successiva.
**Utilizzando il Console di gestione AWS**
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. Nel riquadro di navigazione selezionare **Events (Eventi)**.
1. Nell'elenco **Events (Eventi)**, annota la posizione nell'evento **Recovered from Binary log filename (Recuperato dal nome di file del log binario)**.
![\[Visualizza il primario MySQL\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-mysql-rep-binary-log-position.png)
**Utilizzando il AWS CLI**
È inoltre possibile ottenere il nome e la posizione del file binlog utilizzando il comando [AWS CLI describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html). Di seguito viene illustrato un esempio del comando `describe-events`.
```
PROMPT> aws rds describe-events
```
Nell'output, identifica l'evento che mostra la posizione del binlog.
1. Durante la connessione al database esterno MySQL, crea un utente da utilizzare per la replica. Questo account viene utilizzato unicamente per la replica e deve essere limitato al dominio personale per aumentare la sicurezza. Di seguito è riportato un esempio.
```
mysql> CREATE USER ''@'' IDENTIFIED BY '';
```
L'utente richiede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE`. Concedi questi privilegi all'utente.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO ''@'';
```
Se non hai bisogno di utilizzare la replica crittografata, richiedi le connessioni SSL per l'utente replica. Ad esempio, puoi usare la seguente istruzione per richiedere connessioni SSL per l'account utente ``.
```
GRANT USAGE ON *.* TO ''@'' REQUIRE SSL;
```
**Nota**
Se `REQUIRE SSL` non è incluso, la connessione di replica potrebbe ridiventare una connessione non crittografata.
1. Nella console Amazon RDS, aggiungi l'indirizzo IP del server che ospita il database MySQL esterno al gruppo di sicurezza VPC per il cluster di database Aurora MySQL. Per ulteriori informazioni sulla modifica di un gruppo di sicurezza VPC, consulta [Gruppi di sicurezza per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella *Guida per l'utente di Amazon Virtual Private Cloud*.
Potrebbe anche essere necessario configurare la rete locale per consentire le connessioni dall'indirizzo IP del cluster database Aurora MySQL, affinché possa comunicare con il database MySQL esterno. Per individuare l'indirizzo IP del cluster di database Aurora MySQL, utilizzare il comando `host`.
```
host
```
Il nome host è il nome DNS dell'endpoint del cluster di database Aurora MySQL.
1. Abilita la replica del log binario eseguendo la stored procedure [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versione 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) o [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source). Questa procedura archiviata ha la seguente sintassi.
```
CALL mysql.rds_set_external_master (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
CALL mysql.rds_set_external_source (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
Per informazioni sui parametri, consulta [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versione 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) e [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source).
Per `mysql_binary_log_file_name` e `mysql_binary_log_file_location`, utilizza la posizione nell'evento **Recovered from Binary log filename (Recuperato dal nome di file del log binario)** che hai annotato in precedenza.
Se i dati nel cluster di database Aurora MySQL non sono crittografati, il parametro `ssl_encryption` deve essere impostato su `0`. Se i dati sono crittografati, il parametro `ssl_encryption`, deve essere impostato su `1`.
L'esempio seguente esegue la procedura per un cluster database Aurora MySQL che ha dati crittografati.
```
CALL mysql.rds_set_external_master(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'password',
'mysql-bin.000010',
120,
1);
CALL mysql.rds_set_external_source(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'password',
'mysql-bin.000010',
120,
1);
```
Questa procedura archiviata imposta i parametri che il cluster database Aurora MySQL utilizza per la connessione al database MySQL esterno e per leggere il log binario. Se i dati sono crittografati, scarica anche il certificato autorità certificato SSL, il certificato client e la chiave client nel disco locale.
1. Avvia la replica del log binario eseguendo la procedura archiviata [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication).
```
CALL mysql.rds_start_replication;
```
1. Monitora quanto è indietro il cluster database Aurora MySQL rispetto al database primario MySQL di replica. A questo scopo, esegui la connessione al cluster database Aurora MySQL ed esegui il comando seguente.
```
Aurora MySQL version 2:
SHOW SLAVE STATUS;
Aurora MySQL version 3:
SHOW REPLICA STATUS;
```
Nell'output del comando, il campo `Seconds Behind Master` indica quanto è indietro il cluster database Aurora MySQL rispetto al primario MySQL. Quando questo valore corrisponde a `0` (zero), il cluster database Aurora MySQL è aggiornato rispetto al primario e puoi passare alla fase successiva per interrompere la replica.
1. Esegui la connessione al database primario MySQL di replica e interrompi la replica. Per eseguire questa operazione, chiama la stored procedure [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication).
```
CALL mysql.rds_stop_replication;
```
# Riduzione dei tempi di migrazione fisica ad Amazon Aurora MySQL
Puoi apportare le seguenti modifiche al database per velocizzare il processo di migrazione di un database ad Amazon Aurora MySQL.
**Importante**
Assicurati di eseguire questi aggiornamenti su una copia di un database di produzione, anziché sul database di produzione stesso. Puoi eseguire il backup della copia e quindi ripristinarlo nel cluster database Aurora MySQL per evitare interruzioni del servizio nel database di produzione.
## Tipi di tabella non supportati
Aurora MySQL supporta solo il motore InnoDB per le tabelle di database. Se il database include tabelle MyISAM, queste devono essere convertite prima della loro migrazione ad Aurora MySQL. Il processo di conversione richiede ulteriore spazio per la conversione da MyISAM a InnoDB durante la procedura di migrazione.
Per ridurre la possibilità di rimanere senza spazio o per velocizzare il processo di migrazione, converti tutte le tabelle MyISAM in tabelle InnoDB prima di migrarle. Le dimensioni della tabella InnoDB risultante è equivalente alle dimensioni necessarie da Aurora MySQL per quella tabella. Per convertire una tabella MyISAM in InnoDB, esegui il comando seguente:
```
ALTER TABLE schema.table_name engine=innodb, algorithm=copy;
```
Aurora MySQL non supporta le pagine o le tabelle compresse, ovvero le tabelle create con `ROW_FORMAT=COMPRESSED` o `COMPRESSION = {"zlib"|"lz4"}`.
Per ridurre la possibilità di rimanere senza spazio o per velocizzare il processo di migrazione, espandi le tabelle compresse impostando `ROW_FORMAT` su `DEFAULT`, `COMPACT`, `DYNAMIC`, o `REDUNDANT`. Per le pagine compresse, imposta `COMPRESSION="none"`.
Per ulteriori informazioni, consulta [InnoDB row formats](https://dev.mysql.com/doc/refman/8.0/en/innodb-row-format.html) e [InnoDB table and page compression](https://dev.mysql.com/doc/refman/8.0/en/innodb-compression.html) nella documentazione di MySQL.
Puoi utilizzare il seguente script SQL nell'istanza database MySQL esistente per elencare le tabelle nel database che sono tabelle MyISAM o compresse.
```
-- This script examines a MySQL database for conditions that block
-- migrating the database into Aurora MySQL.
-- It must be run from an account that has read permission for the
-- INFORMATION_SCHEMA database.
-- Verify that this is a supported version of MySQL.
select msg as `==> Checking current version of MySQL.`
from
(
select
'This script should be run on MySQL version 5.6 or higher. ' +
'Earlier versions are not supported.' as msg,
cast(substring_index(version(), '.', 1) as unsigned) * 100 +
cast(substring_index(substring_index(version(), '.', 2), '.', -1)
as unsigned)
as major_minor
) as T
where major_minor <> 506;
-- List MyISAM and compressed tables. Include the table size.
select concat(TABLE_SCHEMA, '.', TABLE_NAME) as `==> MyISAM or Compressed Tables`,
round(((data_length + index_length) / 1024 / 1024), 2) "Approx size (MB)"
from INFORMATION_SCHEMA.TABLES
where
ENGINE <> 'InnoDB'
and
(
-- User tables
TABLE_SCHEMA not in ('mysql', 'performance_schema',
'information_schema')
or
-- Non-standard system tables
(
TABLE_SCHEMA = 'mysql' and TABLE_NAME not in
(
'columns_priv', 'db', 'event', 'func', 'general_log',
'help_category', 'help_keyword', 'help_relation',
'help_topic', 'host', 'ndb_binlog_index', 'plugin',
'proc', 'procs_priv', 'proxies_priv', 'servers', 'slow_log',
'tables_priv', 'time_zone', 'time_zone_leap_second',
'time_zone_name', 'time_zone_transition',
'time_zone_transition_type', 'user'
)
)
)
or
(
-- Compressed tables
ROW_FORMAT = 'Compressed'
);
```
## Account utente con privilegi non supportati
Gli account utente con privilegi non supportati da Aurora MySQL vengono importati senza i privilegi non supportati. Per l'elenco dei privilegi supportati, consulta [Privilegio basato sui ruoli](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
Puoi eseguire la seguente query SQL sul database di origine per elencare gli account utente con privilegi non supportati.
```
SELECT
user,
host
FROM
mysql.user
WHERE
Shutdown_priv = 'y'
OR File_priv = 'y'
OR Super_priv = 'y'
OR Create_tablespace_priv = 'y';
```
## Privilegi dinamici in Aurora MySQL versione 3
I privilegi dinamici non vengono importati. Aurora MySQL versione 3 supporta i privilegi dinamici seguenti.
```
'APPLICATION_PASSWORD_ADMIN',
'CONNECTION_ADMIN',
'REPLICATION_APPLIER',
'ROLE_ADMIN',
'SESSION_VARIABLES_ADMIN',
'SET_USER_ID',
'XA_RECOVER_ADMIN'
```
Lo script di esempio seguente concede i privilegi dinamici supportati agli account utente nel cluster database Aurora MySQL.
```
-- This script finds the user accounts that have Aurora MySQL supported dynamic privileges
-- and grants them to corresponding user accounts in the Aurora MySQL DB cluster.
/home/ec2-user/opt/mysql/8.0.26/bin/mysql -uusername -pxxxxx -P8026 -h127.0.0.1 -BNe "SELECT
CONCAT('GRANT ', GRANTS, ' ON *.* TO ', GRANTEE ,';') AS grant_statement
FROM (select GRANTEE, group_concat(privilege_type) AS GRANTS FROM information_schema.user_privileges
WHERE privilege_type IN (
'APPLICATION_PASSWORD_ADMIN',
'CONNECTION_ADMIN',
'REPLICATION_APPLIER',
'ROLE_ADMIN',
'SESSION_VARIABLES_ADMIN',
'SET_USER_ID',
'XA_RECOVER_ADMIN')
AND GRANTEE NOT IN (\"'mysql.session'@'localhost'\",\"'mysql.infoschema'@'localhost'\",\"'mysql.sys'@'localhost'\") GROUP BY GRANTEE)
AS PRIVGRANTS; " | /home/ec2-user/opt/mysql/8.0.26/bin/mysql -u master_username -p master_password -h DB_cluster_endpoint
```
## Oggetti archiviati con 'rdsadmin'@'localhost' come definer
Le funzioni, le procedure, le viste, gli eventi e i trigger con `'rdsadmin'@'localhost'` come definer non vengono importati.
Puoi usare il seguente script SQL nel database MySQL di origine per elencare gli oggetti archiviati con il definire non supportato.
```
-- This SQL query lists routines with `rdsadmin`@`localhost` as the definer.
SELECT
ROUTINE_SCHEMA,
ROUTINE_NAME
FROM
information_schema.routines
WHERE
definer = 'rdsadmin@localhost';
-- This SQL query lists triggers with `rdsadmin`@`localhost` as the definer.
SELECT
TRIGGER_SCHEMA,
TRIGGER_NAME,
DEFINER
FROM
information_schema.triggers
WHERE
DEFINER = 'rdsadmin@localhost';
-- This SQL query lists events with `rdsadmin`@`localhost` as the definer.
SELECT
EVENT_SCHEMA,
EVENT_NAME
FROM
information_schema.events
WHERE
DEFINER = 'rdsadmin@localhost';
-- This SQL query lists views with `rdsadmin`@`localhost` as the definer.
SELECT
TABLE_SCHEMA,
TABLE_NAME
FROM
information_schema.views
WHERE
DEFINER = 'rdsadmin@localhost';
```
# Migrazione logica da MySQL ad Amazon Aurora MySQL mediante mysqldump
Poiché Amazon Aurora MySQL è un database compatibile con MySQL, puoi utilizzare l’utilità `mysqldump` per copiare i dati dal database MySQL oppure l’utilità `mariadb-dump` per copiare i dati dal database MariaDB database in un cluster di database Aurora MySQL esistente.
Per informazioni su come eseguire questa procedura con i database MySQL o MariaDB di dimensioni molto grandi, consulta i seguenti argomenti nella *Guida per l’utente di Amazon Relational Database Service*:
+ MySQL: [Importazione dei dati in un database Amazon RDS per MySQL con tempo di inattività ridotto](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html)
+ MariaDB: [Importazione dei dati in un database Amazon RDS per MariaDB con tempo di inattività ridotto](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mariadb-importing-data-reduced-downtime.html)
Per i database MySQL o MariaDB che contengono una quantità inferiore di dati, consulta i seguenti argomenti nella *Guida per l’utente di Amazon Relational Database Service*:
+ MySQL: [Importazione di dati da un database MySQL esterno in un’istanza database Amazon RDS per MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-external-database.html)
+ MariaDB: [Importazione di dati da un database MariaDB esterno in un’istanza database Amazon RDS per MariaDB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mariadb-importing-data-external-database.html)
# Migrazione dei dati da un'istanza database RDS per MySQL a un cluster di database Amazon Aurora MySQL
Puoi migrare (copiare) i dati a un cluster di database Amazon Aurora MySQL direttamente da un'istanza database RDS per MySQL.
**Topics**
+ [Migrazione di una snapshot RDS for MySQL a Aurora](AuroraMySQL.Migrating.RDSMySQL.Snapshot.md)
+ [Migrazione di dati da un'istanza database RDS per MySQL a un cluster database Amazon Aurora MySQL utilizzando una replica di lettura Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
**Nota**
Poiché Amazon Aurora MySQL è compatibile con MySQL, puoi migrare i dati dal database MySQL impostando la replica tra il database MySQL e un cluster di database Amazon Aurora MySQL. Per ulteriori informazioni, consulta [Replica con Amazon Aurora](Aurora.Replication.md).
# Migrazione di una snapshot RDS for MySQL a Aurora
Puoi effettuare la migrazione di uno snapshot DB di un'istanza database RDS for MySQL per creare un cluster database Aurora MySQL. Il nuovo cluster DB Aurora MySQL viene popolato con i dati dall'istanza database RDS for MySQL originale. Lo snapshot di database deve essere realizzato da un'istanza database Amazon RDS che esegue MySQL compatibile con Aurora MySQL.
Puoi effettuare la migrazione di una snapshot DB manuale o automatizzata. Dopo aver creato il cluster database, puoi le creare le repliche Aurora facoltative.
**Nota**
Puoi anche migrare un'istanza database RDS per MySQL a un cluster di database Aurora MySQL creando una replica di lettura Aurora dell'istanza database RDS per MySQL di origine. Per ulteriori informazioni, consulta [Migrazione di dati da un'istanza database RDS per MySQL a un cluster database Amazon Aurora MySQL utilizzando una replica di lettura Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md).
Non è possibile migrare ad Aurora MySQL 3.05 e versioni successive da alcune versioni precedenti di MySQL 8.0, tra cui 8.0.11, 8.0.13 e 8.0.15. Si consiglia di eseguire l'aggiornamento a MySQL 8.0.28 prima della migrazione.
La procedura generale da seguire è riportata di seguito:
1. Determina la quantità di spazio da predisporre per il cluster database Aurora MySQL. Per ulteriori informazioni, consulta [Di quanto spazio ho bisogno?](#AuroraMySQL.Migrating.RDSMySQL.Space)
1. Usa la console per creare lo snapshot nella AWS regione in cui si trova l'istanza Amazon RDS MySQL. Per informazioni sulla creazione di uno snapshot DB, consulta [Creazione di uno snapshot DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html).
1. Se lo snapshot DB non si trova nella stessa AWS regione del cluster DB, usa la console Amazon RDS per copiare lo snapshot DB in quella regione. AWS Per informazioni sulla copia di una snapshot DB, consulta [Copia di una snapshot DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html).
1. Utilizza la console per migrare la snapshot DB e creare un cluster database Aurora MySQL con gli stessi database dell'istanza database MySQL originale.
**avvertimento**
Amazon RDS limita ogni AWS account a una copia istantanea in ciascuna AWS regione alla volta.
## Di quanto spazio ho bisogno?
Quando effettui la migrazione di una snapshot di un'istanza database MySQL in un cluster di database Aurora MySQL, Aurora utilizza un volume Amazon Elastic Block Store (Amazon EBS) per formattare i dati dalla snapshot prima della migrazione. In alcuni casi, è necessario ulteriore spazio per formattare i dati per la migrazione.
Le tabelle che non sono tabelle MyISAM e non sono compresse possono avere 16 TB di dimensioni. Se hai tabelle MyISAM, Aurora deve utilizzare ulteriori spazio nel volume per convertire le tabelle in modo che siano compatibili con Aurora MySQL. Se hai tabelle compresse, Aurora deve utilizzare ulteriore spazio nel volume per espandere queste tabelle prima di archiviarle nel volume cluster Aurora. A causa dei requisiti di spazio aggiuntivo, devi accertarti che nessuna delle tabelle MyISAM e compresse migrate dall'istanza database MySQL abbia una dimensione superiore a 8 TB.
## Riduzione della quantità di spazio necessaria per migrare i dati in Amazon Aurora MySQL
Potrebbe essere necessario modificare lo schema del database prima di migrarlo in Amazon Aurora. Tale modifica può essere utile nei casi seguenti:
+ Desideri accelerare il processo di migrazione.
+ Non sai con precisione di quanto spazio necessiti.
+ Hai provato a effettuare la migrazione dei dati ma la migrazione non è andata a buon fine per insufficienza di spazio.
Puoi applicare le seguenti modifiche per migliorare il processo di migrazione di un database in Amazon Aurora.
**Importante**
Accertati di eseguire questi aggiornamenti in una nuova istanza database recuperata da una snapshot di un database di produzione, piuttosto che su un'istanza di produzione. Puoi migrare i dati dalla snapshot della nuova istanza database nel cluster database Aurora per evitare interruzioni di servizio nel database di produzione.
| Tipo tabella | Limite o linea guida |
| --- | --- |
| Tabelle MyISAM | Aurora MySQL supporta solo tabelle InnoDB. Se hai tabelle MyISAM nel database, devono essere convertite prima di essere migrate in Aurora MySQL. Il processo di conversione richiede ulteriore spazio per la conversione da MyISAM a InnoDB durante la procedura di migrazione. Per ridurre la possibilità di rimanere senza spazio o per velocizzare il processo di migrazione, converti tutte le tabelle MyISAM in tabelle InnoDB prima di migrarle. Le dimensioni della tabella InnoDB risultante è equivalente alle dimensioni necessarie da Aurora MySQL per quella tabella. Per convertire una tabella MyISAM in InnoDB, esegui il comando seguente: `alter table . engine=innodb, algorithm=copy;` |
| Tabelle compresse | Aurora MySQL non supporta tabelle compresse (ovvero tabelle create con `ROW_FORMAT=COMPRESSED`). Per ridurre la possibilità di rimanere senza spazio o per velocizzare il processo di migrazione, espandi le tabelle compresse impostando `ROW_FORMAT` su `DEFAULT`, `COMPACT`, `DYNAMIC`, o `REDUNDANT`. Per ulteriori informazioni, consulta [Formati di riga in InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-row-format.html) nella documentazione di MySQL. |
Puoi utilizzare il seguente script SQL nell'istanza database MySQL esistente per elencare le tabelle nel database che sono tabelle MyISAM o compresse.
```
-- This script examines a MySQL database for conditions that block
-- migrating the database into Amazon Aurora.
-- It needs to be run from an account that has read permission for the
-- INFORMATION_SCHEMA database.
-- Verify that this is a supported version of MySQL.
select msg as `==> Checking current version of MySQL.`
from
(
select
'This script should be run on MySQL version 5.6 or higher. ' +
'Earlier versions are not supported.' as msg,
cast(substring_index(version(), '.', 1) as unsigned) * 100 +
cast(substring_index(substring_index(version(), '.', 2), '.', -1)
as unsigned)
as major_minor
) as T
where major_minor <> 506;
-- List MyISAM and compressed tables. Include the table size.
select concat(TABLE_SCHEMA, '.', TABLE_NAME) as `==> MyISAM or Compressed Tables`,
round(((data_length + index_length) / 1024 / 1024), 2) "Approx size (MB)"
from INFORMATION_SCHEMA.TABLES
where
ENGINE <> 'InnoDB'
and
(
-- User tables
TABLE_SCHEMA not in ('mysql', 'performance_schema',
'information_schema')
or
-- Non-standard system tables
(
TABLE_SCHEMA = 'mysql' and TABLE_NAME not in
(
'columns_priv', 'db', 'event', 'func', 'general_log',
'help_category', 'help_keyword', 'help_relation',
'help_topic', 'host', 'ndb_binlog_index', 'plugin',
'proc', 'procs_priv', 'proxies_priv', 'servers', 'slow_log',
'tables_priv', 'time_zone', 'time_zone_leap_second',
'time_zone_name', 'time_zone_transition',
'time_zone_transition_type', 'user'
)
)
)
or
(
-- Compressed tables
ROW_FORMAT = 'Compressed'
);
```
Lo script produce output simile all'output nell'esempio seguente. L'esempio visualizza due tabelle che devono essere convertite da MyISAM a InnoDB. L'output include anche le dimensioni approssimative di ogni tabella in megabyte (MB).
```
+---------------------------------+------------------+
| ==> MyISAM or Compressed Tables | Approx size (MB) |
+---------------------------------+------------------+
| test.name_table | 2102.25 |
| test.my_table | 65.25 |
+---------------------------------+------------------+
2 rows in set (0.01 sec)
```
## Migrazione di uno snapshot DB di RDS per MySQL in un cluster database Aurora MySQL
È possibile migrare uno snapshot DB di un'istanza DB RDS for MySQL per creare un cluster Aurora MySQL DB utilizzando o il. Console di gestione AWS AWS CLI Il nuovo cluster DB Aurora MySQL viene popolato con i dati dall'istanza database RDS for MySQL originale. Per informazioni sulla creazione di uno snapshot DB, consulta [Creazione di uno snapshot DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html).
Se lo snapshot DB non si trova nella AWS regione in cui desideri collocare i dati, copia lo snapshot DB in quella regione. AWS Per informazioni sulla copia di una snapshot DB, consulta [Copia di una snapshot DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html).
### Console
Quando migri lo snapshot DB utilizzando Console di gestione AWS, la console esegue le azioni necessarie per creare solo il cluster DB.
Puoi decidere anche che il nuovo cluster DB Aurora MySQL venga crittografato a riposo utilizzando una AWS KMS key.
**Per migrare uno snapshot MySQL DB utilizzando il Console di gestione AWS**
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. Inizia la migrazione dall'istanza database MySQL o dalla snapshot:
Per iniziare la migrazione dall'istanza database:
1. Nel riquadro di navigazione, seleziona **Databases (Database)**, quindi seleziona l'istanza database MySQL.
1. In **Actions (Operazioni)** scegliere **Migrate latest snapshot (Migrazione snapshot più recente)**.
Per iniziare la migrazione dalla snapshot:
1. Selezionare**Snapshots (Snapshot)**.
1. Nella pagina **Snapshots (Snapshot)** seleziona la snapshot che desideri migrare in un cluster di database Aurora MySQL.
1. Scegliere **Snapshot Actions (Operazioni snapshot)**, quindi scegliere **Migrate Snapshot (Migrazione snapshot)**.
Viene visualizzata la pagina **Migrate Database (Migrazione database)**.
1. Impostare i valori seguenti nella pagina **Migrate Database (Migra database)**:
+ **Migrate to DB Engine (Migrazione al motore DB)**: seleziona `aurora`.
+ **DB Engine Version (Versione motore database)**: seleziona la versione di motore database per il cluster di database Aurora MySQL.
+ **Classe di istanza database**: scegliere una classe dell'istanza database che abbia lo spazio di archiviazione e la capacità richiesti per il database, ad esempio `db.r3.large`. I volumi dei cluster Aurora aumentano automaticamente quando aumenta la quantità di dati nel database. Un volume del cluster Aurora può raggiungere una dimensione massima di 128 tebibytes (TiB). È quindi sufficiente selezionare una classe di istanza database che soddisfi i requisiti di storage correnti. Per ulteriori informazioni, consulta [Panoramica dell'archiviazione di Amazon Aurora](Aurora.Overview.StorageReliability.md#Aurora.Overview.Storage).
+ **Identificatore dell'istanza DB**: digita un nome per il cluster DB che sia univoco per il tuo account nella AWS regione selezionata. Questo identificatore viene utilizzato negli indirizzi degli endpoint per le istanze nel cluster di database. Potresti scegliere di aggiungere alcune informazioni al nome, ad esempio includendo la AWS regione e il motore DB selezionati. **aurora-cluster1**
L'identificatore istanze database presenta i seguenti vincoli:
+ Deve contenere da 1 a 63 caratteri alfanumerici o trattini.
+ Il primo carattere deve essere una lettera.
+ Non può terminare con un trattino o contenere due trattini consecutivi.
+ Deve essere univoco per tutte le istanze DB per AWS account e per AWS regione.
+ **Virtual Private Cloud (VPC)**: se hai già un VPC esistente, puoi utilizzarlo con il cluster di database Aurora MySQL selezionando l'identificatore VPC, ad esempio `vpc-a464d1c1`. Per ulteriori informazioni sulla creazione di un VPC, consulta [Tutorial: crea un VPC da utilizzare con un cluster di DB (solo) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md).
Diversamente, puoi stabilire che Aurora crei un VPC per te selezionando **Create a new VPC (Crea un nuovo VPC)**.
+ **DB subnet group** (Gruppo di sottoreti DB): un gruppo di sottoreti esistente può essere utilizzato con il cluster database Aurora MySQL selezionando l'identificatore del gruppo di sottoreti, ad esempio `gs-subnet-group1`.
Diversamente, puoi stabilire che Aurora crei un gruppo di sottoreti selezionando **Create a new subnet group (Crea nuovo gruppo di sottoreti)**.
+ **Public accessibility (Accesso pubblico)**: seleziona **No (No)** per specificare che le istanze nel cluster database si possono accedere solamente da risorse all'interno del proprio VPC. Selezionare **Yes (Si)** per specificare che le istanze nel cluster database sono accessibili dalle risorse nella rete pubblica. Il valore predefinito è **Yes (Sì)**.
**Nota**
Il cluster DB di produzione potrebbe non trovarsi in una sottorete pubblica, poiché solo i server applicativi richiedono l'accesso al cluster DB. Se non è necessario che il cluster database si trovi in una sottorete pubblica, impostare **Publicly Accessible (Accessibile pubblicamente)** su **No**.
+ **Availability Zone (Zona di disponibilità)**: seleziona la zona di disponibilità per ospitare l'istanza primaria per il cluster di database Aurora MySQL. Per permettere a Aurora di selezionare automaticamente una zona di disponibilità, seleziona **No Preference (Nessuna preferenza)**.
+ **Database Port (Porta database)**: digita la porta predefinita da usare quando si effettua la connessione a istanze nel cluster di database Aurora MySQL. Il valore di default è `3306`.
**Nota**
Potrebbe essere attivo un firewall aziendale che non permette l'accesso alle porte predefinite come la porta predefinita di MySQL 3306. In questo caso, fornire un valore di porta permesso dal firewall aziendale. Ricorda il valore di porta per utilizzarlo successivamente, al momento della connessione al cluster di database Aurora MySQL.
+ **Encryption (Crittografia)**: seleziona **Enable Encryption (Abilita crittografia)** perché il nuovo cluster di database Aurora MySQL venga crittografato mentre è inattivo. Se scegli **Enable Encryption (Abilita crittografia)**, devi scegliere una chiave KMS come valore **AWS KMS key**.
Se la snapshot DB non è crittografata, specifica una chiave di crittografia per fare in modo che il cluster database sia crittografato mentre è inattivo.
Se la snapshot DB è crittografata, specifica una chiave di crittografia per fare in modo che il cluster database sia crittografato mentre è inattivo utilizzando la chiave di crittografia specificata. Puoi specificare la chiave di crittografia utilizzata dalla snapshot DB o una chiave diversa. Non puoi creare un cluster database non crittografato da una snapshot DB crittografata.
+ **Aggiornamento automatico della versione secondaria**: questa impostazione non si applica ai cluster di database Aurora MySQL.
Per ulteriori informazioni sugli aggiornamenti del motore per Aurora MySQL, consultare [Aggiornamenti del motore del database per Amazon Aurora MySQLVersioni beta e con supporto a lungo termine (LTS, Long-Term Support) di Amazon Aurora MySQL](AuroraMySQL.Updates.md).
1. Selezionare **Migrate (Migra)** per effettuare la migrazione della snapshot DB.
1. Selezionare **Instances (Istanze)** e quindi l'icona con la freccia per visualizzare i dettagli del cluster DB e monitorare l'avanzamento della migrazione. Nella pagina dei dettagli, puoi trovare l'endpoint del cluster utilizzato per la connessione all'istanza principale del cluster DB. Per ulteriori informazioni sulla connessione a un cluster di database Aurora MySQL, consulta [Connessione a un cluster database Amazon Aurora](Aurora.Connecting.md).
### AWS CLI
Puoi creare un cluster database Aurora da uno snapshot DB di una istanza database RDS for MySQL utilizzando il comando [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-snapshot.html) con i seguenti parametri:
+ `--db-cluster-identifier`: nome del cluster di database da creare.
+ `--engine aurora-mysql`: per un cluster di database compatibile con MySQL 5.7 o 8.0.
+ `--kms-key-id`— Con cui AWS KMS key crittografare facoltativamente il cluster DB, a seconda che lo snapshot del DB sia crittografato.
+ Se la snapshot DB non è crittografata, specifica una chiave di crittografia per fare in modo che il cluster database sia crittografato mentre è inattivo. Altrimenti, il cluster database non è crittografato.
+ Se la snapshot DB è crittografata, specifica una chiave di crittografia per fare in modo che il cluster database sia crittografato mentre è inattivo utilizzando la chiave di crittografia specificata. Altrimenti, il cluster database è crittografato mentre è inattivo utilizzando la chiave di crittografia per la snapshot DB.
**Nota**
Non puoi creare un cluster database non crittografato da una snapshot DB crittografata.
+ `--snapshot-identifier`: l'Amazon Resource Name (ARN) dello snapshot DB da migrare. Per ulteriori informazioni su Amazon RDS ARNs, consulta [Amazon Relational Database Service (Amazon](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-rds) RDS).
Quando migri la snapshot DB utilizzando il comando `RestoreDBClusterFromSnapshot`, il comando crea sia il cluster database sia l'istanza primaria.
In questo esempio, si crea un cluster DB compatibile con MySQL 5.7 *mydbcluster* denominato da un'istantanea DB con un ARN impostato su. *mydbsnapshotARN*
Per Linux, macOS o Unix:
```
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier mydbcluster \
--snapshot-identifier mydbsnapshotARN \
--engine aurora-mysql
```
Per Windows:
```
aws rds restore-db-cluster-from-snapshot ^
--db-cluster-identifier mydbcluster ^
--snapshot-identifier mydbsnapshotARN ^
--engine aurora-mysql
```
In questo esempio, si crea un cluster DB compatibile con MySQL 5.7 *mydbcluster* denominato da un'istantanea DB con un ARN impostato su. *mydbsnapshotARN*
Per Linux, macOS o Unix:
```
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier mydbcluster \
--snapshot-identifier mydbsnapshotARN \
--engine aurora-mysql
```
Per Windows:
```
aws rds restore-db-cluster-from-snapshot ^
--db-cluster-identifier mydbcluster ^
--snapshot-identifier mydbsnapshotARN ^
--engine aurora-mysql
```
# Migrazione di dati da un'istanza database RDS per MySQL a un cluster database Amazon Aurora MySQL utilizzando una replica di lettura Aurora
Aurora utilizza la funzionalità di replica dei log binari del motore di database MySQL per creare un tipo speciale di database cluster chiamato replica di lettura Aurora per un'istanza database RDS per MySQL di origine. Gli aggiornamenti effettuati sull'istanza database RDS per MySQL di origine vengono replicati in modo asincrono nella replica di lettura Aurora.
Consigliamo di utilizzare questa funzionalità per eseguire la migrazione da un'istanza database RDS per MySQL a un cluster database Aurora MySQL creando una replica di lettura Aurora dell'istanza database MySQL di origine. Quando il ritardo di replica tra un'istanza database RDS per MySQL e la replica di lettura Aurora è 0, puoi indirizzare le applicazioni client alla replica di lettura Aurora e poi arrestare la replica per rendere la replica di lettura Aurora un cluster database Aurora MySQL standalone. La migrazione potrebbe richiedere del tempo, circa diverse ore per tebibyte (TiB) di dati.
Per l'elenco delle regioni in cui è disponibile Aurora, consulta [Amazon Aurora](https://docs.aws.amazon.com/general/latest/gr/rande.html#aurora) in *Riferimenti generali di AWS*.
Quando crei una replica di lettura Aurora di un'istanza database RDS per MySQL, Amazon RDS crea uno snapshot database dell'istanza database RDS per MySQL di origine (privata per Amazon RDS e senza addebiti). Amazon RDS in seguito migra i dati dallo snapshot DB alla replica di lettura Aurora. Dopo che i dati dello snapshot database sono stati migrati al nuovo cluster database Aurora MySQL, Amazon RDS avvia la replica tra l'istanza database RDS per MySQL e il cluster database Aurora MySQL. Se l'istanza database RDS per MySQL contiene tabelle che utilizzano motori di archiviazione diversi da InnoDB o che utilizzano il formato di riga compresso, puoi velocizzare il processo di creazione di una replica di lettura Aurora modificando le tabelle in modo che vengano utilizzati il motore di archiviazione InnoDB e il formato di riga dinamico prima di creare la replica di lettura Aurora. Per ulteriori informazioni sul processo di copia di una snapshot di database MySQL in un cluster di database Aurora MySQL, consulta [Migrazione dei dati da un'istanza database RDS per MySQL a un cluster di database Amazon Aurora MySQL](AuroraMySQL.Migrating.RDSMySQL.md).
Puoi avere una sola replica di lettura Aurora per un'istanza database RDS per MySQL.
**Nota**
Possono verificarsi problemi di replica a causa delle differenze di funzionalità tra Aurora MySQL e la versione del motore di database MySQL dell'istanza database RDS per MySQL, ossia l'istanza di replica primaria. Se riscontri un errore, puoi trovare assistenza nel [forum della community di Amazon RDS](https://forums.aws.amazon.com/forum.jspa?forumID=60) o Supporto AWS contattando.
Non puoi creare una replica di lettura Aurora se l'istanza database RDS per MySQL è già l'origine di una replica di lettura tra regioni.
Non è possibile migrare ad Aurora MySQL 3.05 e versioni successive da alcune versioni precedenti di RDS per MySQL 8.0, tra cui 8.0.11, 8.0.13 e 8.0.15. Si consiglia di eseguire l'aggiornamento a RDS per MySQL versione 8.0.28 prima della migrazione.
Per ulteriori informazioni sulle repliche di lettura MySQL, consulta la sezione relativa all'[uso di repliche di lettura con istanze database di MariaDB, MySQL e PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html).
## Creazione di una replica di lettura Aurora
È possibile creare una replica di lettura Aurora per un'istanza DB RDS for MySQL utilizzando la console, l'o l'API RDS. AWS CLI
### Console
**Creazione di una replica di lettura Aurora da un'istanza database RDS per MySQL di origine**
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. Nel pannello di navigazione, seleziona **Database**.
1. Scegliere l'istanza database MySQL da usare come origine per la replica di lettura Aurora.
1. Per **Actions (Operazioni)**, scegliere **Create Aurora read replica (Crea replica di lettura Aurora)**.
1. Scegliere le specifiche del cluster di database da utilizzare per la replica di lettura Aurora, come descritto nella tabella seguente.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.RDSMySQL.Replica.html)
1. Scegliere **Create read replica (Crea replica di lettura)**.
### AWS CLI
Per creare una replica di lettura Aurora da un'istanza DB RDS for MySQL di origine, usa i comandi [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)and per [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI creare un nuovo cluster Aurora MySQL DB. Quando chiami il comando `create-db-cluster`, includi il parametro `--replication-source-identifier` per identificare l'ARN (Amazon Resource Name) per l'istanza database MySQL di origine. Per ulteriori informazioni su Amazon RDS ARNs, consulta [Amazon Relational Database Service (Amazon](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-rds) RDS).
Non specificare il nome utente master, la password master o il nome del database, in quanto la replica di lettura Aurora utilizza lo stesso nome utente master, la password master e il nome del database dell'istanza database MySQL di origine.
Per Linux, macOS o Unix:
```
aws rds create-db-cluster --db-cluster-identifier sample-replica-cluster --engine aurora \
--db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2 \
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:db:primary-mysql-instance
```
Per Windows:
```
aws rds create-db-cluster --db-cluster-identifier sample-replica-cluster --engine aurora ^
--db-subnet-group-name mysubnetgroup --vpc-security-group-ids sg-c7e5b0d2 ^
--replication-source-identifier arn:aws:rds:us-west-2:123456789012:db:primary-mysql-instance
```
Se utilizzi la console per creare una replica di lettura Aurora, Aurora crea automaticamente l'istanza primaria per la replica di lettura Aurora del cluster di database. Se si utilizza il AWS CLI per creare una replica di lettura Aurora, è necessario creare in modo esplicito l'istanza principale per il cluster DB. L'istanza primaria è la prima istanza creata in un cluster di database.
È possibile creare un'istanza primaria per il cluster DB utilizzando il [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI comando con i seguenti parametri.
+ `--db-cluster-identifier`
Nome del cluster DB.
+ `--db-instance-class`
Nome della classe dell'istanza database da utilizzare per l'istanza primaria.
+ `--db-instance-identifier`
Nome dell'istanza primaria.
+ `--engine aurora`
In questo esempio, si crea un'istanza primaria denominata *myreadreplicainstance* per il cluster DB denominato*myreadreplicacluster*, utilizzando la classe di istanza DB specificata in*myinstanceclass*.
**Example**
Per Linux, macOS o Unix:
```
aws rds create-db-instance \
--db-cluster-identifier myreadreplicacluster \
--db-instance-class myinstanceclass \
--db-instance-identifier myreadreplicainstance \
--engine aurora
```
Per Windows:
```
aws rds create-db-instance ^
--db-cluster-identifier myreadreplicacluster ^
--db-instance-class myinstanceclass ^
--db-instance-identifier myreadreplicainstance ^
--engine aurora
```
### API RDS
Per creare una replica di lettura Aurora da un'istanza database RDS per MySQL di origine, utilizza i comandi API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) e [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) di Amazon RDS per creare una nuova istanza primaria e un nuovo cluster database Aurora. Non specificare il nome utente master, la password master o il nome del database, in quanto la replica di lettura Aurora utilizza lo stesso nome utente master, la password master e il nome del database dell'istanza database RDS per MySQL di origine.
Puoi creare un nuovo cluster database Aurora per una replica di lettura Aurora da un'istanza database RDS per MySQL di origine utilizzando il comando [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) dell'API Amazon RDS con i seguenti parametri:
+ `DBClusterIdentifier`
Nome del cluster di database da creare.
+ `DBSubnetGroupName`
Nome del gruppo di sottoreti database da associare al cluster DB.
+ `Engine=aurora`
+ `KmsKeyId`
Con cui AWS KMS key crittografare facoltativamente il cluster DB, a seconda che l'istanza database MySQL sia crittografata.
+ Se l'istanza database MySQL non è crittografata, specifica una chiave di crittografia per fare in modo che il cluster di database sia crittografato mentre è inattivo. Altrimenti, il cluster di database è crittografato mentre è inattivo utilizzando la chiave di crittografia predefinita per l'account.
+ Se l'istanza database MySQL è crittografata, specifica una chiave di crittografia per fare in modo che il cluster di database sia crittografato mentre è inattivo utilizzando la chiave di crittografia specificata. Altrimenti, il cluster di database è crittografato mentre è inattivo utilizzando la chiave di crittografia per l'istanza database MySQL.
**Nota**
Non puoi creare un cluster di database non crittografato da un'istanza database MySQL crittografata.
+ `ReplicationSourceIdentifier`
L'Amazon Resource Name (ARN) per l'istanza database MySQL origine. Per ulteriori informazioni su Amazon RDS ARNs, consulta [Amazon Relational Database Service (Amazon](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html#arn-syntax-rds) RDS).
+ `VpcSecurityGroupIds`
Elenco dei gruppi di sicurezza VPC EC2 da associare a questo cluster di database.
In questo esempio, si crea un cluster DB denominato *myreadreplicacluster* da un'istanza DB MySQL di origine con un ARN impostato su, associato a un gruppo di sottoreti DB *mysubnetgroup* denominato e *mysqlprimaryARN* a un gruppo di sicurezza VPC denominato. *mysecuritygroup*
**Example**
```
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBCluster
&DBClusterIdentifier=myreadreplicacluster
&DBSubnetGroupName=mysubnetgroup
&Engine=aurora
&ReplicationSourceIdentifier=mysqlprimaryARN
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-10-31
&VpcSecurityGroupIds=mysecuritygroup
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20150927/us-east-1/rds/aws4_request
&X-Amz-Date=20150927T164851Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=6a8f4bd6a98f649c75ea04a6b3929ecc75ac09739588391cd7250f5280e716db
```
Se utilizzi la console per creare una replica di lettura Aurora, Aurora crea automaticamente l'istanza primaria per la replica di lettura Aurora del cluster di database. Se si utilizza il AWS CLI per creare una replica di lettura Aurora, è necessario creare in modo esplicito l'istanza principale per il cluster DB. L'istanza primaria è la prima istanza creata in un cluster di database.
Puoi creare un'istanza primaria per il cluster di database utilizzando il comando [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) dell'API Amazon RDS con i seguenti parametri:
+ `DBClusterIdentifier`
Nome del cluster DB.
+ `DBInstanceClass`
Nome della classe dell'istanza database da utilizzare per l'istanza primaria.
+ `DBInstanceIdentifier`
Nome dell'istanza primaria.
+ `Engine=aurora`
In questo esempio, si crea un'istanza primaria denominata *myreadreplicainstance* per il cluster DB denominato*myreadreplicacluster*, utilizzando la classe di istanza DB specificata in. *myinstanceclass*
**Example**
```
https://rds.us-east-1.amazonaws.com/
?Action=CreateDBInstance
&DBClusterIdentifier=myreadreplicacluster
&DBInstanceClass=myinstanceclass
&DBInstanceIdentifier=myreadreplicainstance
&Engine=aurora
&SignatureMethod=HmacSHA256
&SignatureVersion=4
&Version=2014-09-01
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20140424/us-east-1/rds/aws4_request
&X-Amz-Date=20140424T194844Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=bee4aabc750bf7dad0cd9e22b952bd6089d91e2a16592c2293e532eeaab8bc77
```
## Visualizzazione di una replica di lettura Aurora
Puoi visualizzare le relazioni di replica da MySQL a Aurora MySQL per i cluster di database Aurora MySQL utilizzando la Console di gestione AWS o la AWS CLI.
### Console
**Per visualizzare l'istanza database MySQL primaria per una replica di lettura Aurora**
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. Nel pannello di navigazione, seleziona **Database**.
1. Selezionare il cluster di database affinché la replica di lettura Aurora mostri i propri dettagli. Le informazioni sull'istanza database MySQL primaria si trovano nel campo **Replication source (Origine replica)**.
![\[Visualizza il primario MySQL\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-repl6.png)
### AWS CLI
Per visualizzare le relazioni di replica da MySQL ad Aurora MySQL per i cluster Aurora MySQL DB utilizzando i comandi, e. AWS CLI[https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)
Per determinare quale istanza database MySQL è quella primaria, utilizzare [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) e specificare l'identificatore cluster della replica di lettura Aurora per l'opzione `--db-cluster-identifier`. Fai riferimento all'elemento `ReplicationSourceIdentifier` nell'output per l'ARN dell'istanza database che costituisce il principale di replica.
Per determinare quale cluster di database è la replica di lettura Aurora, utilizzare [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) e specificare l'identificatore istanze dell'istanza database MySQL per l'opzione `--db-instance-identifier`. Fai riferimento all'elemento `ReadReplicaDBClusterIdentifiers` nell'output per l'identificatore cluster di database della replica di lettura Aurora.
**Example**
Per Linux, macOS o Unix:
```
aws rds describe-db-clusters \
--db-cluster-identifier myreadreplicacluster
```
```
aws rds describe-db-instances \
--db-instance-identifier mysqlprimary
```
Per Windows:
```
aws rds describe-db-clusters ^
--db-cluster-identifier myreadreplicacluster
```
```
aws rds describe-db-instances ^
--db-instance-identifier mysqlprimary
```
## Promozione di una replica di lettura Aurora
Al termine della migrazione, è possibile promuovere la replica di lettura Aurora a un cluster DB autonomo utilizzando o. Console di gestione AWS AWS CLI
Quindi, puoi indirizzare le applicazioni client all'endpoint per la replica di lettura Aurora. Per ulteriori informazioni sugli endpoint Aurora, consulta [Connessioni degli endpoint Amazon Aurora](Aurora.Overview.Endpoints.md). La promozione dovrebbe completarsi abbastanza velocemente; nel corso della promozione, è possibile eseguire operazioni di lettura e scrittura sulla replica di lettura Aurora. Tuttavia, non è possibile eliminare l'istanza database MySQL master o scollegare l'istanza database e la replica di lettura Aurora durante questo periodo.
Prima di promuovere la replica di lettura Aurora, interrompi la scrittura di transazioni nell'istanza database MySQL di origine e aspetta che il ritardo di replica nella replica di lettura Aurora raggiunga 0. Puoi visualizzare il ritardo della replica per una replica di lettura Aurora chiamando il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3) sulla replica di lettura Aurora. Controlla il valore **secondi di latenza dal principale**.
Puoi iniziare a scrivere la replica di lettura Aurora dopo che le transazioni di scrittura al master sono iniziate e il ritardo della replica equivale a 0. Se scrivi la replica di lettura Aurora prima di ciò e modifichi le tabelle la cui modifica è in corso anche nel master MySQL, rischi di interrompere la replica su Aurora. Se ciò avviene, devi eliminare la replica di lettura Aurora e crearla di nuovo.
### Console
**Come promuovere una replica di lettura Aurora a cluster di database Aurora**
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. Nel pannello di navigazione, seleziona **Database**.
1. Seleziona il cluster di database per la replica di lettura Aurora.
1. In **Actions (Operazioni)**, selezionare **Promote (Promuovi)**.
1. Selezionare **Promote read replica (Promuovi replica di lettura)**.
Dopo la promozione, verificare che la promozione sia stata completata utilizzando la procedura seguente.
**Per confermare che la replica di lettura Aurora è stata promossa**
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. Nel riquadro di navigazione selezionare **Events (Eventi)**.
1. Nella pagina **Events (Eventi)**, verificare che esista un evento `Promoted Read Replica cluster to a stand-alone database cluster` per il cluster promosso.
Al completamento della promozione, l'istanza database MySQL master e la replica di lettura Aurora non sono collegate e puoi eliminare in modo sicuro l'istanza database, se lo desideri.
### AWS CLI
Per promuovere una replica di lettura Aurora in un cluster DB autonomo, usa il comando. [https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) AWS CLI
**Example**
Per Linux, macOS o Unix:
```
aws rds promote-read-replica-db-cluster \
--db-cluster-identifier myreadreplicacluster
```
Per Windows:
```
aws rds promote-read-replica-db-cluster ^
--db-cluster-identifier myreadreplicacluster
```