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à. # Replica con Amazon Aurora MySQL Le funzionalità di replica Aurora MySQL sono essenziali per garantire l'elevata disponibilità e le prestazioni avanzate del cluster. Aurora facilita la creazione o il ridimensionamento dei cluster con un massimo di 15 repliche Aurora. Tutte le repliche utilizzano gli stessi dati sottostanti. Se alcune istanze database passano alla modalità offline, altre rimangono disponibili per continuare a elaborare le query o per essere utilizzate come scrittore, se necessario. Aurora ripartisce automaticamente le connessioni di sola lettura in più istanze database, consentendo a un cluster Aurora di supportare carichi di lavoro che comportano un grande numero di query. Nei seguenti argomenti vengono fornite informazioni sul funzionamento della replica Aurora MySQL nonché sulla regolazione delle impostazioni di replica per garantire una disponibilità e prestazioni ottimali. **Topics** + [ ## Utilizzo delle repliche di Aurora ](#AuroraMySQL.Replication.Replicas) + [ ## Opzioni di replica per Amazon Aurora MySQL ](#AuroraMySQL.Replication.Options) + [ ## Considerazioni sulle prestazioni per la replica Amazon Aurora MySQL ](#AuroraMySQL.Replication.Performance) + [ # Configurazione dei filtri di replica con Aurora MySQL ](AuroraMySQL.Replication.Filters.md) + [ ## Monitoraggio della replica Amazon Aurora MySQL. ](#AuroraMySQL.Replication.Monitoring) + [ # Repliche di cluster di database Amazon Aurora MySQL tra Regioni AWS ](AuroraMySQL.Replication.CrossRegion.md) + [ # Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari) ](AuroraMySQL.Replication.MySQL.md) + [ # Utilizzo della replica basata su GTID ](mysql-replication-gtid.md) ## Utilizzo delle repliche di Aurora Le repliche Aurora sono endpoint indipendenti in un cluster DB Aurora, utilizzati al meglio per operazioni di dimensionamento della lettura e maggiore disponibilità. È possibile distribuire fino a 15 repliche di Aurora nelle zone di disponibilità sulle quali si estende un cluster di database in una Regione AWS. Sebbene il volume cluster database sia fatto di copie multiple di dati per il cluster database, i dati nel volume cluster sono rappresentati come un volume singolo e logico nell'istanza primaria e nelle repliche Aurora nel cluster database. Per ulteriori informazioni sulle repliche di Aurora, consulta [Repliche di Aurora](Aurora.Replication.md#Aurora.Replication.Replicas). Le repliche Aurora funzionano bene per il dimensionamento della lettura perché sono dedicate completamente a operazioni di lettura nel volume cluster. Le operazioni di lettura sono gestite dall'istanza primaria. Poiché il volume del cluster viene condiviso tra tutte le istanze database nel tuo cluster database Aurora MySQL, non è necessaria alcuna ulteriore azione per replicare una copia dei dati per ciascuna replica Aurora. Al contrario, le repliche di lettura MySQL devono riprodurre, su un singolo thread, tutte le operazioni di scrittura dall'istanza database master al datastore locale. Questa limitazione può influire sulla capacita delle repliche di lettura MySQL di supportare grandi volumi di traffico in lettura. Con Aurora MySQL, quando una replica Aurora viene eliminata, l'endpoint dell'istanza viene rimosso immediatamente e la replica Aurora viene rimossa dall'endpoint di lettura. Se vi sono istruzioni in esecuzione nella replica Aurora da eliminare, si ha un periodo di tolleranza di tre minuti. Le istruzioni esistenti possono finire correttamente durante un periodo di tolleranza. Quando finisce il periodo di tolleranza, la replica Aurora viene chiusa ed eliminata. **Importante** Le repliche Aurora per Aurora MySQL utilizzano sempre il livello di isolamento della transazione predefinita `REPEATABLE READ` per operazioni nelle tabelle InnoDB. Puoi utilizzare il comando `SET TRANSACTION ISOLATION LEVEL` per modificare il livello di transazione solo per l'istanza primaria di un cluster database Aurora MySQL. Questa restrizione evita blocchi a livello di utente nelle repliche Aurora e permette alle repliche Aurora di dimensionarsi per supportare migliaia di connessioni utente attive mantenendo il ritardo di replica al minimo. **Nota** Le istruzioni DDL che vengono eseguite sull'istanza primaria possono interrompere le connessioni di database sulle repliche Aurora associate. Se una connessione di replica Aurora sta utilizzando attivamente un oggetto di database, come una tabella e quell'oggetto è modificato nell'istanza primaria utilizzando un'istruzione DDL, la connessione di replica Aurora viene interrotta. **Nota** La regione Cina (Ningxia) non supporta le repliche di lettura fra regioni. ## Opzioni di replica per Amazon Aurora MySQL Puoi impostare repliche tra qualsiasi delle seguenti opzioni: + Due cluster di database Aurora MySQL in Regioni AWS diverse mediante la creazione di una replica di lettura di un cluster di database Aurora MySQL tra regioni. Per ulteriori informazioni, consulta [Repliche di cluster di database Amazon Aurora MySQL tra Regioni AWS](AuroraMySQL.Replication.CrossRegion.md). + Due cluster di database Aurora MySQL nella stessa Regione AWS mediante l'utilizzo di una replica del log binario (binlog) MySQL. Per ulteriori informazioni, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). + Una istanza database RDS for MySQL come origine e un cluster database Aurora MySQL, creando una replica di lettura Aurora di una istanza database RDS for MySQL. È possibile utilizzare questo approccio per apportare modifiche ai dati esistenti e in corso in Aurora MySQL durante la migrazione ad Aurora. 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). È inoltre possibile utilizzare questo approccio per aumentare la scalabilità delle query di lettura per i dati. A tale scopo, eseguire query sui dati utilizzando una o più istanze database all'interno di un cluster Aurora MySQL di sola lettura. Per ulteriori informazioni, consulta [Dimensionamento delle letture per il database MySQL con Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md). + Un cluster di database Aurora MySQL in una Regione AWS e fino a cinque cluster di database Aurora MySQL di sola lettura in regioni diverse mediante la creazione di un database globale Aurora. È possibile utilizzare un database globale Aurora per supportare applicazioni con un footprint globale. Il cluster database Aurora MySQL primario dispone di un'istanza di scrittura e fino a 15 repliche Aurora. I cluster database Aurora MySQL secondari di sola lettura possono essere composti di un massimo di 16 repliche Aurora. Per ulteriori informazioni, consulta [Utilizzo di Database globale Amazon Aurora](aurora-global-database.md). **Nota** Il riavvio dell'istanza primaria di un cluster database Amazon Aurora riavvia automaticamente anche le repliche Aurora per il cluster database, per ristabilire un punto di ingresso che garantisce coerenza di lettura/scrittura nel cluster database. ## Considerazioni sulle prestazioni per la replica Amazon Aurora MySQL Le funzionalità seguenti consentono di ottimizzare le prestazioni della replica Aurora MySQL. La funzionalità di compressione dei log di replica riduce automaticamente la larghezza di banda di rete per i messaggi di replica. Poiché ogni messaggio è trasmesso a tutte le repliche Aurora, i vantaggi sono maggiori per i cluster più voluminosi. Questa funzionalità implica un certo overhead della CPU sul nodo scrittore per eseguire la compressione. È sempre abilitato in Aurora MySQL versione 2 e versione 3. La funzionalità di filtraggio binlog riduce automaticamente la larghezza di banda di rete per i messaggi di replica. Poiché le repliche Aurora non utilizzano informazioni di binlog incluse nei messaggi di replica, quei dati sono omessi dai messaggi inviati a tali nodi. In Aurora MySQL versione 2, puoi controllare questa funzionalità modificando il parametro `aurora_enable_repl_bin_log_filtering`. Per impostazione predefinita, questo parametro è abilitato. Poiché questa ottimizzazione è concepita per essere trasparente, puoi disattivare questa impostazione solo durante la diagnosi o la risoluzione dei problemi relativi alla replica. Ad esempio per corrispondere al comportamento di un cluster Aurora MySQL meno recente dove questa funzionalità non era disponibile. In Aurora MySQL versione 3, il filtraggio dei file binlog è sempre abilitato. # Configurazione dei filtri di replica con Aurora MySQL Puoi utilizzare i filtri di replica per specificare quali database e tabelle vengono replicati con una replica di lettura. I filtri di replica possono includere database e tabelle nella replica o escluderli dalla replica. Di seguito sono riportati alcuni casi d'uso per i filtri di replica: + Per ridurre le dimensioni di una replica di lettura. Con il filtro di replica è possibile escludere i database e le tabelle che non sono necessari nella replica di lettura. + Per escludere database e tabelle dalle repliche di lettura per motivi di sicurezza. + Per replicare database e tabelle diversi per casi d'uso specifici in repliche di lettura diverse. Ad esempio, è possibile utilizzare repliche di lettura specifiche per l'analisi o la condivisione. + Per un cluster di database che dispone di repliche di lettura in più Regioni AWS, per replicare database o tabelle diversi in differenti Regioni AWS. + Per specificare quali database e tabelle vengono replicati con un cluster di database Aurora MySQL configurato come replica in una topologia di replica in entrata. Per ulteriori informazioni su questa configurazione, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). **Topics** + [ ## Impostazione dei parametri dei filtri di replica per Aurora MySQL ](#AuroraMySQL.Replication.Filters.Configuring) + [ ## Limitazioni dei filtri di replica per Aurora MySQL ](#AuroraMySQL.Replication.Filters.Limitations) + [ ## Esempi di filtri di replica per Aurora MySQL ](#AuroraMySQL.Replication.Filters.Examples) + [ ## Visualizzazione dei filtri di replica per una replica di lettura ](#AuroraMySQL.Replication.Filters.Viewing) ## Impostazione dei parametri dei filtri di replica per Aurora MySQL Per configurare i filtri di replica, imposta i seguenti parametri: + `binlog-do-db` – Replica le modifiche ai log binari specificati. Quando si imposta questo parametro per un cluster di origine dei log binari, vengono replicati solo i log binari specificati nel parametro. + `binlog-ignore-db` – Non replicare le modifiche ai log binari specificati. Quando il parametro `binlog-do-db` è impostato per un cluster di origine dei log binari, questo parametro non viene valutato. + `replicate-do-db` – Replicare le modifiche ai database specificati. Quando si imposta questo parametro per un cluster di replica dei log binari, vengono replicati solo i database specificati nel parametro. + `replicate-ignore-db` – Non replicare le modifiche ai database specificati. Quando il parametro `replicate-do-db` è impostato per un cluster di replica dei log binari, questo parametro non viene valutato. + `replicate-do-table` – Replicare le modifiche alle tabelle specificate. Quando si imposta questo parametro per una replica di lettura, vengono replicate solo le tabelle specificate nel parametro. Inoltre, quando viene impostato il parametro `replicate-do-db` o `replicate-ignore-db`, assicurati di includere il database che contiene le tabelle specificate nella replica con il cluster di replica dei log binari. + `replicate-ignore-table` – Non replicare le modifiche alle tabelle specificate. Quando il parametro `replicate-do-table` è impostato per un cluster di replica dei log binari, questo parametro non viene valutato. + `replicate-wild-do-table` – Replicare le tabelle in base ai modelli di nome del database e della tabella specificati. I caratteri jolly `%` e `_` sono supportati. Quando viene impostato il parametro `replicate-do-db` o `replicate-ignore-db`, assicurati di includere il database che contiene le tabelle specificate nella replica con il cluster di replica dei log binari. + `replicate-wild-ignore-table` – Non replicare le tabelle in base ai modelli di nomi di database e tabella specificati. I caratteri jolly `%` e `_` sono supportati. Quando il parametro `replicate-do-table` o `replicate-wild-do-table` è impostato per un cluster di replica dei log binari, questo parametro non viene valutato. I parametri vengono valutati nell'ordine in cui sono elencati. Per ulteriori informazioni sul funzionamento di questi parametri, consulta la documentazione di MySQL: + Per informazioni generali, consulta [Opzioni e variabili del server di replica](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html). + Per informazioni sulla modalità di valutazione dei parametri di filtro della replica del database, consulta [Valutazione delle opzioni di replica a livello di database e registrazione binaria](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-db-options.html). + Per informazioni sulla modalità di valutazione dei parametri di filtro replica delle tabelle, consulta [Valutazione delle opzioni di replica a livello di tabella](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-table-options.html). Per impostazione predefinita, ognuno di questi parametri ha un valore vuoto. In ogni cluster di log binari, è possibile utilizzare questi parametri per impostare, modificare ed eliminare i filtri di replica. Quando viene impostato uno di questi parametri, è necessario separare ogni filtro dagli altri con una virgola. È possibile utilizzare i caratteri jolly `%` e `_` nei parametri `replicate-wild-do-table` e `replicate-wild-ignore-table`. Il carattere jolly `%` corrisponde a un numero qualsiasi di caratteri e il carattere jolly `_` corrisponde a un solo carattere. Il formato di registrazione binaria dell'istanza database di origine è importante per la replica perché determina il record delle modifiche ai dati. L'impostazione del parametro `binlog_format` determina se la replica è basata su righe o basata su dichiarazione. Per ulteriori informazioni, consulta [Configurazione di Aurora per database Single-AZ](USER_LogAccess.MySQL.BinaryFormat.md). **Nota** Tutte le istruzioni DDL (Data Definition Language) vengono replicate come istruzioni, indipendentemente dall'impostazione `binlog_format` dell'istanza database di origine. ## Limitazioni dei filtri di replica per Aurora MySQL Le seguenti limitazioni si applicano ai filtri di replica per Aurora MySQL: + I filtri di replica sono supportati solo per Aurora MySQL versione 3. + Ogni parametro di filtro della replica ha un limite di 2.000 caratteri. + Le virgole non sono supportate nei filtri di replica. + Il filtro delle repliche non supporta le transazioni XA. Per ulteriori informazioni, consulta [Restrizioni sulle transazioni XA](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) nella documentazione di MySQL. ## Esempi di filtri di replica per Aurora MySQL Per configurare il filtro per una replica di lettura, modifica i parametri di filtro replica nel gruppo di parametri del cluster di database associato alla replica di lettura. **Nota** Non è consentito modificare un gruppo di parametri del cluster di database predefinito. Se la replica di lettura usa un gruppo di parametri predefinito, creare un nuovo gruppo di parametri e associarlo alla replica di lettura. Per ulteriori informazioni sui gruppi di parametri del cluster di database, consulta [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). È possibile impostare parametri in un gruppo di parametri del cluster di database utilizzando la Console di gestione AWS, la AWS CLI o l'API RDS. Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). Quando si impostano parametri in un gruppo di parametri del cluster di database, tutti i cluster di database associati al gruppo di parametri utilizzano le impostazioni dei parametri. Se imposti i parametri di filtro replica in un gruppo di parametri del cluster di database, assicurati che il gruppo di parametri sia associato solo alle repliche di lettura. Lasciare vuoti i parametri di filtro di replica per le istanze database di origine. Negli esempi seguenti vengono impostati i parametri utilizzando AWS CLI. In questi esempi si imposta `ApplyMethod` su `immediate` in modo che le modifiche ai parametri avvengano immediatamente dopo il completamento del comando della CLI. Se si desidera applicare una modifica in sospeso dopo il riavvio della replica di lettura, impostare `ApplyMethod` su `pending-reboot`. Gli esempi seguenti impostano i filtri di replica: + [Including databases in replication](#rep-filter-in-dbs-ams) + [Including tables in replication](#rep-filter-in-tables-ams) + [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-ams) + [Excluding databases from replication](#rep-filter-ex-dbs-ams) + [Excluding tables from replication](#rep-filter-ex-tables-ams) + [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-ams) **Example Inclusione dei database nella replica** Nell'esempio seguente sono inclusi i database `mydb1` e `mydb2` nella replica. Per Linux, macOS o Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` **Example Inclusione delle tabelle nella replica** Nell'esempio seguente sono incluse le tabelle `table1` e `table2` nel database `mydb1` nella replica. Per Linux, macOS o Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` **Example Inclusione di tabelle nella replica utilizzando caratteri jolly** Nell'esempio seguente sono incluse tabelle con nomi che iniziano con `order` e `return` nel database `mydb` nella replica. Per Linux, macOS o Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` **Example Esclusione di database dalla replica** Nell'esempio seguente vengono esclusi i database `mydb5` e `mydb6` dalla replica. Per Linux, macOS o Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6,ApplyMethod=immediate" ``` **Example Esclusione di tabelle dalla replica** Nell'esempio seguente vengono escluse dalla replica le tabelle `table1` nel database `mydb5` e `table2` nel database `mydb6`. Per Linux, macOS o Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` **Example Esclusione di tabelle dalla replica utilizzando caratteri jolly** Nell'esempio seguente vengono escluse le tabelle con nomi che iniziano con `order` e `return` nel database `mydb7` dalla replica. Per Linux, macOS o Unix: ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` ## Visualizzazione dei filtri di replica per una replica di lettura È possibile visualizzare i filtri di replica per una replica di lettura nei seguenti modi: + Controllare le impostazioni dei parametri di filtro replica nel gruppo di parametri associato alla replica di lettura. Per istruzioni, consulta [Visualizzazione dei valori dei parametri per un gruppo di parametri del database in Amazon Aurora](USER_WorkingWithParamGroups.Viewing.md). + In un client MySQL, connettersi alla replica di lettura ed eseguire l'istruzione `SHOW REPLICA STATUS`. Nell'output, i campi seguenti mostrano i filtri di replica per la replica di lettura: + `Binlog_Do_DB` + `Binlog_Ignore_DB` + `Replicate_Do_DB` + `Replicate_Ignore_DB` + `Replicate_Do_Table` + `Replicate_Ignore_Table` + `Replicate_Wild_Do_Table` + `Replicate_Wild_Ignore_Table` Per ulteriori informazioni su questi campi, consulta [Verifica dello stato della replica](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) nella documentazione di MariaDB. ## Monitoraggio della replica Amazon Aurora MySQL. Il dimensionamento di lettura e l'alta disponibilità dipendono da un periodo di ritardo minimo. Puoi monitorare il ritardo di una replica Aurora rispetto all'istanza principale del cluster database Aurora MySQL, monitorando il parametro `AuroraReplicaLag` di Amazon CloudWatch. La metrica `AuroraReplicaLag` viene registrata in ogni replica Aurora. L'istanza DB primaria registra anche le metriche `AuroraReplicaLagMaximum` e `AuroraReplicaLagMinimum` Amazon CloudWatch. La metrica `AuroraReplicaLagMaximum` registra la quantità massima di ritardo tra l'istanza DB primaria e ogni replica Aurora nel cluster DB. La metrica `AuroraReplicaLagMinimum` registra la quantità minima di ritardo tra l'istanza DB primaria e ogni replica Aurora nel cluster DB. Se è necessario il valore più attuale del ritardo replica di Aurora, puoi controllare la metrica `AuroraReplicaLag` in Amazon CloudWatch. Il ritardo replica di Aurora viene anche registrato su ogni replica Aurora del cluster database Aurora MySQL nella tabella `information_schema.replica_host_status`. Per ulteriori informazioni su questa tabella, consultare [information\$1schema.replica\$1host\$1status](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.replica_host_status). Per ulteriori informazioni sul monitoraggio delle istanze RDS e dei parametri CloudWatch, consulta [Monitoraggio dei parametri in un cluster di database Amazon Aurora](MonitoringAurora.md). # Repliche di cluster di database Amazon Aurora MySQL tra Regioni AWS Puoi creare un cluster di database Amazon Aurora MySQL come una replica di lettura in una Regione AWS diversa rispetto al cluster di database di origine. L'adozione di questo approccio può migliorare le capacità di ripristino di emergenza, permettere di dimensionare le operazioni di lettura in una Regione AWS più vicina agli utenti e semplificare la migrazione da una Regione AWS a un'altra. Puoi creare repliche di lettura dei cluster di database crittografati e non crittografati. La replica di lettura deve essere crittografata se il cluster di database di origine è crittografato. Per ogni cluster di database di origine, puoi avere fino a cinque cluster database tra regioni che sono repliche di lettura. **Nota** In alternativa alle repliche di lettura tra regioni, è possibile dimensionare le operazioni di lettura con ritardi minimi utilizzando un database globale Aurora. Un Database globale Aurora ha un cluster di database Aurora primario in una Regione AWS e fino a dieci cluster di database di sola lettura secondari in Regioni differenti. Ogni cluster database secondario può includere fino a 16 repliche Aurora (anziché 15). La replica dal cluster database primario a tutti i secondari viene gestita dal livello di archiviazione di Aurora anziché dal motore del database, pertanto il ritardo per la replica delle modifiche è minimo, in genere inferiore a 1 secondo. Mantenere il motore di database fuori dal processo di replica significa che il motore di database è dedicato all'elaborazione dei carichi di lavoro. Significa inoltre che non è necessario configurare o gestire la replica binlog (registrazione dei log binari) di Aurora MySQL. Per ulteriori informazioni, consulta [Utilizzo di Database globale Amazon Aurora](aurora-global-database.md). Quando crei una replica di lettura del cluster di database Aurora MySQL in un'altra Regione AWS, devi tenere presente quanto segue: + Il cluster di database di origine e il cluster di database di replica di lettura tra regione può avere fino a 15 repliche Aurora assieme all'istanza primaria per il cluster database. Con questa funzionalità, puoi dimensionare le operazioni di lettura per la Regione AWS di origine e la Regione AWS di destinazione della replica. + In uno scenario con più regioni, si verifica un ritardo maggiore tra il cluster di database di origine e la replica di lettura a causa della maggiore lunghezza dei canali di rete tra Regioni AWS. + I dati trasferiti per repliche tra regioni comportano costo di trasferimento dei dati Amazon RDS. Le seguenti operazioni di replica tra regioni generano addebiti per i dati trasferiti fuori dalla Regione AWS di origine: + Quando si crea la replica di lettura, Amazon RDS acquisisce uno snapshot del cluster di origine e lo trasferisce alla Regione AWS che contiene la replica di lettura. + Per ogni modifica dei dati apportata nei database di origine, Amazon RDS trasferisce dati dalla regione di origine alla Regione AWS che contiene la replica di lettura. Per ulteriori informazioni sui prezzi del trasferimento dati Amazon RDS, consulta [Prezzi di Amazon Aurora](https://aws.amazon.com/rds/aurora/pricing/). + Puoi eseguire più operazioni di creazione o eliminazione simultanee per repliche di lettura che fanno riferimento allo stesso cluster di database di origine. Tuttavia, devi rimanere entro il limite di cinque repliche di lettura per ogni cluster di database di origine. + Per un efficace funzionamento della replica, ciascuna replica di lettura deve avere la stessa quantità di risorse di calcolo e storage del cluster di database di origine. Se si dimensiona il cluster di database di origine, si devono dimensionare anche le repliche di lettura. **Topics** + [ ## Prima di iniziare ](#AuroraMySQL.Replication.CrossRegion.Prerequisites) + [ # Creazione di un cluster di database per una replica di lettura tra Regioni per Aurora MySQL ](AuroraMySQL.Replication.CrossRegion.Creating.md) + [ # Promozione di una replica di lettura a cluster di database per Aurora MySQL ](AuroraMySQL.Replication.CrossRegion.Promote.md) + [ # Risoluzione dei problemi delle repliche tra Regioni per Amazon Aurora MySQL ](AuroraMySQL.Replication.CrossRegion.Troubleshooting.md) ## Prima di iniziare Prima di poter creare un cluster di database di Aurora MySQL che è una replica di lettura tra regioni, è necessario abilitare l'accesso binario al cluster di database fonte di Aurora MySQL. La replica tra regioni per Aurora MySQL utilizza la replica binaria MySQL per riprodurre le modifiche nel cluster di database di replica di lettura tra regioni. Per abilitare l'accesso binario a un cluster database Aurora MySQL, aggiornare il parametro `binlog_format` per il cluster database fonte. Il parametro `binlog_format` è un parametro a livello di cluster che si trova nel gruppo di parametri cluster predefinito. Se il cluster database utilizza il gruppo di parametri cluster database predefinito, crea un nuovo gruppo di parametri cluster database per modificare le impostazioni `binlog_format`. Consigliamo di impostare `binlog_format` su `MIXED`. Tuttavia, puoi anche impostare `binlog_format` su `ROW` o `STATEMENT` se hai bisogno di un formato binlog specifico. Riavvia il cluster database Aurora affinché venga applicata la modifica. Per ulteriori informazioni sull'utilizzo di registrazione binaria con Aurora, consulta [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). Per ulteriori informazioni sulla modifica dei parametri di configurazione di Aurora MySQL, consulta [Parametri dell’istanza database e del cluster database di Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) e [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). # Creazione di un cluster di database per una replica di lettura tra Regioni per Aurora MySQL Puoi creare un cluster database Aurora che è una replica di lettura tra regioni utilizzando la Console di gestione AWS, la AWS Command Line Interface (AWS CLI) o l'API di Amazon RDS. Puoi creare repliche di lettura tra regioni da cluster di database crittografati e non crittografati. Quando crei una replica di lettura tra Regioni per Aurora MySQL utilizzando la Console di gestione AWS, Amazon RDS crea un cluster database nella Regione AWS di destinazione e poi crea automaticamente un'istanza database che è l'istanza primaria per quel cluster database. Quando crei una replica di lettura tra Regioni utilizzando la AWS CLI o l'API RDS, prima crea il cluster database nella Regione AWS di destinazione e attendi che diventi attivo. Quando è attivo, crei un'istanza database che è l'istanza primaria per il cluster database. La replica inizia quando l'istanza primaria del cluster di database di replica di lettura diventa disponibile. Utilizza le seguenti procedure per creare una replica di lettura tra regioni da un cluster di database di Aurora MySQL. Queste procedure funzionano per la creazione di repliche di lettura da cluster di database crittografati o non crittografati. ## Console **Come creare un cluster database Aurora MySQL che è una replica di lettura tra regioni con la Console di gestione AWS** 1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nell'angolo in alto a destra della Console di gestione AWS, selezionare la Regione AWS che ospita il cluster di database di origine. 1. Nel riquadro di navigazione, scegliere **Databases** (Database). 1. Seleziona il cluster database per cui vuoi creare una replica di lettura tra Regioni. 1. In **Actions** (Operazioni), scegli **Create cross region read replica** (Crea replica di lettura tra regioni). 1. Nella pagina **Create cross region read replica (Crea replica di lettura tra regioni)**, scegliere le impostazioni di opzione per il cluster di database di replica di lettura tra regioni, come descritto nella seguente tabella. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.Creating.html) 1. Seleziona **Create (Crea)** per creare la replica di lettura tra regioni per Aurora. ## AWS CLI **Per creare un cluster di database Aurora MySQL che è una replica di lettura tra regioni con CLI** 1. Chiamare il comando AWS CLI [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) nella Regione AWS in cui si desidera creare il cluster di database di replica di lettura. Includi l'opzione `--replication-source-identifier` e specifica l' Amazon Resource Name (ARN) del cluster di database per il quale creare una replica di lettura. Per la replica tra regioni dove il cluster di database identificato tramite `--replication-source-identifier` è crittografato, è necessario specificare anche le opzioni `--kms-key-id` e `--storage-encrypted`. **Nota** Puoi impostare repliche tra regioni da un cluster di database crittografato a una replica di lettura crittografata specificando `--storage-encrypted` e fornendo un valore per `--kms-key-id`. Non puoi specificare i parametri `--master-username` e `--master-user-password`. Tali valori vengono presi dal cluster di database di origine. Il seguente esempio di codice crea una replica di lettura nella regione us-east-1 da uno snapshot di cluster di database non crittografato nella regione us-west-2. Il comando viene chiamato nella regione Stati Uniti orientali 1. In questo esempio è specificata l'opzione `--manage-master-user-password` per generare la password dell'utente master e gestirla in Secrets Manager. Per ulteriori informazioni, consulta [Gestione delle password con Amazon Aurora e Gestione dei segreti AWS](rds-secrets-manager.md). In alternativa, puoi utilizzare l'opzione `--master-password` per specificare e gestire personalmente la password. Per Linux, macOS o Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` Per Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` Il seguente esempio di codice crea una replica di lettura nella regione us-east-1 da uno snapshot di cluster di database crittografato nella regione us-west-2. Il comando viene chiamato nella regione Stati Uniti orientali 1. Per Linux, macOS o Unix: ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster \ --kms-key-id my-us-east-1-key \ --storage-encrypted ``` Per Windows: ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ^ --kms-key-id my-us-east-1-key ^ --storage-encrypted ``` L'opzione `--source-region` è obbligatoria per la replica tra la regione AWS GovCloud (Stati Uniti orientali) e la regione AWS GovCloud (Stati Uniti occidentali), dove il cluster di database identificato da `--replication-source-identifier` è crittografato. Per `--source-region`, specificare la Regione AWS del cluster di database di origine. Se non si specifica `--source-region`, è necessario specificare un valore per `--pre-signed-url`. Un *URL prefirmato* è un URL che contiene una richiesta firmata Signature Versione 4 per il comando `create-db-cluster` chiamato nella Regione AWS di origine. Per ulteriori informazioni sull'opzione `pre-signed-url`, consulta [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) in *Riferimento ai comandi AWS CLI*. 1. Controlla che il cluster di database sia diventato disponibile utilizzando il comando AWS CLI [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html), come visualizzato nell'esempio seguente. ``` aws rds describe-db-clusters --db-cluster-identifier sample-replica-cluster ``` Quando i risultati **`describe-db-clusters`** mostrano uno stato `available`, crea l'istanza primaria per il cluster database affinché la replica possa iniziare. A tale scopo, utilizza il comando AWS CLI [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html), come visualizzato nell'esempio seguente. Per Linux, macOS o Unix: ``` aws rds create-db-instance \ --db-cluster-identifier sample-replica-cluster \ --db-instance-class db.r5.large \ --db-instance-identifier sample-replica-instance \ --engine aurora-mysql ``` Per Windows: ``` aws rds create-db-instance ^ --db-cluster-identifier sample-replica-cluster ^ --db-instance-class db.r5.large ^ --db-instance-identifier sample-replica-instance ^ --engine aurora-mysql ``` Quando l'istanza database viene creata e diventa disponibile, inizia la replica. Puoi determinare se l'istanza database è disponibile chiamando il comando AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html). ## API RDS **Per creare un cluster di database di Aurora MySQL che è una replica di lettura tra regioni con l'API** 1. Chiama l'operazione dell'API RDS [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) nella Regione AWS in cui desideri creare il cluster di database di replica di lettura. Includi il parametro `ReplicationSourceIdentifier` e specifica l' Amazon Resource Name (ARN) del cluster di database per il quale creare una replica di lettura. Per la replica tra regioni dove il cluster di database identificato da `ReplicationSourceIdentifier` è crittografato, specifica il parametro `KmsKeyId` e impostare il parametro `StorageEncrypted` su `true`. **Nota** Puoi configurare repliche tra regioni da un cluster di database crittografato a una replica di lettura crittografata specificando `StorageEncrypted` come **true** e fornendo un valore per `KmsKeyId`. In questo caso, non devi specificare `PreSignedUrl`. Non devi includere i parametri `MasterUsername` e `MasterUserPassword`, perché quei valori sono presi dal cluster database origine. Il seguente esempio di codice crea una replica di lettura nella regione us-east-1 da uno snapshot di cluster di database non crittografato nella regione us-west-2. Questa operazione viene chiamata nella regione us-east-1. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` Il seguente esempio di codice crea una replica di lettura nella regione us-east-1 da uno snapshot di cluster di database crittografato nella regione us-west-2. Questa operazione viene chiamata nella regione us-east-1. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &KmsKeyId=my-us-east-1-key &StorageEncrypted=true &PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F %253FAction%253DCreateDBCluster %2526DestinationRegion%253Dus-east-1 %2526KmsKeyId%253Dmy-us-east-1-key %2526ReplicationSourceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Acluster%25253Asample-master-cluster %2526SignatureMethod%253DHmacSHA256 %2526SignatureVersion%253D4 %2526Version%253D2014-10-31 %2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256 %2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds%252Faws4_request %2526X-Amz-Date%253D20161117T215409Z %2526X-Amz-Expires%253D3600 %2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-content-sha256%253Bx-amz-date %2526X-Amz-Signature%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613 &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` Per la replica tra regioni tra la regione AWS GovCloud (Stati Uniti orientali) e la regione AWS GovCloud (Stati Uniti occidentali), in cui il cluster di database identificato da `ReplicationSourceIdentifier` è crittografato, specificare anche il parametro `PreSignedUrl`. L'URL prefirmato deve essere una richiesta valida per l'operazione API `CreateDBCluster` che può essere eseguita nella Regione AWS di origine contenente il cluster di database crittografato da replicare. L'identificatore della chiave KMS viene utilizzato per crittografare la replica di lettura e deve essere una chiave KMS valida per la Regione AWS di destinazione. Per generare automaticamente invece che manualmente un URL prefirmato, utilizzare il comando AWS CLI [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html), ma con l'opzione `--source-region`. 1. Controllare che il cluster di database sia diventato disponibile utilizzando l'operazione [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) dell'API RDS, come visualizzato nell'esempio seguente. ``` https://rds.us-east-1.amazonaws.com/ ?Action=DescribeDBClusters &DBClusterIdentifier=sample-replica-cluster &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T002223Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=84c2e4f8fba7c577ac5d820711e34c6e45ffcd35be8a6b7c50f329a74f35f426 ``` Quando lo stato dei risultati di `DescribeDBClusters` è `available`, creare l'istanza primaria per il cluster di database affinché la replica possa iniziare. A tale scopo, utilizzare l'operazione [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) dell'API RDS come visualizzato nell'esempio seguente. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBInstance &DBClusterIdentifier=sample-replica-cluster &DBInstanceClass=db.r5.large &DBInstanceIdentifier=sample-replica-instance &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T003808Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=125fe575959f5bbcebd53f2365f907179757a08b5d7a16a378dfa59387f58cdb ``` Quando l'istanza database viene creata e diventa disponibile, inizia la replica. Puoi determinare se l'istanza database è disponibile chiamando il comando AWS CLI [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html). ## Visualizzazione di repliche tra regioni Amazon Aurora MySQL Puoi visualizzare le relazioni di replica tra regioni per i cluster di database di Amazon Aurora MySQL chiamando il comando AWS CLI [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) o l'operazione API RDS [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html). Nella risposta, fai riferimento al campo `ReadReplicaIdentifiers` per gli identificatori di cluster di database di cluster di qualsiasi cluster di database di replica di lettura tra regioni. Fai riferimento all'elemento `ReplicationSourceIdentifier` per l'ARN del cluster di database di origine corrispondente all'origine della replica. # Promozione di una replica di lettura a cluster di database per Aurora MySQL Puoi promuovere una replica di lettura Aurora MySQL a un cluster database standalone. Quando promuovi una replica di lettura Aurora MySQL, le relative istanze database vengono riavviate per essere disponibili. In genere, promuovi una replica di lettura Aurora MySQL a un cluster database standalone come schema di ripristino dei dati in caso di errore del cluster database di origine. A tale scopo, crea prima di tutto una replica di lettura e quindi monitora il cluster di database di origine per individuare eventuali errori. In caso di errore, sono necessarie le operazioni seguenti: 1. Promuovi la replica di lettura. 1. Indirizzare il traffico di database al cluster database promosso. 1. Creare una replica di lettura sostitutiva con il cluster di database promosso come origine. Quando promuovi una replica di lettura, questa diventa un cluster di database Aurora standalone. Il processo di promozione può richiedere alcuni minuti per il completamento, che possono aumentare a seconda delle dimensioni della replica di lettura. Dopo aver promosso la replica di lettura a nuovo cluster di database, il cluster si comporta come qualsiasi altro cluster di database. Ad esempio, è possibile creare repliche di lettura dal cluster ed eseguire operazioni di ripristino point-in-time. È anche possibile creare repliche Aurora per il cluster database. Poiché il cluster di database promosso non è più una replica di lettura, non è possibile usarlo come target di replica. Le fasi seguenti illustrano il processo generale di promozione di una replica di lettura a cluster di database: 1. Arrestare la scrittura delle transazioni nel cluster di database di origine della replica di lettura e quindi attendere il completamento di tutti gli aggiornamenti nella replica di lettura. Gli aggiornamenti del database vengono eseguiti nella replica di lettura dopo essere stati completati nel cluster di database di origine e questo ritardo di replica può variare significativamente. Utilizzare il parametro `ReplicaLag` per determinare quando sono stati applicati tutti gli aggiornamenti alla replica di lettura. Il parametro `ReplicaLag` consente di registrare il tempo di ritardo di un'istanza database di replica di lettura rispetto all'istanza database di origine. Quando il parametro `ReplicaLag` diventa `0`, la replica di lettura ha raggiunto l'istanza database di origine. 1. Promuovi la replica di lettura utilizzando l'opzione **Promuovi** sulla console Amazon RDS, il comando AWS CLI [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) o l'operazione API Amazon RDS [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html). È possibile scegliere un'istanza database Aurora MySQL per promuovere la replica di lettura. Dopo la promozione della replica di lettura, il cluster di database di Aurora MySQL viene promosso a cluster di database standalone. L'istanza database con la priorità di failover maggiore viene promossa a istanza database primaria per il cluster database. Le altre istanze database diventano repliche Aurora. **Nota** Per il completamento del processo di promozione sono necessari alcuni minuti. Quando promuovi una replica di lettura, la replica viene arrestata e le istanze database vengono riavviate. Al termine del riavvio, la replica di lettura è disponibile come un nuovo cluster di database. ## Console **Per promuovere una replica di lettura Aurora MySQL a cluster database** 1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nella console scegliere **Instances (Istanze)**. Viene visualizzato il riquadro **Instance (Istanza)**. 1. Nel riquadro **Instances (Istanze)**, scegliere la replica di lettura che si vuole promuovere. Le repliche di lettura vengono visualizzate come istanze database Aurora MySQL. 1. Per **Actions (Operazioni)**, scegliere **Promote read replica (Promuovere replica di lettura)**. 1. Nella pagina di conferma scegliere **Promote read replica (Promuovi replica di lettura)**. ## AWS CLI Per promuovere una replica di lettura a un cluster di database, utilizza il comando AWS CLI [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html). **Example** Per Linux, macOS o Unix: ``` aws rds promote-read-replica-db-cluster \ --db-cluster-identifier mydbcluster ``` Per Windows: ``` aws rds promote-read-replica-db-cluster ^ --db-cluster-identifier mydbcluster ``` ## API RDS Per promuovere una replica di lettura a cluster di database, chiama [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html). # Risoluzione dei problemi delle repliche tra Regioni per Amazon Aurora MySQL Di seguito è riportato un elenco di messaggi di errore comuni che si possono verificare durante la creazione di una replica di lettura tra regioni Amazon Aurora e le istruzioni per risolvere gli errori specificati. ## Il cluster origine [cluster database ARN] non ha binlog abilitati Per risolvere questo problema, abilitare l'accesso binario nel cluster database origine. Per ulteriori informazioni, consulta [Prima di iniziare](AuroraMySQL.Replication.CrossRegion.md#AuroraMySQL.Replication.CrossRegion.Prerequisites). ## Il cluster origine [ARN cluster database] non ha il gruppo di parametri del cluster sincronizzato nello scrittore Ricevi questo errore se hai aggiornato il parametro `binlog_format` del cluster database, ma non hai riavviato l'istanza primaria per il cluster database. Riavvia l'istanza primaria (ovvero, lo scrittore) per il cluster database e prova di nuovo. ## Il cluster origine [ARN cluster database] ha già una replica di lettura in questa regione Per ogni cluster di database di origine in qualsiasi Regione AWS, puoi avere fino a cinque cluster di database tra regioni che sono repliche di lettura. Se disponi già del numero massimo di repliche di lettura per un cluster di database in una particolare Regione AWS, devi eliminarne una esistente prima di poter creare un nuovo cluster di database tra regioni in tale regione. ## Il cluster di database [ARN cluster di database] richiede l'aggiornamento di un motore di database per il supporto delle repliche tra regioni Per risolvere questo problema, aggiorna la versione del motore di database per tutte le istanze nel cluster di database di origine alla versione di motore di database più recente e prova a creare di nuovo la replica di lettura tra regioni. # Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari) In quanto Amazon Aurora MySQL è compatibile con MySQL, puoi impostare la replica tra un database MySQL e un cluster di database Amazon Aurora MySQL. Questo tipo di replica utilizza la replica dei log binari MySQL ed è comunemente indicato come *replica binlog*. Se si utilizza la replica dei log binari con Aurora, si consiglia di eseguire sul database MySQL versione 5.5 o successiva. È possibile impostare la replica in cui il cluster Aurora MySQL del database è il master di replica o la replica. È possibile eseguire la replica con un'istanza DB Amazon RDS MySQL, un database MySQL esterno su Amazon RDS o un altro cluster DB Aurora MySQL. **Nota** Non è possibile utilizzare la replica binlog da o verso determinati tipi di cluster di database Aurora. In particolare, la replica binlog non è disponibile per i cluster Aurora Serverless v1. Se l'istruzione `SHOW MASTER STATUS` e `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3) non restituisce alcun output, controlla che il cluster in uso supporti la replica binlog. Puoi anche eseguire una replica con un'istanza database RDS per MySQL o un cluster di database Aurora MySQL in un'altra Regione AWS. Quando esegui la replica su più server Regioni AWS, assicurati che i cluster e le istanze DB siano accessibili pubblicamente. Se i cluster di database Aurora MySQL si trovano in sottoreti private nel VPC, usa il peering VPC tra le Regioni AWS. Per ulteriori informazioni, consulta [Un cluster database in un VPC a cui accede un'istanza EC2 in un VPC diverso](USER_VPC.Scenarios.md#USER_VPC.Scenario3). Se si desidera configurare la replica tra un cluster Aurora MySQL DB e un cluster Aurora MySQL DB in un altro, è possibile creare un cluster Aurora MySQL DB come replica di lettura Regione AWS in un cluster DB diverso da quello di origine. Regione AWS Per ulteriori informazioni, consulta [Repliche di cluster di database Amazon Aurora MySQL tra Regioni AWS](AuroraMySQL.Replication.CrossRegion.md). Con Aurora MySQL versione 2 e 3, è possibile eseguire la replica tra Aurora MySQL e un'origine o una destinazione esterna che utilizza gli identificatori di transazione globali () per la replica. GTIDs Assicurati che i parametri basati su GTID nel cluster di database Aurora MySQL presentino impostazioni compatibili con lo stato GTID del database esterno. Per informazioni su come effettuare questa operazione, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). In Aurora MySQL versione 3.01 e successive, puoi scegliere come assegnare transazioni replicate da una GTIDs fonte che non utilizza. GTIDs Per informazioni sulla procedura archiviata che controlla tale impostazione, vedere [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versione 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). **avvertimento** Quando esegui la replica tra Aurora MySQL e MySQL, assicurati di utilizzare solo tabelle InnoDB. Se hai tabelle MyISAM, che desideri replicare, puoi convertirle in InnoDB prima di impostare la replica con il seguente comando. ``` alter table . engine=innodb, algorithm=copy; ``` Nelle sezioni seguenti, viene descritto come configurare la replica, interrompere la replica, scalare le letture per il database in uso, ottimizzare la replica binlog e configurare il file di log binario avanzato. **Topics** + [ # Configurazione del processo di replica dei log binari per Aurora MySQL ](AuroraMySQL.Replication.MySQL.SettingUp.md) + [ # Arresto del processo di replica dei log binari per Aurora MySQL ](AuroraMySQL.Replication.MySQL.Stopping.md) + [ # Dimensionamento delle letture per il database MySQL con Amazon Aurora ](AuroraMySQL.Replication.ReadScaling.md) + [ # Ottimizzazione della replica dei log binari per Aurora MySQL ](binlog-optimization.md) + [ # Configurazione del file di log binario avanzato per Aurora MySQL ](AuroraMySQL.Enhanced.binlog.md) # Configurazione del processo di replica dei log binari per Aurora MySQL L'impostazione della replica MySQL con Aurora MySQL prevede le seguenti fasi che vengono discusse in dettaglio: **Contents** + [ ## 1. Abilitare l'accesso binario nella fonte di replica ](#AuroraMySQL.Replication.MySQL.EnableBinlog) + [ ## 2. Mantieni i log binari nel master di replica fino a quando non sono più necessari ](#AuroraMySQL.Replication.MySQL.RetainBinlogs) + [ ## 3. Creazione di una copia o un dump dell’origine della replica ](#AuroraMySQL.Replication.MySQL.CreateSnapshot) + [ ## 4. Caricamento del dump nella destinazione di replica (se necessario) ](#AuroraMySQL.Replication.MySQL.LoadSnapshot) + [ ## 5. Creazione di un utente di replica sull’origine di replica ](#AuroraMySQL.Replication.MySQL.CreateReplUser) + [ ## 6. Abilitare la replica nel target di replica ](#AuroraMySQL.Replication.MySQL.EnableReplication) + [ ### Definire una posizione per arrestare la replica su una replica di lettura ](#AuroraMySQL.Replication.StartReplicationUntil) + [ ## 7. Monitora la replica ](#AuroraMySQL.Replication.MySQL.Monitor) + [ ## Sincronizzazione delle password tra origine di replica e destinazione ](#AuroraMySQL.Replication.passwords) ## 1. Abilitare l'accesso binario nella fonte di replica Seguono le istruzioni su come abilitare l'accesso binario nella fonte di replica per il motore del database. | Motore del database | Istruzioni | | --- | --- | | Aurora MySQL | **Per abilitare l'accesso binario in un cluster di database Aurora MySQL** Imposta il parametro del cluster di database `binlog_format` su `ROW`, `STATEMENT` o `MIXED`. `MIXED` è consigliato a meno che tu abbia bisogno di un formato binlog specifico. Il valore predefinito è `OFF`. Per modificare il parametro `binlog_format`, crea un gruppo di parametri del cluster di database personalizzato e associalo al tuo cluster di database. Non puoi modificare i parametri in un gruppo di parametri del cluster di database predefinito. Se stai modificando il parametro `binlog_format` da `OFF` a un altro valore, riavvia il cluster di database Aurora per rendere effettiva la modifica. Per ulteriori informazioni, consulta [Parametri dell’istanza database e del cluster database di Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) e [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). | | RDS for MySQL | **Per abilitare l'accesso binario in un'istanza database Amazon RDS** Non è possibile abilitare l'accesso binario direttamente per un'istanza database Amazon RDS, ma si può abilitarlo procedendo in uno dei seguenti modi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | MySQL (esterno) | **Per impostare la replica crittografata** Per replicare i dati in maniera sicura con Aurora MySQL versione 2, puoi utilizzare la replica crittografata. Se non hai bisogno di utilizzare la replica crittografata, puoi saltare queste fasi. Seguono i prerequisiti per l'utilizzo della replica crittografata: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Per abilitare l'accesso binario a un database esterno MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | ## 2. Mantieni i log binari nel master di replica fino a quando non sono più necessari Quando si utilizza la replica dei log binari MySQL, Amazon RDS non gestisce il processo di replica. Come risultato, devi assicurarti che i file binlog nel master di replica siano mantenuti finché le modifiche vengono applicate alla replica. Questa manutenzione aiuta a ripristinare il database di origine in caso di errore. Utilizza le istruzioni seguenti per mantenere i registri binari per il motore di database. | Motore del database | Istruzioni | | --- | --- | | Aurora MySQL | **Per mantenere i log binari in un cluster di database Aurora MySQL** Non hai accesso ai file binlog per un cluster di database Aurora MySQL. Come risultato, devi selezionare un intervallo di tempo per mantenere i file binlog nel master di replica abbastanza a lungo per assicurare che le modifiche vengano applicate alla replica prima che il file binlog venga eliminato da Amazon RDS. Puoi mantenere i file binlog in un cluster di database Aurora MySQL fino a 90 giorni. Se stai impostando la replica con un database MySQL o un'istanza database RDS per MySQL come replica e il database per il quale stai creando la replica è di grandi dimensioni, seleziona un intervallo di tempo ampio per mantenere i file binlog finché la copia iniziale del database nella replica sia completa e il ritardo di replica sia pari a 0. Per impostare il periodo di conservazione dei log binari, usa la procedura [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) e specifica il parametro di configurazione `'binlog retention hours'` insieme al numero di ore di conservazione dei file binlog nel cluster di database. Il valore massimo per Aurora MySQL versione 2.11.0 e successive e versione 3 è 2160 (90 giorni). L'esempio seguente imposta il periodo di conservazione dei file binlog su 6 giorni: 
CALL mysql.rds_set_configuration('binlog retention hours', 144);
Dopo l'inizio della replica, è possibile verificare che le modifiche siano state applicate alla replica eseguendo il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3) nella replica e controllando il campo `Seconds behind master`. Se il campo `Seconds behind master` è 0, non vi è alcun ritardo di replica. Quando non c'é ritardo di replica, riduci il periodo di tempo di conservazione dei file binlog impostando il parametro di configurazione `binlog retention hours` su un intervallo di tempo più breve. Se questa impostazione non è specificata, verrà utilizzato il valore predefinito per Aurora MySQL ovvero 24 (1 giorno). Se si specifica un valore per `'binlog retention hours'` che è superiore al valore massimo, allora Aurora MySQL utilizza il valore massimo. | | RDS per MySQL | **Per mantenere i log binari in un'istanza database Amazon RDS** Puoi mantenere i file dei registri binari in un'istanza database di Amazon RDS impostando le ore di conservazione del binlog allo stesso modo di un cluster di database Aurora MySQL, come descritto nella riga precedente. Puoi anche mantenere i file binlog in un'istanza database Amazon RDS creando una replica di lettura per l'istanza database. La replica di lettura è temporanea e ha solamente l'obiettivo di mantenere i file binlog. Dopo che la replica di lettura è stata creata, chiama la procedura [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) nella replica di lettura. Mentre la replica è interrotta, Amazon RDS non elimina nessuno dei file binlog nel master di replica. Dopo aver impostato la replica con la replica permanente, puoi eliminare la replica di lettura quando il ritardo di replica (campo `Seconds behind master`) tra il master di replica a la replica permanente diventa 0. | | MySQL (esterno) | **Per mantenere i log binari in un database esterno MySQL;** Siccome i file binlog in un database MySQL non sono gestiti da Amazon RDS, vengono mantenuti finché li elimini. Dopo l'inizio della replica, è possibile verificare che le modifiche siano state applicate alla replica eseguendo il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3) nella replica e controllando il campo `Seconds behind master`. Se il campo `Seconds behind master` è 0, non vi è alcun ritardo di replica. Quando non c'é ritardo di replica, puoi eliminare i vecchi file binlog. | ## 3. Creazione di una copia o un dump dell’origine della replica È possibile utilizzare uno snapshot, un clone o un dump dell’origine della replica per caricare una copia di base dei dati nella replica. Quindi si inizia a replicare da quel punto. Utilizza le istruzioni seguenti per creare una copia o un dump dell’origine della replica per il motore di database. | Motore del database | Istruzioni | | --- | --- | | Aurora MySQL | **Come creare una copia di un cluster di database Aurora MySQL** Seleziona uno dei seguenti metodi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Come determinare il nome e la posizione del file binlog** Seleziona uno dei seguenti metodi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Come creare un dump di un cluster di database Aurora MySQL** Se la destinazione di replica è un database MySQL esterno o un’istanza database RDS per MySQL, devi creare un file dump dal cluster di database Aurora. Assicurati che il comando `mysqldump` venga eseguito nella copia del cluster di database di origine che hai creato. In questo modo si evitano considerazioni bloccanti quando si esegue il dump. Se il dump fosse eseguito direttamente sul cluster di database di origine, sarebbe necessario bloccare le tabelle di origine per evitare scritture simultanee su di esse mentre il dump è in corso. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | RDS per MySQL | **Per creare una snapshot di un'istanza database Amazon RDS** Crea una replica di lettura dell'istanza database Amazon RDS. Per ulteriori informazioni, consulta [Creazione di una replica di lettura](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) nella *Guida per l'utente di Amazon Relational Database Service*. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | MySQL (esterno) | **Per creare il dump di un database MySQL esterno** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | ## 4. Caricamento del dump nella destinazione di replica (se necessario) Se intendi caricare i dati da un dump di un database MySQL che è esterno ad Amazon RDS, è consigliabile creare un’istanza EC2 in cui copiare i file dump. Quindi puoi caricare i dati nel tuo cluster di database o nell’istanza database da quell’istanza EC2. Utilizzando questo approccio, puoi comprimere i file dump prima di copiarli nell'istanza EC2 per ridurre i costi di rete associati con la copia dei dati in Amazon RDS. Puoi anche crittografare il file o i file dump per assicurare i dati mentre vengono trasferiti nella rete. **Nota** Se crei un nuovo cluster di database Aurora MySQL come destinazione di replica, non è necessario che tu carichi un file dump: È possibile eseguire il ripristino da uno snapshot del cluster di database per creare un nuovo cluster di database. Per ulteriori informazioni, consulta [Ripristino da uno snapshot cluster database](aurora-restore-snapshot.md). Puoi clonare il tuo cluster di database di origine per creare un nuovo cluster di database. Per ulteriori informazioni, consulta [Clonazione di un volume per un cluster di database Amazon Aurora](Aurora.Managing.Clone.md). Puoi eseguire la migrazione dei dati da uno snapshot di un’istanza database in un nuovo cluster di database. Per ulteriori informazioni, consulta [Migrazione di dati a un cluster di database Amazon Aurora MySQL](AuroraMySQL.Migrating.md). Utilizza le istruzioni seguenti per caricare il dump dell’origine di replica nella destinazione di replica per il motore di database. | Motore del database | Istruzioni | | --- | --- | | Aurora MySQL | **Come caricare un dump in un cluster di database Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | RDS per MySQL | **Per caricare un dump in un'istanza database Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | MySQL (esterno) | **Per caricare un dump in un database MySQL esterno** Non è possibile caricare uno snapshot di database o di cluster di database in un database MySQL esterno. Devi utilizzare invece l'output dal comando `mysqldump`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | ## 5. Creazione di un utente di replica sull’origine di replica Crea un ID utente sull’origine utilizzato solamente per la replica. L’esempio seguente riguarda database RDS per MySQL o database di origine MySQL esterni. ``` mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password'; ``` Per i database di origine Aurora MySQL, il parametro del cluster di database `skip_name_resolve` è impostato su `1` (`ON`) e non può essere modificato, quindi è necessario utilizzare un indirizzo IP per l’host anziché un nome di dominio. Per ulteriori informazioni, consulta [skip\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_skip_name_resolve) nella documentazione di MySQL. ``` mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password'; ``` L'utente richiede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE`. Concedi questi privilegi all'utente. Se non hai bisogno di utilizzare la replica crittografata, richiedi le connessioni SSL per l'utente replica. Ad esempio, puoi utilizzare una delle seguenti istruzioni per richiedere connessioni SSL per l’account utente `repl_user`. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address'; ``` ``` GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL; ``` **Nota** Se `REQUIRE SSL` non è incluso, la connessione di replica potrebbe ridiventare una connessione non crittografata. ## 6. Abilitare la replica nel target di replica Raccomandiamo di fare una snapshot manuale del cluster di database Aurora MySQL o del target di replica dell'istanza database RDS for MySQL, prima di abilitare la replica. Se c'è un problema e devi ristabilire la replica con il cluster di database o il target di replica dell'istanza database, puoi ripristinare il cluster di database o l'istanza database da questa snapshot invece di dover importare di nuovo i dati nel target di replica. Utilizza le istruzioni seguenti per attivare la replica del motore di database. | Motore del database | Istruzioni | | --- | --- | | Aurora MySQL | **Per abilitare la replica da un cluster di database Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Per utilizzare la crittografia SSL, imposta il valore finale su `1` anziché `0`. | | RDS per MySQL | **Per abilitare la replica da un'istanza database Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Per utilizzare la crittografia SSL, imposta il valore finale su `1` anziché `0`. | | MySQL (esterno) | **Per abilitare la replica da un database esterno MySQL;** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | Se la replica fallisce, può verificarsi un notevole aumento dei dati involontari I/O sulla replica, con conseguente peggioramento delle prestazioni. Se la replica non riesce o non è più necessaria, è possibile eseguire 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) per rimuovere la configurazione della replica. ### Definire una posizione per arrestare la replica su una replica di lettura In Aurora MySQL versione 3.04 e successive, puoi avviare una replica e quindi arrestarla in una posizione di file di log binario specifica mediante la stored procedure [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). **Per avviare la replica su una replica di lettura e arrestare la replica in corrispondenza di una posizione specifica** 1. Utilizzando un client MySQL, stabilisci una connessione al cluster di database Aurora MySQL di replica come utente master. 1. Eseguire la procedura archiviata [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). L'esempio seguente avvia la replica e replica le modifiche fino a raggiungere la posizione `120` nel file di log binario `mysql-bin-changelog.000777`. In caso di disaster recovery, presumere che la posizione `120` si riferisca al momento immediatamente precedente l'errore. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` La replica si arresta automaticamente quando viene raggiunto il punto di arresto. Viene generato il seguente evento RDS: `Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure`. Se si utilizza la replica basata su GTID, scegliere la stored procedure [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL versione 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) invece della [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Per ulteriori informazioni sulla replica basata su GTID, consultare [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). ## 7. Monitora la replica Quando imposti la replica MySQL con un cluster di database Aurora MySQL, devi monitorare gli eventi di failover per il cluster di database Aurora MySQL quando è il target di replica. Se accade un failover, il cluster di database che è il target di replica potrebbe essere ricreato in un nuovo host con un indirizzo di rete diverso. Per informazioni su come monitorare gli eventi di failover, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md). È anche possibile monitorare quanto è indietro la destinazione della replica rispetto all'origine eseguendo la connessione alla destinazione della replica e il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3). Nell'output del comando, il campo `Seconds Behind Master` indica quanto è indietro il target di replica rispetto al master di replica. **Importante** Se aggiorni il tuo cluster di database e specifichi un gruppo di parametri personalizzati, assicurati di riavviare manualmente il cluster al termine dell’aggiornamento. In questo modo il cluster utilizza le nuove impostazioni dei parametri personalizzati e riavvia la replica dei log binari. ## Sincronizzazione delle password tra origine di replica e destinazione Quando si modificano gli account utente e le password nell'origine di replica utilizzando le istruzioni SQL, tali modifiche vengono replicate automaticamente nella destinazione di replica. Se si utilizza l'API Console di gestione AWS AWS CLI, the o RDS per modificare la password principale sull'origine della replica, tali modifiche non vengono replicate automaticamente nella destinazione di replica. Se si desidera sincronizzare l'utente principale e la password principale tra il sistema di origine e quello di destinazione, è necessario apportare la stessa modifica alla destinazione di replica. # Arresto del processo di replica dei log binari per Aurora MySQL Per fermare la replica dei log binari con un'istanza database MySQL, un database MySQL esterno o un altro cluster di database Aurora, segui questa procedura, che viene illustrata nel dettaglio nel seguente argomento. [1. Arrestare la replica dei log binari nella destinazione di replica](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication) [2. Disabilitare l'accesso binario alla fonte di replica](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging) ## 1. Arrestare la replica dei log binari nella destinazione di replica Usa le seguenti istruzioni per arrestare la replica dei log binari del motore di database. | Motore del database | Istruzioni | | --- | --- | | Aurora MySQL | **Per arrestare la replica dei log binari in una destinazione di replica del cluster di database Aurora MySQL** Esegui la connessione al cluster di database Aurora che è la destinazione della replica e chiama la procedura [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). | | RDS per MySQL | **Per arrestare la replica binlog in un'istanza database Amazon RDS** Esegui la connessione all'istanza database RDS che è la destinazione della replica e chiama la procedura [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). | | MySQL (esterno) | **Per fermare la replica dei log binari in un database MySQL esterno** Connettiti al database MySQL ed esegui il comando`STOP SLAVE` (versione 5.7) o `STOP REPLICA` (versione 8.0). | ## 2. Disabilitare l'accesso binario alla fonte di replica Usa le seguenti istruzioni per disattivare la registrazione dei log binari nell'origine della replica per il motore del database. | Motore del database | Istruzioni | | --- | --- | | Aurora MySQL | **Per disabilitare l'accesso binario in un cluster di database Amazon Aurora** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) | | RDS for MySQL | **Per disabilitare l'accesso binario in un'istanza database Amazon RDS** Non è possibile abilitare l'accesso binario direttamente per un'istanza database Amazon RDS, ma è possibile abilitarlo procedendo come di seguito: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) | | MySQL (esterno) | **Per disabilitare l'accesso binario a un database esterno MySQL** Esegui la connessione al database MySQL e chiama il comando `STOP REPLICATION`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) | # Dimensionamento delle letture per il database MySQL con Amazon Aurora Puoi utilizzare Amazon Aurora con l'istanza database MySQL per usufruire delle funzionalità di dimensionamento della lettura di Amazon Aurora ed espandere il reale carico di lavoro della tua istanza database MySQL. Per utilizzare Aurora per ridimensionare le operazioni di lettura dell'istanza database MySQL, crea un cluster di database Amazon Aurora MySQL e rendilo una replica di lettura per l'istanza database MySQL. Ciò si applica a un'istanza database RDS per MySQL o a un database MySQL in esecuzione esternamente a Amazon RDS. Per informazioni su come creare un cluster di database Amazon Aurora, consulta [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md). Quando si configura la replica tra l'istanza database MySQL e il cluster di database Amazon Aurora, assicurarsi di seguire queste linee guida: + Utilizzare l'indirizzo dell'endpoint del cluster di database di Amazon Aurora quando si fa riferimento al cluster di database Amazon Aurora MySQL. Se si verifica un failover, la replica di Aurora promossa a istanza principale per il cluster di database Aurora MySQL continua a utilizzare l'indirizzo dell'endpoint del cluster di database. + Conservare i binlog sull'istanza di scrittura finché non si ha la conferma che siano stati applicati alla replica di Aurora. Questa manutenzione assicura il ripristino dell'istanza di lettura nel caso di errori. **Importante** Quando si utilizza la replica auto-gestita, si ha la responsabilità di monitorare e risolvere eventuali problemi di replica. Per ulteriori informazioni, consulta [Diagnosi e risoluzione del ritardo tra repliche di lettura](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag). **Nota** Le autorizzazioni richieste per avviare la replica su un cluster di database Aurora MySQL sono limitate e non disponibili per l'utente master Amazon RDS. Pertanto sarà necessario utilizzare le procedure [mysql.rds\$1set\$1external\$1master (Aurora MySQL versione 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) o [mysql.rds\$1set\$1external\$1source (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) per impostare la replica tra il cluster di database Aurora MySQL e l'istanza database MySQL. ## Avvio della replica tra un'istanza di origine esterna e un cluster di database Aurora MySQL 1. Rendere di sola lettura l'istanza database MySQL di origine: ``` mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON; ``` 1. Eseguire il comando `SHOW MASTER STATUS` nell'istanza database MySQL di origine per determinare la posizione di binlog. Viene restituito un output simile all'esempio seguente: ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` 1. Copia il database dall'istanza database MySQL esterna al cluster di database Amazon Aurora MySQL utilizzando `mysqldump`. Per database di dimensioni particolarmente elevate, è possibile utilizzare la procedura descritta in [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) nella *Guida per l’utente di Amazon Relational Database Service*. Per Linux, macOS o Unix: ``` mysqldump \ --databases \ --single-transaction \ --compress \ --order-by-primary \ -u local_user \ -p local_password | mysql \ --host aurora_cluster_endpoint_address \ --port 3306 \ -u RDS_user_name \ -p RDS_password ``` Per Windows: ``` mysqldump ^ --databases ^ --single-transaction ^ --compress ^ --order-by-primary ^ -u local_user ^ -p local_password | mysql ^ --host aurora_cluster_endpoint_address ^ --port 3306 ^ -u RDS_user_name ^ -p RDS_password ``` **Nota** Assicurati che non siano presenti spazi tra l'opzione `-p` e la password immessa. Utilizza le opzioni `--host`, `--user (-u)`, `--port` e `-p` nel comando `mysql` per specificare il nome host, il nome utente e la password per eseguire la connessione al cluster di database Aurora. Il nome host è il nome DNS per l'endpoint del cluster di database Amazon Aurora, ad esempio, `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`. Il valore dell'endpoint è disponibile nei dettagli del cluster nella console di gestione Amazon RDS. 1. Rendere nuovamente scrivibile l'istanza database MySQL di origine: ``` mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES; ``` Per ulteriori informazioni sulla creazione di backup da utilizzare con la replica, vedere [http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html) nella documentazione di MySQL. 1. Nella console di gestione Amazon RDS aggiungi l'indirizzo IP del server che ospita il database MySQL di origine al gruppo di sicurezza VPC per il cluster di database Amazon Aurora. 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 di database Amazon Aurora, affinché possa comunicare con l'istanza di MySQL di origine. Per individuare l'indirizzo IP del cluster di database Amazon Aurora, utilizzare il comando `host`. ``` host aurora_endpoint_address ``` Il nome host è il nome DNS dell'endpoint del cluster di database Amazon Aurora. 1. Utilizzando il client scelto, eseguire la connessione all'istanza di MySQL esterna e creare un utente MySQL 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. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Per un'istanza di MySQL esterna, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente della replica. Per concedere ad esempio i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente "`repl_user`" del proprio dominio, eseguire questo comando. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Acquisire uno snapshot manuale del cluster di database Aurora MySQL da impostare come replica di lettura prima di impostare la replica. Se è necessario ridefinire la replica con il cluster di database come replica di lettura, è possibile ripristinare il cluster di database Aurora MySQL da tale snapshot anziché dover importare i dati dall'istanza database MySQL in un nuovo cluster di database Aurora MySQL. 1. Configurare il cluster di database Amazon Aurora come replica. Esegui la connessione al cluster di database Amazon Aurora come utente master e identifica il database MySQL di origine come origine di replica utilizzando [mysql.rds\$1set\$1external\$1master (Aurora MySQL versione 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) o le procedure [mysql.rds\$1set\$1external\$1source (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication). Utilizza il nome e la posizione del file binlog, recuperati nella fase 2. Di seguito è riportato un esempio di : ``` For Aurora MySQL version 2: CALL mysql.rds_set_external_master ('mymasterserver.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3: CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); ``` 1. Nel cluster di database Amazon Aurora chiama la procedura [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) per avviare la replica. ``` CALL mysql.rds_start_replication; ``` Dopo aver definito la replica tra l'istanza database MySQL di origine e il cluster di database Amazon Aurora sarà possibile aggiungere le repliche di Aurora al cluster di database Amazon Aurora. È possibile quindi connettere le repliche di Aurora per il dimensionamento della lettura dei dati. Per informazioni sulla creazione di una replica di Aurora, consulta [Aggiunta di repliche di Aurora a un cluster di database](aurora-replicas-adding.md). # Ottimizzazione della replica dei log binari per Aurora MySQL Di seguito, è possibile imparare a ottimizzare le prestazioni di replica dei log binari e risolvere i problemi correlati in Aurora MySQL. **Suggerimento** Questa discussione presuppone che tu abbia familiarità con il meccanismo di replica dei log binari MySQL e del suo funzionamento. Per informazioni di base, consulta [Implementazione della replica](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) nella documentazione di MySQL. ## Replica dei log binari multithread Con la replica del log binario multithread, un thread SQL legge gli eventi dal log di inoltro e li mette in coda per l'applicazione dei thread SQL worker. I thread di lavoro SQL sono gestiti dal thread coordinatore. Gli eventi di log binari vengono applicati in parallelo quando possibile. Il livello di parallelismo dipende da fattori quali versione, parametri, progettazione dello schema e caratteristiche del carico di lavoro. La replica dei log binari multithread è supportata in Aurora MySQL versione 3 e Aurora MySQL 2.12.1 e versioni successive. Affinché una replica multithread elabori in modo efficiente gli eventi dei log binari in parallelo, è necessario configurare l’origine per la replica dei log binari multithread, la quale dovrà utilizzare una versione che includa le informazioni sul parallelismo nei file di log binari. Quando un’istanza database Aurora MySQL è configurata per l’utilizzo della replica dei log binari, per impostazione predefinita l’istanza di replica utilizza la replica a thread singolo per le versioni precedenti alla 3.04 di Aurora MySQL. Per abilitare la replica multithread, si aggiorna il parametro `replica_parallel_workers` a un valore maggiore di `1` nel gruppo di parametri personalizzati. Per Aurora MySQL 3.04 e versioni successive, la replica è multithread per impostazione predefinita, con `replica_parallel_workers` impostato su `4`. È possibile modificare questo parametro nel gruppo di parametri personalizzato. Per aumentare la resilienza del database contro arresti imprevisti, ti consigliamo di abilitare la replica GTID sull'origine e di GTIDs consentirla sulla replica. Per consentire la replica GTID, si imposta `gtid_mode` su `ON_PERMISSIVE` sia sull’origine sia sulla replica. Per ulteriori informazioni sulla replica basata su GTID, consultare [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). Le opzioni di configurazione seguenti consentono di ottimizzare la replica multithread. Per informazioni sull'utilizzo, consulta [Opzioni e variabili di replica e registrazione binaria](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html) nel *Manuale di riferimento MySQL*. Per ulteriori informazioni sulla replica multithread, consulta il blog MySQL [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/). I valori ottimali dei parametri dipendono da diversi fattori. Ad esempio, le prestazioni per la replica dei log binari sono influenzate dalle caratteristiche del carico di lavoro del database e dalla classe di istanza database su cui è in esecuzione la replica. Pertanto, si consiglia di testare con attenzione tutte le modifiche apportate a questi parametri di configurazione prima di applicare nuove impostazioni di parametro a un’istanza di produzione: + `binlog_format recommended value` impostato su `ROW` + `binlog_group_commit_sync_delay` + `binlog_group_commit_sync_no_delay_count` + `binlog_transaction_dependency_history_size` + `binlog_transaction_dependency_tracking`, il valore consigliato è `WRITESET` + `replica_preserve_commit_order` + `replica_parallel_type`, il valore consigliato è `LOGICAL_CLOCK` + `replica_parallel_workers` + `replica_pending_jobs_size_max` + `transaction_write_set_extraction`, il valore consigliato è `XXHASH64` Le caratteristiche dello schema e del carico di lavoro sono fattori che influiscono sulla replica in parallelo. Di seguito sono riportati i fattori più comuni. + Assenza di chiavi primarie: RDS non è in grado di stabilire la dipendenza writeset per le tabelle senza chiavi primarie. Con il formato `ROW`, è possibile eseguire una singola istruzione su più righe con un’unica scansione completa della tabella sull’origine, ma si ottiene una scansione completa della tabella per ogni riga modificata sulla replica. L’assenza di chiavi primarie riduce in modo significativo il throughput di replica. + Presenza di chiavi esterne: se sono presenti chiavi esterne, Amazon RDS non può utilizzare la dipendenza writeset per il parallelismo delle tabelle con la relazione delle chiavi esterne. + Dimensione delle transazioni: se una singola transazione si estende su dozzine o centinaia di megabyte o gigabyte, il thread coordinatore e uno dei thread di lavoro potrebbero impiegare molto tempo solo per elaborare quella transazione. Durante questo periodo, tutti gli altri thread di lavoro potrebbero rimanere inattivi dopo aver completato l’elaborazione delle transazioni precedenti. In Aurora MySQL 3.06 e versioni successive, è possibile migliorare le prestazioni delle repliche di log binari durante la replica delle transazioni per tabelle di grandi dimensioni con più di un indice secondario. Questa funzionalità introduce un pool di thread per applicare le modifiche dell’indice secondario in parallelo su una replica di log binari. La funzionalità è controllata dal parametro del cluster di database `aurora_binlog_replication_sec_index_parallel_workers`, che controlla il numero totale di thread paralleli disponibili per applicare le modifiche dell’indice secondario. Per impostazione predefinita, il parametro è impostato su `0` (disabilitato). L’abilitazione di questa funzionalità non richiede il riavvio dell’istanza. Per abilitare questa funzionalità, arrestare la replica in corso, impostare il numero desiderato di thread di lavoro paralleli e quindi riavviare la replica. ## Ottimizzazione della replica dei log binari In Aurora MySQL 2.10 e versioni successive, Aurora applica automaticamente un'ottimizzazione nota come cache binlog alla replica dei log binari. I/O Inserendo nella cache gli eventi binlog più recenti, questa ottimizzazione è progettata per migliorare le prestazioni del thread di dump di binlog limitando al contempo l'impatto sulle transazioni in primo piano sull'istanza di origine binlog. **Nota** Questa memoria utilizzata per questa funzione è indipendente dall'impostazione `binlog_cache` MySQL. Questa funzione non si applica alle istanze DB Aurora che utilizzano le classi di istanza `db.t2` e `db.t3`. Non è necessario regolare alcun parametro di configurazione per attivare questa ottimizzazione. In particolare, se il parametro di configurazione `aurora_binlog_replication_max_yield_seconds` è stato impostato su un valore diverso da zero nelle versioni precedenti di Aurora MySQL, impostarlo su zero per le versioni attualmente disponibili. Le variabili `aurora_binlog_io_cache_reads` di stato `aurora_binlog_io_cache_read_requests` aiutano a monitorare la frequenza con cui i dati vengono letti dalla cache binlog. I/O + `aurora_binlog_io_cache_read_requests`mostra il numero di richieste di I/O lettura binlog dalla cache. + `aurora_binlog_io_cache_reads`mostra il numero di I/O letture binlog che recuperano informazioni dalla cache. La seguente query SQL calcola la percentuale di richieste di lettura binlog che sfruttano le informazioni memorizzate nella cache. In questo caso, più il rapporto è vicino a 100, migliore è. ``` mysql> SELECT (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads') / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests') * 100 as binlog_io_cache_hit_ratio; +---------------------------+ | binlog_io_cache_hit_ratio | +---------------------------+ | 99.99847949080622 | +---------------------------+ ``` La funzionalità di I/O cache binlog include anche nuove metriche relative ai thread di dump binlog. I *thread di dump* sono i thread creati quando le nuove repliche di binlog sono collegate all'istanza fonte binlog. I parametri del thread di dump vengono stampati nel log del database ogni 60 secondi con il prefisso `[Dump thread metrics]`. I parametri includono informazioni per ogni replica binlog, ad esempio `Secondary_id`, `Secondary_uuid`, il nome del file binlog e la posizione in cui ogni replica sta leggendo. I parametri includono anche `Bytes_behind_primary` che rappresenta la distanza in byte tra l'origine della replica e la replica. Questa metrica misura il ritardo del thread di replica. I/O Tale cifra è diversa dal ritardo del thread dell'applicatore SQL della replica, rappresentato dal parametro `seconds_behind_master` sulla replica binlog. È possibile determinare se le repliche di binlog stiano recuperando l'origine o rimangano indietro controllando se la distanza diminuisce o aumenta. ## Log di inoltro in memoria In Aurora MySQL versione 3.10 e versioni successive, Aurora introduce un’ottimizzazione nota come log di inoltro in memoria per migliorare il throughput della replica. Questa ottimizzazione migliora le I/O prestazioni del relay log memorizzando nella cache tutto il contenuto del relay log intermedio in memoria. Di conseguenza, riduce la latenza di commit riducendo al minimo I/O le operazioni di archiviazione poiché il contenuto del relay log rimane facilmente accessibile in memoria. Per impostazione predefinita, la funzionalità di log di inoltro in memoria è abilitata automaticamente per gli scenari di replica gestiti da Aurora (incluse implementazioni blu/verdi, replica Aurora-Aurora e repliche tra Regioni) quando la replica soddisfa una di queste configurazioni: + Modalità di replica a thread singolo (replica\$1parallel\$1workers = 0) + Replica multithread con modalità GTID abilitata: + Posizionamento automatico abilitato + Modalità GTID impostata su ON per la replica + Replica basata su file con replica\$1preserve\$1commit\$1order = ON La funzionalità di log di inoltro in memoria è supportata su classi di istanza più grandi di t3.large, ma non è disponibile sulle istanze Aurora Serverless. Il buffer circolare del log di inoltro ha una dimensione fissa di 128 MB. Per monitorare il consumo di memoria di questa funzionalità, è possibile eseguire la seguente query: ``` SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache'; ``` La funzionalità di log di inoltro in memoria è controllata dal parametro aurora\$1in\$1memory\$1relaylog, che può essere impostato a livello di istanza o di cluster di database. È possibile abilitare o disabilitare questa funzionalità in modo dinamico senza riavviare l’istanza: 1. Arrestare la replica in corso 1. Impostare aurora\$1in\$1memory\$1relaylog su ON (per abilitare) o OFF (per disabilitare) nel gruppo di parametri 1. Riavviare la replica Esempio: ``` CALL mysql.rds_stop_replication; set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group CALL mysql.rds_start_replication; ``` Anche quando aurora\$1in\$1memory\$1relaylog è impostato su ON, la funzionalità di log di inoltro in memoria potrebbe comunque essere disabilitata in determinate condizioni. Per verificare lo stato corrente della funzionalità, è possibile utilizzare il seguente comando: ``` SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status'; ``` Se la funzionalità viene disabilitata in modo imprevisto, è possibile identificarne il motivo eseguendo il seguente comando: ``` SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason'; ``` Questo comando restituisce un messaggio che spiega perché la funzionalità è attualmente disabilitata. # Configurazione del file di log binario avanzato per Aurora MySQL Il file di log binario avanzato riduce il sovraccarico delle prestazioni di elaborazione causato dall'attivazione del file di log binario, che in alcuni casi può arrivare fino al 50%. Con il file di log binario avanzato, questo sovraccarico può essere ridotto a circa il 13%. Per ridurre il sovraccarico, il file di log binario avanzato scrive i log binari e i log delle transazioni nello spazio di archiviazione in parallelo, il che riduce al minimo i dati scritti al momento del commit della transazione. L'utilizzo del file di log binario avanzato migliora anche i tempi di ripristino del database dopo riavvii e failover fino al 99% rispetto al file di log binario della community MySQL. Il file di log binario avanzato è compatibile con i carichi di lavoro esistenti basati sul file di log binario e viene utilizzato nello stesso modo in cui si utilizza il file di log binario della community MySQL. Il file di log binario avanzato è disponibile in Aurora MySQL versione 3.03.1 e successive. **Topics** + [ ## Configurazione dei parametri del file di log binario avanzato ](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters) + [ ## Altri parametri correlati ](#AuroraMySQL.Enhanced.binlog.other.parameters) + [ ## Differenze tra file di log binario avanzato e file di log binario avanzato della community MySQL ](#AuroraMySQL.Enhanced.binlog.differences) + [ ## Metriche Amazon CloudWatch per il file di log binario avanzato ](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics) + [ ## Limitazioni del file di log binario avanzato ](#AuroraMySQL.Enhanced.binlog.limitations) ## Configurazione dei parametri del file di log binario avanzato È possibile passare dal file di log binario della community MySQL al file di log binario avanzato attivando/disattivando i relativi parametri. Gli utenti esistenti di file di log binario possono continuare a leggere e consumare i file di log binario senza interruzioni nella sequenza di file di log binario. Per attivare il file di log binario avanzato, imposta i seguenti parametri: | Parametro | Predefinito | Descrizione | | --- | --- | --- | | binlog\$1format | – | Impostare il parametro binlog\$1format sul formato di registrazione binaria desiderato per attivare il file di log binario avanzato. Assicurarsi che binlog\$1format parameter non sia impostato su OFF. Per ulteriori informazioni, consultare [Configurazione del log binario di Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html). | | aurora\$1enhanced\$1binlog | 0 | Impostare il valore di questo parametro su 1 nel gruppo di parametri del cluster database associato al cluster Aurora MySQL. Quando si modifica il valore di questo parametro, è necessario riavviare l'istanza di scrittura quando il valore di DBClusterParameterGroupStatus viene visualizzato come pending-reboot. | | binlog\$1backup | 1 | Disattivare questo parametro per attivare il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 0. | | binlog\$1replication\$1globaldb | 1 | Disattivare questo parametro per attivare il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 0. | **Importante** È possibile disattivare i parametri `binlog_backup` e `binlog_replication_globaldb`  solo in caso di utilizzo del file di log binario avanzato. Per disattivare il file di log binario avanzato, imposta i seguenti parametri: | Parametro | Descrizione | | --- | --- | | aurora\$1enhanced\$1binlog | Impostare il valore di questo parametro su 0 nel gruppo di parametri del cluster database associato al cluster Aurora MySQL. Ogni volta che si modifica il valore di questo parametro, è necessario riavviare l'istanza di scrittura quando il valore di DBClusterParameterGroupStatus viene visualizzato come pending-reboot. | | binlog\$1backup | Attivare questo parametro quando si disattiva il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 1. | | binlog\$1replication\$1globaldb | Attivare questo parametro quando si disattiva il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 1. | Per verificare se il file di log binario avanzato è attivo, usare il seguente comando nel client MySQL: ``` mysql>show status like 'aurora_enhanced_binlog'; +------------------------+--------+ | Variable_name | Value | +------------------------+--------+ | aurora_enhanced_binlog | ACTIVE | +------------------------+--------+ 1 row in set (0.00 sec) ``` Quando il file di log binario avanzato è attivo, l'output mostra `ACTIVE` per `aurora_enhanced_binlog`. ## Altri parametri correlati Quando si attiva il file di log binario avanzato, questa operazione interessa i seguenti parametri: + Il parametro `max_binlog_size` è visibile ma non modificabile. Il relativo valore predefinito `134217728` viene impostato automaticamente su `268435456` quando il file di log binario avanzato è attivato. + A differenza file di log binario avanzato della community MySQL, `binlog_checksum` non agisce come parametro dinamico quando il file di log binario avanzato è attivato. Affinché la modifica a questo parametro abbia effetto, è necessario riavviare manualmente il cluster database anche quando `ApplyMethod` è `immediate`. + Il valore impostato per il parametro `binlog_order_commits` non ha alcun effetto sull'ordine dei commit quando il file di log binario avanzato è attivato. I commit vengono sempre ordinati senza ulteriori implicazioni in termini di prestazioni. ## Differenze tra file di log binario avanzato e file di log binario avanzato della community MySQL Il file di log binario avanzato interagisce in modo diverso con i cloni, i backup e il database globale Aurora rispetto al file di log binario avanzato di Community MySQL. Si consiglia di analizzare le seguenti differenze prima di utilizzare il file di log binario avanzato. + I file di log binario avanzati del cluster di database di origine non sono disponibili su un cluster di database clonato. + I file di log binario avanzati non sono inclusi nei backup di Aurora. Pertanto, i file di log binario avanzati del cluster database di origine non sono disponibili dopo il ripristino di un cluster database nonostante il relativo periodo di conservazione impostato. + Se utilizzati con un database globale Aurora, i file di log binario avanzati del cluster database primario non vengono replicati nel cluster database nelle regioni secondarie. ****Examples** (Esempi)** Negli esempi seguenti vengono illustrate le differenze tra file di log binario avanzati e file di log binario della community MySQL. **Su un cluster database ripristinato o clonato** Quando il file di log binario avanzato è attivato, i file di log binario storici non sono disponibili nel cluster database ripristinato o clonato. Dopo un'operazione di ripristino o clonazione, se il file di log binario è attivato, il nuovo cluster database inizia a scrivere la propria sequenza di file di log binario a partire da 1 (mysql-bin-changelog.000001). Per attivare il file di log binario avanzato dopo un'operazione di ripristino o clonazione, impostare i parametri del cluster database richiesti sul cluster database ripristinato o clonato. Per ulteriori informazioni, consulta [Configurazione dei parametri del file di log binario avanzato](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters). **Example Esempio: operazione di clonazione o ripristino eseguita con il file di log binario avanzato attivato** Cluster database di origine: ``` mysql> show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | | mysql-bin-changelog.000003 | 156 | No | | mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog turned on | mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog turned on | mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog turned on +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` In un cluster database ripristinato o clonato, non viene eseguito il backup dei file di log binario quando è attivato il file di log binario avanzato. Per evitare discontinuità nei dati del file di log binario, non sono disponibili nemmeno i file di log binario scritti prima di attivare il file di log binario avanzato. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | --> New sequence of Binlog files +----------------------------+-----------+-----------+ 1 row in set (0.00 sec) ``` **Example Esempio: operazione di clonazione o ripristino eseguita con il file di log binario avanzato disattivato** Cluster di database di origine: ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` Il file di log binario avanzato viene disabilitato dopo `mysql-bin-changelog.000003`. In un cluster database ripristinato o clonato, sono disponibili file di log binario scritti dopo aver disattivato il file di log binario avanzato. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 1 row in set (0.00 sec) ``` **Su un database globale Amazon Aurora** Su un database globale Amazon Aurora, i dati del file di log binario del cluster database primario non vengono replicati nei cluster database secondari. Dopo un processo di failover tra regioni, i dati del file di log binario non sono disponibili nel cluster database primario appena promosso. Se il file di log binario è attivato, il cluster database appena promosso avvia la propria sequenza di file di log binario, a partire da 1 (mysql-bin-changelog.000001). Per attivare il file di log binario avanzato dopo il failover, è necessario impostare i parametri del cluster database richiesti sul cluster database secondario. Per ulteriori informazioni, consulta [Configurazione dei parametri del file di log binario avanzato](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters). **Example Esempio: operazione di failover globale del database eseguita con il file di log binario avanzato attivato** Vecchio cluster database primario (prima del failover): ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | | mysql-bin-changelog.000003 | 156 | No | | mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog enabled +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` Nuovo cluster database primario (dopo il failover): I file di log binario non vengono replicati nelle regioni secondarie quando il file di log binario avanzato è attivato. Per evitare discontinuità nei dati del file di log binario, i file di log binario scritti prima di attivare il file di log binario avanzato non sono disponibili. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | --> Fresh sequence of Binlog files +----------------------------+-----------+-----------+ 1 row in set (0.00 sec) ``` **Example Esempio: operazione di failover globale del database eseguita con il file di log binario avanzato disattivato** Cluster database di origine: ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` **Cluster database ripristinato o clonato:** Il file di log binario avanzato viene disabilitato dopo `mysql-bin-changelog.000003`. I file di log binario scritti dopo aver disattivato il file di log binario avanzato vengono replicati e sono disponibili nel cluster database appena promosso. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 3 rows in set (0.00 sec) ``` ## Metriche Amazon CloudWatch per il file di log binario avanzato Le seguenti metriche di Amazon CloudWatch vengono pubblicate solo quando il file di log binario avanzato è attivato. | Parametro CloudWatch | Descrizione | unità | | --- | --- | --- | | ChangeLogBytesUsed | Quantità di spazio di archiviazione in byte utilizzato dal file di log binario avanzato. | Byte | | ChangeLogReadIOPs | Numero di operazioni I/O di lettura eseguite nel file di log binario avanzato in intervalli di 5 minuti. | Conteggio per 5 minuti | | ChangeLogWriteIOPs | Numero di operazioni I/O di scrittura su disco eseguite nel file di log binario avanzato in intervalli di 5 minuti. | Conteggio per 5 minuti | ## Limitazioni del file di log binario avanzato Le seguenti limitazioni si applicano ai cluster database Amazon Aurora quando il file di log binario avanzato è attivato. + Il file di log binario avanzato è supportato solo in Aurora MySQL versione 3.03.1 e successive. + I file di log binario avanzati scritti sul cluster database primario non vengono copiati nei cluster database clonati o ripristinati. + Se utilizzati con un database globale Amazon Aurora, i file di log binario avanzati del cluster database primario non vengono replicati nei cluster database secondari. Pertanto, dopo il processo di failover, i dati dei file di log binario storici non sono disponibili nel nuovo cluster database primario. + I seguenti parametri di configurazione del file di log binario vengono ignorati: + `binlog_group_commit_sync_delay` + `binlog_group_commit_sync_no_delay_count` + `binlog_max_flush_queue_time` + Non è possibile eliminare o rinominare una tabella danneggiata in un database. Per eliminare queste tabelle, è possibile contattare Supporto. + La cache I/O del file di log binario è disabilitata quando il file di log binario avanzato è attivato. Per ulteriori informazioni, consulta [Ottimizzazione della replica dei log binari per Aurora MySQL](binlog-optimization.md). **Nota** Il file di log binario avanzato è caratterizzato da miglioramenti delle prestazioni di lettura simili a quelli della cache I/O del file di log binario e da ulteriori ottimizzazioni delle prestazioni di scrittura. + La funzionalità Backtrack non è supportata. Il file di log binario avanzato non può essere attivato in un cluster database nelle seguenti condizioni: + Cluster database con la funzionalità Backtrack abilitata. + Cluster di database con la funzionalità Backtrack precedentemente abilitata, ma non disattivata. + Cluster database ripristinato da un cluster database di origine o da uno snapshot con la funzionalità Backtrack abilitata. # Utilizzo della replica basata su GTID Di seguito sono riportate le indicazioni per utilizzare gli identificatori di transazione globali (GTID) con la replica basata sui log binari (binlog) tra un cluster Aurora MySQL e un’origine esterna. **Nota** Per Aurora, puoi utilizzare questa caratteristica solo con i cluster Aurora MySQL che utilizzano la replica basata sui registri binari verso o da un database MySQL esterno. L'altro database può essere un'istanza Amazon RDS MySQL, un database MySQL On-Premise o un cluster di database Aurora in una Regione AWS diversa. Per sapere come configurare questo tipo di replica, consultare [Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)](AuroraMySQL.Replication.MySQL.md). Se si utilizza la replica basata su binlog e non si ha familiarità con la replica basata su GTID con MySQL, consulta [Replication with global transaction identifiers](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) nella documentazione MySQL. La replica basata su GTID è supportata per Aurora MySQL versione 2 e 3. **Topics** + [ ## Identificatori globali di transazione (GTID) ](#mysql-replication-gtid.overview) + [ ## Parametri per la replica basata su GTID ](#mysql-replication-gtid.parameters) + [ # Abilitazione della replica basata su GTID per un cluster Aurora MySQL ](mysql-replication-gtid.configuring-aurora.md) + [ # Disabilitazione della replica basata su GTID per un cluster DB Aurora MySQL ](mysql-replication-gtid.disabling.md) ## Identificatori globali di transazione (GTID) *Gli identificatori globali di transazione (GTID)* sono identificatori univoci generati per le transazioni MySQL sottoposte a commit. Puoi utilizzare i GTID per semplificare la replica basata sui log binari e facilitare la risoluzione dei problemi. **Nota** Quando Aurora sincronizza i dati tra le istanze database in un cluster, tale meccanismo di replica non coinvolge i log binari (binlog). Per Aurora MySQL, la replica basata su GTID si applica solo quando si utilizza anche la replica basata sui log binari per replicare un database esterno compatibile con MySQL verso o da un cluster di database di Aurora MySQL. MySQL utilizza due diversi tipi di transazioni per la replica basata sui log binari: + *Transazioni GTID* – Transazioni identificate da un GTID. + *Transazioni anonime* – Transazioni a cui non è assegnato un GTID. In una configurazione di replica, i GTID sono univoci in tutte le istanze database. I GTID semplificano la configurazione della replica perché, quando vengono utilizzati, non è necessario fare riferimento alle posizioni nel file di log. I GTID semplificano anche la registrazione delle transazioni replicate e verificano che l’istanza di origine e le repliche siano coerenti. In genere si utilizza la replica basata su GTID con Aurora durante la replica da un database esterno compatibile con MySQL verso un cluster Aurora. Puoi configurare questa configurazione di replica come parte di una migrazione da un database locale o Amazon RDS verso Aurora MySQL. Se il database esterno utilizza già i GTID, l'abilitazione della replica basata su GTID per il cluster Aurora semplifica il processo di replica. Configuri la replica basata su GTID per un cluster Aurora MySQL impostando innanzitutto i parametri di configurazione rilevanti in un gruppo di parametri del cluster di database. Quindi associ tale gruppo di parametri al cluster. ## Parametri per la replica basata su GTID Utilizzare i parametri seguenti per configurare la replica basata su GTID. | Parametro | Valori validi | Descrizione | | --- | --- | --- | | `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` indica che le nuove transazioni sono anonime, ovvero non hanno GTID, e che una transazione deve essere anonima per poter essere replicata. `OFF_PERMISSIVE` indica che le nuove transazioni sono anonime, ma tutte le transazioni possono essere replicate. `ON_PERMISSIVE` indica che le nuove transazioni hanno GTID assegnati, ma tutte le transazioni possono essere replicate. `ON` indica che le nuove transazioni hanno GTID assegnati e che una transazione deve avere un GTID per poter essere replicata. | | `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` consente alle transazioni di violare la coerenza GTID. `ON` impedisce alle transazioni di violare la coerenza GTID. `WARN` consente alle transazioni di violare la consistenza GTID, ma genera un avviso quando si verifica una violazione. | **Nota** Nella Console di gestione AWS, il parametro `gtid_mode` viene visualizzato come `gtid-mode`. Per la replica basata su GTID, utilizza queste impostazioni per il gruppo di parametri del cluster di database per il cluster di database Aurora MySQL: + `ON` e `ON_PERMISSIVE` si applicano solo alla replica in uscita da un cluster Aurora MySQL. Entrambi questi valori fanno sì che il cluster di database Aurora utilizzi i GTID per le transazioni replicate su un database esterno. `ON` richiede che anche il database esterno utilizzi la replica basata su GTID. Per `ON_PERMISSIVE` la replica basata su GTID è opzionale sul database esterno. + `OFF_PERMISSIVE`, se impostato, significa che il cluster di database Aurora può accettare la replica in ingresso da un database esterno. Possono farlo indipendentemente dal fatto che il database esterno utilizzi la replica basata su GTID o meno. + `OFF`, se impostato, significa che il cluster di database Aurora accetta solo la replica in ingresso da database esterni che non utilizzano la replica basata su GTID. **Suggerimento** La replica in ingresso è lo scenario di replica basata sui log binari più comune per i cluster Aurora MySQL. Per la replica in ingresso, ti consigliamo di impostare la modalità GTID su `OFF_PERMISSIVE`. Questa impostazione consente la replica in ingresso da database esterni indipendentemente dalle impostazioni GTID dell'origine della replica. Per ulteriori informazioni sui gruppi di parametri, consultare [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). # Abilitazione della replica basata su GTID per un cluster Aurora MySQL Quando la replica basata su GTID è abilitata per un cluster di database Aurora MySQL, le impostazioni GTID si applicano sia alla replica basata sui log binari in ingresso che a quella in uscita. **Per abilitare la replica basata su GTID per un cluster Aurora MySQL** 1. Creare o modificare un gruppo di parametri del cluster di database utilizzando le seguenti impostazioni dei parametri: + `gtid_mode` – `ON` o `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` 1. Associare il gruppo di parametri del cluster di database al cluster Aurora MySQL. A tale scopo, seguire la procedura descritta in [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). 1. (Facoltativo) Specifica come assegnare i GTID alle transazioni che non li includono. Per eseguire questa operazione, chiama la procedura archiviata in [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL versione 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). # Disabilitazione della replica basata su GTID per un cluster DB Aurora MySQL Puoi disabilitare la replica basata su GTID per un cluster di database Aurora MySQL. Ciò significa che il cluster Aurora non può eseguire la replica basata sui log binari in ingresso o in uscita con database esterni che utilizzano la replica basata su GTID. . **Nota** Nella seguente procedura, *replica di lettura* indica la destinazione della replica in una configurazione Aurora con replica basata sui log binari verso o da un database esterno. Non indica istanze database di replica a sola lettura di Aurora. Ad esempio, quando un cluster Aurora accetta la replica in ingresso da un'origine esterna, l'istanza primaria Aurora funge da replica di lettura per la replica basata sui log binari. Per ulteriori dettagli sulle procedure memorizzate citate in questa sezione, consultare [Informazioni di riferimento sulle stored procedure Aurora MySQL](AuroraMySQL.Reference.StoredProcs.md). **Per disabilitare la replica basata su GTID per un cluster DB Aurora MySQL** 1. Nelle repliche di Aurora, esegui questa procedura: Per la versione 3 ``` CALL mysql.rds_set_source_auto_position(0); ``` Per la versione 2 ``` CALL mysql.rds_set_master_auto_position(0); ``` 1. Reimpostare `gtid_mode` su `ON_PERMISSIVE`. 1. Verificare che il gruppo di parametri del cluster di database associato al cluster di database Aurora MySQL abbia il parametro `gtid_mode` impostato su `ON_PERMISSIVE`. Per ulteriori informazioni sull'impostazione dei parametri di configurazione mediante i gruppi di parametri, consultare [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). 1. Riavvio del cluster di database Aurora MySQL 1. Reimpostare `gtid_mode` su `OFF_PERMISSIVE`. 1. Verificare che il gruppo di parametri del cluster di database associato al cluster di database Aurora MySQL abbia il parametro `gtid_mode` impostato su `OFF_PERMISSIVE`. 1. Riavvio del cluster di database Aurora MySQL 1. Attendere che tutte le transazioni GTID vengano applicate sull'istanza primaria di Aurora. Per verificare che le transazioni siano applicate, esegui queste operazioni: 1. Sull'istanza database primaria di Aurora, esegui il comando `SHOW MASTER STATUS`. L’output visualizzato dovrebbe essere simile al seguente. ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` Annotare il file e la posizione nell'output. 1. In ogni replica di lettura, utilizza le informazioni su file e posizione presenti nell’istanza di origine menzionata nella fase precedente per eseguire la query seguente. Per la versione 3 ``` SELECT SOURCE_POS_WAIT('file', position); ``` Per la versione 2 ``` SELECT MASTER_POS_WAIT('file', position); ``` Ad esempio, se il nome del file è `mysql-bin-changelog.000031` e la posizione è `107`, eseguire l’istruzione seguente. Per la versione 3 ``` SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107); ``` Per la versione 2 ``` SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107); ``` 1. Reimposta i parametri GTID per disabilitare la replica basata su GTID. 1. Verificare che il gruppo di parametri del cluster di database associato al cluster Aurora MySQL abbia le seguenti impostazioni dei parametri: + `gtid_mode` – `OFF` + `enforce_gtid_consistency` – `OFF` 1. Riavvio del cluster di database Aurora MySQL