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à. # Configurazione di cluster attivi-attivi in RDS per MySQL In Amazon RDS, un cluster attivo-attivo è una configurazione di database in cui più nodi gestiscono attivamente le operazioni di lettura e scrittura, distribuendo il carico di lavoro tra le istanze per migliorare la disponibilità e la scalabilità. Ogni nodo del cluster è sincronizzato per mantenere la coerenza dei dati, garantendo un’elevata disponibilità e un failover più rapido in caso di guasto del nodo. È possibile configurare un cluster attivo-attivo in RDS per MySQL utilizzando il plugin di replica di gruppo MySQL. Il plugin di replica di gruppo è supportato per le istanze database RDS per MySQL con le versioni del motore seguenti: + Tutte le versioni di MySQL 8.4 + MySQL 8.0.35 e versioni secondarie successive Per informazioni sulla replica di gruppo MySQL, consulta [ Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication.html) nella documentazione MySQL. La documentazione MySQL contiene informazioni dettagliate su questa funzionalità, mentre il presente argomento descrive come configurare e gestire il plugin nelle istanze database RDS per MySQL. **Nota** Per brevità, tutte le menzioni di cluster “attivo-attivo” in questo argomento si riferiscono ai cluster attivi-attivi che utilizzano il plugin di replica di gruppo MySQL. ## Casi d’uso per cluster attivi-attivi Di seguito sono indicati i casi d’uso in cui è opportuno utilizzare i cluster attivi-attivi: + Applicazioni che richiedono tutte le istanze database nel cluster per supportare le operazioni di scrittura. Il plugin di replica di gruppo mantiene i dati coerenti su ogni istanza database nel cluster attivo-attivo. Per ulteriori informazioni sul funzionamento, consulta [ Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) nella documentazione MySQL. + Applicazioni che richiedono la disponibilità continua del database. In un cluster attivo-attivo i dati vengono mantenuti in tutte le istanze database del cluster. Se in un’istanza database si verifica un errore, l’applicazione può reindirizzare il traffico verso un’altra istanza database del cluster. + Applicazioni per cui può essere necessario suddividere le operazioni di lettura e scrittura tra diversi istanze database del cluster per scopi di bilanciamento del carico. In un cluster attivo-attivo le applicazioni possono inviare traffico di lettura a istanze database specifiche e traffico di scrittura ad altre. È anche possibile cambiare le istanze database a cui inviare letture o scritture in qualsiasi momento. **Topics** + [Casi d’uso per cluster attivi-attivi](#mysql-active-active-clusters-benefits) + [Limitazioni e considerazioni relative ai cluster attivi-attivi](mysql-active-active-clusters-considerations-limitations.md) + [Preparazione per un cluster attivo-attivo tra VPC](mysql-active-active-clusters-cross-vpc-prerequisites.md) + [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md) + [Conversione di un’istanza database esistente in un cluster attivo-attivo](mysql-active-active-clusters-converting.md) + [Configurazione di un cluster attivo-attivo con nuove istanze database](mysql-active-active-clusters-setting-up.md) + [Aggiunta di un’istanza database a un cluster attivo-attivo](mysql-active-active-clusters-adding.md) + [Monitoraggio dei cluster attivi-attivi](mysql-active-active-clusters-monitoring.md) + [Arresto della replica di gruppo in un’istanza database in un cluster attivo-attivo](mysql-active-active-clusters-stopping.md) + [Ridenominazione di un’istanza database in un cluster attivo-attivo](mysql-active-active-clusters-renaming.md) + [Rimozione di un’istanza database da un cluster attivo-attivo](mysql-active-active-clusters-remove.md) # Limitazioni e considerazioni relative ai cluster attivi-attivi In Amazon RDS i cluster attivi-attivi offrono disponibilità e scalabilità migliorate grazie alla possibilità di distribuire i carichi di lavoro su più istanze. Quando si utilizza questa architettura, tuttavia, è necessario tenere presente alcune limitazioni e considerazioni importanti. Nelle sezioni seguenti vengono descritti fattori chiave come i ritardi di replica, la risoluzione dei conflitti, l’allocazione delle risorse e il comportamento di failover. È importante comprendere queste considerazioni per garantire prestazioni e affidabilità ottimali nelle implementazioni di cluster attivi-attivi. **Topics** + [Limitazioni per i cluster attivi-attivi in RDS per MySQL](#mysql-active-active-clusters-limitations) + [Considerazioni e best practice per i cluster attivi-attivi di RDS per MySQL](#mysql-active-active-clusters-considerations) ## Limitazioni per i cluster attivi-attivi in RDS per MySQL Le seguenti limitazioni si applicano ai cluster attivi-attivi in RDS per MySQL: + Per le istanze database di un cluster attivo-attivo, il nome utente principale non può essere `rdsgrprepladmin` perché tale nome è riservato alle connessioni di replica di gruppo. + Per le istanze database con repliche di lettura in cluster attivi-attivi, uno stato di replica prolungato diverso da `Replicating` può comportare il superamento dei limiti di archiviazione da parte dei file di log. Per informazioni sullo stato delle repliche di lettura, consulta [Monitoraggio della replica di lettura](USER_ReadRepl.Monitoring.md). + Le implementazioni blu/verde non sono supportate nelle istanze database di un cluster attivo-attivo. Per ulteriori informazioni, consulta [Utilizzo di Amazon RDS Blue/Green Aurora Deployments per gli aggiornamenti del database](blue-green-deployments.md). + L’autenticazione Kerberos non è supportata nelle istanze database di un cluster attivo-attivo. Per ulteriori informazioni, consulta [Utilizzo dell’autenticazione Kerberos per Amazon RDS per MySQL](mysql-kerberos.md). + Le istanze database di un cluster di database Multi-AZ non possono essere aggiunte a un cluster attivo-attivo, a differenza delle istanze database in un’implementazione di istanze database Multi-AZ per cui l’aggiunta è possibile. Per ulteriori informazioni, consulta [Configurazione e gestione di un’implementazione Multi-AZ per Amazon RDS](Concepts.MultiAZ.md). + Le tabelle per cui non esiste una chiave primaria non vengono replicate in un cluster attivo-attivo perché le scritture vengono rifiutate dal plugin di replica di gruppo. + Le tabelle non InnoDB non vengono replicate in un cluster attivo-attivo. + I cluster attivi-attivi non supportano istruzioni DML e DDL simultanee su istanze database diverse nel cluster. + Non è possibile configurare un cluster attivo-attivo per utilizzare la modalità primaria singola per la modalità di replica di gruppo. Per questa configurazione, si consiglia di utilizzare un cluster di database Multi-AZ. Per ulteriori informazioni, consulta [Implementazioni di cluster di database Multi-AZ per Amazon RDS](multi-az-db-clusters-concepts.md). + La replica da più origini non è supportata per le istanze database di un cluster attivo-attivo. + Un cluster attivo-attivo tra Regioni non può imporre la verifica dell’autorità di certificazione (CA) per le connessioni di replica di gruppo. ## Considerazioni e best practice per i cluster attivi-attivi di RDS per MySQL Prima di utilizzare i cluster attivi-attivi di RDS per MySQL, esamina le considerazioni e le best practice seguenti: + Nei cluster attivi-attivi non possono essere presenti più di nove istanze database. + Il plugin di replica di gruppo consente di controllare le garanzie di coerenza delle transazioni del cluster attivo-attivo. Per ulteriori informazioni, consulta [Transaction Consistency Guarantees](https://dev.mysql.com/doc/refman/8.0/en/group-replication-consistency-guarantees.html) nella documentazione MySQL. + Quando istanze database diverse aggiornano la stessa riga in un cluster attivo-attivo, possono verificarsi conflitti. Per informazioni sui conflitti e la relativa risoluzione, consulta [Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) nella documentazione MySQL. + Per la tolleranza ai guasti, includere almeno tre istanze database nel cluster attivo-attivo. È possibile configurare un cluster attivo-attivo solamente con una o due istanze database, ma il cluster non sarà tollerante ai guasti. Per informazioni sulla tolleranza ai guasti, consulta [Fault-tolerance](https://dev.mysql.com/doc/refman/8.0/en/group-replication-fault-tolerance.html) nella documentazione MySQL. + Quando un’istanza database si unisce a un cluster attivo-attivo esistente ed esegue la versione del motore uguale a quella minima del cluster, l’istanza database si unisce in modalità di lettura/scrittura. + Quando un’istanza database si unisce a un cluster attivo-attivo esistente ed esegue una versione del motore successiva a quella minima del cluster, l’istanza database deve rimanere in modalità di sola lettura. + Se si abilita la replica di gruppo per un'istanza DB impostando il relativo `rds.group_replication_enabled` parametro su `1` nel gruppo di parametri DB, ma la replica non è iniziata o non è riuscita, l'istanza DB viene messa in super-read-only modalità per evitare incoerenze tra i dati. Per informazioni sulla super-read-only modalità, consulta la documentazione di [MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only). + È possibile aggiornare un’istanza database in un cluster attivo-attivo, ma l’istanza rimane di sola lettura fino a quando tutte le altre istanze database del cluster attivo-attivo non vengono aggiornate alla stessa versione del motore oppure a una versione successiva. Quando si aggiorna un’istanza database, l’istanza si unisce automaticamente allo stesso cluster attivo-attivo al termine dell’aggiornamento. Per evitare che un’istanza database passi involontariamente alla modalità di sola lettura, disabilitarne gli aggiornamenti automatici delle versioni secondarie. Per informazioni sull’aggiornamento di un’istanza database MySQL, consulta [Aggiornamenti del motore di database RDS per MySQL](USER_UpgradeDBInstance.MySQL.md). + È possibile aggiungere un’istanza database in un’implementazione di istanze database Multi-AZ a un cluster attivo-attivo esistente. È anche possibile convertire un’istanza database Single-AZ di un cluster attivo-attivo a un’implementazione di istanza database Multi-AZ. Se in un’istanza database di un’implementazione Multi-AZ si verifica un errore, viene eseguito il failover dell’istanza primaria all’istanza di standby. La nuova istanza database primaria si unisce automaticamente allo stesso cluster al termine del failover. Per ulteriori informazioni sulle implementazioni di istanze database Multi-AZ, consulta [Implementazioni di istanze database Multi-AZ per Amazon RDS](Concepts.MultiAZSingleStandby.md). + È consigliabile che gli intervalli di tempo per le finestre di manutenzione delle istanze database di un cluster attivo-attivo siano diversi. In tal modo si evita che più istanze database del cluster siano contemporaneamente offline per la manutenzione. Per ulteriori informazioni, consulta [Finestra di manutenzione Amazon RDS](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance). + I cluster attivi-attivi possono utilizzare SSL per le connessioni tra istanze database. Per configurare le connessioni SSL, impostare i parametri [ group\$1replication\$1recovery\$1use\$1ssl](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_recovery_use_ssl) e [ group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode) i cui valori devono corrispondere per tutte le istanze database del cluster attivo-attivo. Attualmente, i cluster attivi-attivi non supportano la verifica dell’autorità di certificazione (CA) per le connessioni tra Regioni AWS. Di conseguenza, è necessario impostare il parametro [ group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode) su `DISABLED` (impostazione predefinita) o su `REQUIRED` per cluster tra Regioni. + Un cluster attivo-attivo RDS per MySQL viene eseguito in modalità multiprimaria. Il valore predefinito di [ group\$1replication\$1enforce\$1update\$1everywhere\$1checks](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_enforce_update_everywhere_checks) è `ON` e il parametro è statico. Quando il parametro è impostato su `ON`, le applicazioni non possono effettuare inserimenti in una tabella con vincoli di chiave esterna a cascata. + Un cluster attivo-attivo RDS per MySQL utilizza lo stack di comunicazione MySQL per la sicurezza della connessione anziché XCOM. Per ulteriori informazioni, consulta [Communication Stack for Connection Security Management](https://dev.mysql.com/doc/refman/8.0/en/group-replication-connection-security.html) nella documentazione MySQL. + Quando un gruppo di parametri database è associato a un’istanza database di un cluster attivo-attivo, si consiglia di associarlo solo ad altre istanze database presenti nel cluster. + I cluster attivi-attivi supportano solo le istanze database RDS per MySQL. Tali istanze devono eseguire versioni supportate del motore di database. + Quando in un’istanza database di un cluster attivo-attivo si verifica un errore imprevisto, RDS avvia automaticamente il ripristino di tale istanza. Se l'istanza DB non viene ripristinata, consigliamo di sostituirla con una nuova istanza DB eseguendo un point-in-time ripristino con un'istanza DB integra nel cluster. Per istruzioni, consulta [Aggiunta di un’istanza database a un cluster attivo-attivo tramite il recupero point-in-time](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr). + È possibile eliminare un’istanza database di un cluster attivo-attivo senza influire sulle altre istanze database del cluster. Per informazioni sulla creazione di un’istanza database, consulta [Eliminazione di un'istanza database](USER_DeleteInstance.md). + Quando un’istanza database esce involontariamente da un cluster attivo-attivo, per impostazione predefinita il valore del parametro `group_replication_exit_state_action` cambia in `OFFLINE_MODE`. In questo stato, l’istanza database non è accessibile ed è necessario riavviarla per riportarla online e unirla nuovamente al cluster. Per cambiare questo comportamento, modifica il parametro `group_replication_exit_state_action` in un gruppo di parametri personalizzato. Se si imposta il parametro su `READ_ONLY`, quando l’istanza database esce involontariamente da un cluster passa a uno stato super-read-only anziché allo stato offline. # Preparazione per un cluster attivo-attivo tra VPC È possibile configurare un cluster attivo-attivo con istanze database Amazon RDS per MySQL in più di un VPC. VPCs Possono essere uguali Regione AWS o diversi Regioni AWS. **Nota** L'invio di traffico tra più Regioni AWS utenti potrebbe comportare costi aggiuntivi. Per ulteriori informazioni, consulta [Overview of Data Transfer Costs for Common Architectures](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/). Se configuri un cluster attivo-attivo in un singolo VPC, puoi saltare questi passaggi e passare a [Configurazione di un cluster attivo-attivo con nuove istanze database](mysql-active-active-clusters-setting-up.md). **Per prepararsi a un cluster attivo-attivo con istanze database in più di un VPC** 1. Assicurati che gli intervalli di IPv4 indirizzi nei blocchi CIDR soddisfino i seguenti requisiti: + Gli intervalli di IPv4 indirizzi nei blocchi CIDR di non VPCs possono sovrapporsi. + Tutti gli intervalli di IPv4 indirizzi nei blocchi CIDR devono essere inferiori `128.0.0.0/subnet_mask` o superiori a 128.0.0.0/. *subnet\$1mask* Gli intervalli seguenti illustrano questi requisiti: + La presenza di `10.1.0.0/16` in un VPC e di `10.2.0.0/16` nell’altro VPC è supportata. + La presenza di `172.1.0.0/16` in un VPC e di `172.2.0.0/16` nell’altro VPC è supportata. + La presenza di `10.1.0.0/16` in un VPC e di `10.1.0.0/16` nell’altro VPC *non è* supportata perché gli intervalli si sovrappongono. + La presenza di `10.1.0.0/16` in un VPC e di `172.1.0.0/16` nell’altro VPC *non è* supportata perché un intervallo è inferiore a `128.0.0.0/subnet_mask` e l’altro è superiore a `128.0.0.0/subnet_mask`. Per informazioni sugli intervalli CIDR, consulta [ VPC CIDR blocks](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) nella *Guida per l’utente di Amazon VPC*. 1. In ogni VPC, verifica che la risoluzione e nomi host DNS siano entrambi abilitati. Per istruzioni, consulta [Visualizzazione e aggiornamento degli attributi DNS per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) nella *Guida per l’utente di Amazon VPC*. 1. Configurali VPCs in modo da poter indirizzare il traffico tra di essi in uno dei seguenti modi: + Crea una connessione peering VPC tra. VPCs Per istruzioni, consulta [Creazione di una connessione peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) nella *Guida per il peering VPC Amazon*. In ogni VPC, verifica che siano presenti regole in entrata per i gruppi di sicurezza che fanno riferimento a gruppi di sicurezza nel VPC collegato in peering. In questo modo, si consente il traffico verso e da istanze associate al gruppo di sicurezza a cui si fa riferimento nel VPC collegato in peering. Per istruzioni, consulta [Aggiornamento dei gruppi di sicurezza per fare riferimento a gruppi di sicurezza peer di riferimento](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html) nella *Guida per il peering VPC Amazon*. + Crea un gateway di transito tra. VPCs Per istruzioni, consulta [Nozioni di base sui gateway di transito](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html) in *Amazon VPC Transit Gateway*. In ogni VPC, verifica che siano presenti regole in entrata per i gruppi di sicurezza che consentano il traffico proveniente dall’altro VPC, ad esempio regole in entrata che specificano il CIDR dell’altro VPC. In questo modo, si consente il traffico verso e da istanze associate al gruppo di sicurezza a cui si fa riferimento nel cluster attivo-attivo. Per ulteriori informazioni, consulta [Controlla il traffico verso AWS le tue risorse utilizzando i gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#working-with-security-groups) nella *Amazon VPC User Guide*. # Impostazioni dei parametri richieste per i cluster attivi-attivi In Amazon RDS per MySQL, la configurazione dei parametri per i cluster attivi-attivi è essenziale per mantenere prestazioni e stabilità operativa costanti. Questa tabella descrive in dettaglio i parametri chiave che controllano la replica, la risoluzione dei conflitti e la distribuzione del carico di lavoro. La corretta configurazione garantisce una sincronizzazione efficiente tra i nodi, riduce il ritardo di replica e ottimizza l’utilizzo delle risorse in ambienti distribuiti oppure a traffico elevato. | Parametro | Descrizione | Impostazione obbligatoria | | --- | --- | --- | | `binlog_format` | Imposta il formato per la registrazione di log binari. Il valore predefinito per RDS per MySQL 8.0 e versioni precedenti è `MIXED`. Il valore predefinito per RDS per MySQL 8.4 è `ROW`. Per ulteriori informazioni, consulta [ la documentazione MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format). | `ROW` | | `enforce_gtid_consistency` | Applica la coerenza GTID per l’esecuzione delle istruzioni. Il valore predefinito per RDS per MySQL è `OFF`. Per ulteriori informazioni, consulta [ la documentazione MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_enforce_gtid_consistency). | `ON` | | `group_replication_group_name` | Imposta il nome della replica di gruppo su un UUID. Il formato UUID è `11111111-2222-3333-4444-555555555555`. Per generare un UUID MySQL, connettiti a un’istanza database MySQL ed esegui `SELECT UUID()`. Il valore deve essere lo stesso per tutte le istanze database del cluster attivo-attivo. Per ulteriori informazioni, consulta [ la documentazione MySQL](https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_uuid). | UUID MySQL | | `gtid-mode` | Controlla la registrazione di log basata su GTID. Il valore predefinito per RDS per MySQL è `OFF_PERMISSIVE`. Per ulteriori informazioni, consulta [ la documentazione MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_mode). | `ON` | | `rds.custom_dns_resolution` | Specifica se consentire la risoluzione DNS dal server Amazon DNS al VPC in uso. La risoluzione DNS deve essere abilitata quando la replica di gruppo è abilitata con il parametro `rds.group_replication_enabled`. La risoluzione DNS non può essere abilitata quando la replica di gruppo è disabilitata con il parametro `rds.group_replication_enabled`. Per ulteriori informazioni, consulta [Amazon DNS Server](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#AmazonDNS) nella *Guida per l’utente di Amazon VPC*. | `1` | | `rds.group_replication_enabled` | Specifica se la replica di gruppo è abilitata per un’istanza database. In un cluster attivo-attivo la replica di gruppo deve essere abilitata in un’istanza database. | `1` | | `replica_preserve_commit_order` (RDS per MySQL 8.4 e versioni successive) o `slave_preserve_commit_order` (RDS per MySQL 8.0) | Controlla l’ordine in cui viene eseguito il commit delle transazioni in una replica. Il valore predefinito per RDS per MySQL è `ON`. Per ulteriori informazioni, consulta [ la documentazione MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#sysvar_slave_preserve_commit_order). | `ON` | # Conversione di un’istanza database esistente in un cluster attivo-attivo La versione del motore di database dell’istanza database da migrare in cluster attivo-attivo deve essere una delle seguenti: + Tutte le versioni di MySQL 8.4 + MySQL 8.0.35 e versioni secondarie successive Se è necessario aggiornare la versione del motore, consulta [Aggiornamenti del motore di database RDS per MySQL](USER_UpgradeDBInstance.MySQL.md). Se configuri un cluster attivo-attivo con istanze database in più di un cloud privato virtuale, verifica che i prerequisiti in [Preparazione per un cluster attivo-attivo tra VPC](mysql-active-active-clusters-cross-vpc-prerequisites.md) siano soddisfatti. Per migrare un’istanza database esistente in un cluster attivo-attivo per RDS per MySQL, esegui queste operazioni. **Topics** + [Fase 1: impostare i parametri del cluster attivo-attivo in uno o più gruppi di parametri personalizzati](#mysql-active-active-clusters-converting-parameter-group) + [Fase 2: associare l’istanza database a un gruppo di parametri di database con i parametri di replica di gruppo richiesti impostati](#mysql-active-active-clusters-converting-associate-parameter-group) + [Fase 3: creare il cluster attivo-attivo](#mysql-active-active-clusters-converting-associate-parameter-groups) + [Fase 4: creare istanze database RDS per MySQL per il cluster attivo-attivo](#mysql-active-active-clusters-converting-add-db-instances) + [Fare 5: inizializzare il gruppo sull’istanza database in fase di conversione](#mysql-active-active-clusters-converting-start-replication-first) + [Fase 6: avviare la replica sulle altre istanze database nel cluster attivo-attivo](#mysql-active-active-clusters-converting-start-replication-other) + [Fase 7 (consigliata): verificare lo stato del cluster attivo-attivo](#mysql-active-active-clusters-converting-view) ## Fase 1: impostare i parametri del cluster attivo-attivo in uno o più gruppi di parametri personalizzati Le istanze database RDS per MySQL in un cluster attivo-attivo devono essere associate a un gruppo di parametri personalizzato con l’impostazione corretta per i parametri richiesti. Per ulteriori informazioni sui parametri e la relativa impostazione per ciascuno, consulta [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md). È possibile impostare i parametri in nuovi gruppi di parametri o in gruppi di parametri esistenti. Tuttavia, per evitare di influire accidentalmente sulle istanze database che non fanno parte del cluster attivo-attivo, si consiglia di creare un nuovo gruppo di parametri personalizzato. Le istanze database di un cluster attivo-attivo possono essere associate allo stesso gruppo di parametri di database oppure a gruppi di parametri di database diversi. È possibile utilizzare Console di gestione AWS o il AWS CLI per creare un nuovo gruppo di parametri personalizzato. Per ulteriori informazioni, consulta [Creazione di un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Creating.md). L'esempio seguente esegue il [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI comando per creare un gruppo di parametri DB personalizzato denominato RDS `myactivepg` for MySQL 8.0: Per Linux, macOS o Unix: ``` aws rds create-db-parameter-group \ --db-parameter-group-name myactivepg \ --db-parameter-group-family mysql8.0 \ --description "Parameter group for active-active clusters" ``` Per Windows: ``` aws rds create-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --db-parameter-group-family mysql8.0 ^ --description "Parameter group for active-active clusters" ``` È inoltre possibile utilizzare Console di gestione AWS o the AWS CLI per impostare i parametri nel gruppo di parametri personalizzato. Per ulteriori informazioni, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). L'esempio seguente esegue il [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI comando per impostare i parametri per RDS for MySQL 8.0. Per utilizzare questo esempio con RDS per MySQL 8.4, modificare `slave_preserve_commit_order` in `replica_preserve_commit_order`. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` ## Fase 2: associare l’istanza database a un gruppo di parametri di database con i parametri di replica di gruppo richiesti impostati Associa l’istanza database a un gruppo di parametri di database creato o modificato nella fase precedente. Per istruzioni, consulta [Associazione di un gruppo di parametri database a un’istanza database in Amazon RDS](USER_WorkingWithParamGroups.Associating.md). Affinché le nuove impostazioni del parametro abbiano effetto, riavvia l’istanza database. Per istruzioni, consulta [Riavvio di un'istanza DB DB](USER_RebootInstance.md). ## Fase 3: creare il cluster attivo-attivo Nel gruppo di parametri di database associato a ciascuna istanza database, imposta il parametro `group_replication_group_seeds` sull’endpoint delle istanze database in fase di conversione. È possibile utilizzare Console di gestione AWS o the per impostare il parametro AWS CLI . Dopo aver impostato il parametro, non è necessario riavviare l’istanza database. Per informazioni sull’impostazione dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). L'esempio seguente esegue il [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI comando per impostare i parametri: Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` ## Fase 4: creare istanze database RDS per MySQL per il cluster attivo-attivo Per creare istanze DB aggiuntive per il cluster active-active, esegui il point-in-time ripristino sull'istanza DB che stai convertendo. Per istruzioni, consulta [Aggiunta di un’istanza database a un cluster attivo-attivo tramite il recupero point-in-time](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr). Nei cluster attivi-attivi possono essere presenti fino a nove istanze database. Esegui il point-in-time ripristino sull'istanza DB fino a ottenere il numero di istanze DB che desideri per il cluster. Quando esegui point-in-recovery, assicurati di associare l'istanza DB che stai aggiungendo a un gruppo di parametri DB `rds.group_replication_enabled` impostato `1` su. In caso contrario, la replica di gruppo non verrà avviata sull’istanza database aggiunta. ## Fare 5: inizializzare il gruppo sull’istanza database in fase di conversione Inizializza il gruppo e avvia la replica: 1. Connettiti all’istanza database in fase di conversione in un client SQL. Per ulteriori informazioni sulla connessione a un’istanza database RDS per MySQL, consulta [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). 1. Nel client SQL, esegui le seguenti stored procedure e *group\$1replication\$1user\$1password* sostituiscile con la password dell'`rdsgrprepladmin`utente. In un cluster attivo-attivo, l’utente `rdsgrprepladmin` è riservato alle connessioni di replica di gruppo. La password di tale utente deve essere la stessa su tutte le istanze database di un cluster attivo-attivo. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(1); ``` Questo esempio imposta il valore `binlog retention hours` su `168` in modo che i file di log binari vengano mantenuti per sette giorni nell’istanza database. È possibile modificare questo valore per soddisfare i requisiti specifici. Questo esempio specifica `1` nella stored procedure `mysql.rds_group_replication_start` per inizializzare un nuovo gruppo con l’istanza database corrente. Per ulteriori informazioni sulle stored procedure chiamate nell’esempio, consulta [Gestione di cluster attivi-attivi](mysql-stored-proc-active-active-clusters.md). ## Fase 6: avviare la replica sulle altre istanze database nel cluster attivo-attivo Per ciascuna istanza database del cluster attivo-attivo, utilizza un client SQL per connetterti all’istanza ed esegui queste stored procedure. Sostituire *group\$1replication\$1user\$1password* con la password dell'`rdsgrprepladmin`utente. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(0); ``` Questo esempio imposta il valore `binlog retention hours` su `168` in modo che i file di log binari vengano mantenuti per sette giorni in ciascuna istanza database. È possibile modificare questo valore per soddisfare i requisiti specifici. L’esempio specifica `0` nella stored procedure `mysql.rds_group_replication_start` per unire l’istanza database corrente a un gruppo esistente. **Suggerimento** Assicurati di eseguire queste stored procedure su tutte le altre istanze database del cluster attivo-attivo. ## Fase 7 (consigliata): verificare lo stato del cluster attivo-attivo Per verificare che ogni membro del cluster sia configurato correttamente, connettiti a un’istanza database del cluster attivo-attivo ed esegui questo comando SQL per controllare lo stato del cluster: ``` SELECT * FROM performance_schema.replication_group_members; ``` L’output deve essere `ONLINE` per l’elemento `MEMBER_STATE` di ogni istanza database, come nell’output di esempio seguente: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Per informazioni sui possibili valori `MEMBER_STATE`, consulta [Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) nella documentazione MySQL. # Configurazione di un cluster attivo-attivo con nuove istanze database Per configurare un cluster attivo-attivo utilizzando nuove istanze database di Amazon RDS per MySQL, esegui queste operazioni. Se configuri un cluster attivo-attivo con istanze database in più di un cloud privato virtuale, verifica che i prerequisiti in [Preparazione per un cluster attivo-attivo tra VPC](mysql-active-active-clusters-cross-vpc-prerequisites.md) siano soddisfatti. **Topics** + [Fase 1: impostare i parametri del cluster attivo-attivo in uno o più gruppi di parametri personalizzati](#mysql-active-active-clusters-setting-up-parameter-group) + [Fase 2: creare nuove istanze database RDS per MySQL per il cluster attivo-attivo](#mysql-active-active-clusters-setting-up-db-instances) + [Fase 3: specificare le istanze database nel cluster attivo-attivo](#mysql-active-active-clusters-setting-up-associate-parameter-groups) + [Fase 4: inizializzare il gruppo su un’istanza database e avviare la replica](#mysql-active-active-clusters-setting-up-start-replication-first) + [Fase 5: avviare la replica sulle altre istanze database nel cluster attivo-attivo](#mysql-active-active-clusters-setting-up-start-replication-other) + [Fase 6 (consigliata): verificare lo stato del cluster attivo-attivo](#mysql-active-active-clusters-setting-up-view) + [Fase 7 (facoltativa): importare i dati in un’istanza database del cluster attivo-attivo](#mysql-active-active-clusters-import) ## Fase 1: impostare i parametri del cluster attivo-attivo in uno o più gruppi di parametri personalizzati Le istanze database RDS per MySQL in un cluster attivo-attivo devono essere associate a un gruppo di parametri personalizzato con l’impostazione corretta per i parametri richiesti. Per ulteriori informazioni sui parametri e la relativa impostazione per ciascuno, consulta [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md). È possibile impostare i parametri in nuovi gruppi di parametri o in gruppi di parametri esistenti. Tuttavia, per evitare di influire accidentalmente sulle istanze database che non fanno parte del cluster attivo-attivo, si consiglia di creare un nuovo gruppo di parametri personalizzato. Le istanze database di un cluster attivo-attivo possono essere associate allo stesso gruppo di parametri di database oppure a gruppi di parametri di database diversi. È possibile utilizzare Console di gestione AWS o il AWS CLI per creare un nuovo gruppo di parametri personalizzato. Per ulteriori informazioni, consulta [Creazione di un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Creating.md). L'esempio seguente esegue il [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI comando per creare un gruppo di parametri DB personalizzato denominato RDS `myactivepg` for MySQL 8.0: Per Linux, macOS o Unix: ``` aws rds create-db-parameter-group \ --db-parameter-group-name myactivepg \ --db-parameter-group-family mysql8.0 \ --description "Parameter group for active-active clusters" ``` Per Windows: ``` aws rds create-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --db-parameter-group-family mysql8.0 ^ --description "Parameter group for active-active clusters" ``` È inoltre possibile utilizzare Console di gestione AWS o the AWS CLI per impostare i parametri nel gruppo di parametri personalizzato. Per ulteriori informazioni, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). L'esempio seguente esegue il [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI comando per impostare i parametri per RDS for MySQL 8.0. Per utilizzare questo esempio con RDS per MySQL 8.4, modificare `slave_preserve_commit_order` in `replica_preserve_commit_order`. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` ## Fase 2: creare nuove istanze database RDS per MySQL per il cluster attivo-attivo I cluster attivi-attivi sono supportati per le seguenti versioni delle istanze database RDS per MySQL: + Tutte le versioni di MySQL 8.4 + MySQL versione 8.0.35 e versioni secondarie successive È possibile creare fino a nove nuove istanze database per il cluster. È possibile utilizzare Console di gestione AWS o the AWS CLI per creare nuove istanze DB. Per ulteriori informazioni sulla creazione di un'istanza database, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md). Quando crei l’istanza database, associala a un gruppo di parametri di database creato o modificato nella fase precedente. ## Fase 3: specificare le istanze database nel cluster attivo-attivo Nel gruppo di parametri di database associato a ciascuna istanza database, imposta il parametro `group_replication_group_seeds` sugli endpoint delle istanze database da includere nel cluster. È possibile utilizzare Console di gestione AWS o the AWS CLI per impostare il parametro. Dopo aver impostato il parametro, non è necessario riavviare l’istanza database. Per informazioni sull’impostazione dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). L'esempio seguente esegue il [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI comando per impostare i parametri: Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` **Suggerimento** Assicurati di impostare il parametro `group_replication_group_seeds` in ogni gruppo di parametri di database associato a un’istanza database nel cluster attivo-attivo. ## Fase 4: inizializzare il gruppo su un’istanza database e avviare la replica È possibile scegliere qualsiasi nuovo database per inizializzare il gruppo e avviare la replica. Per fare ciò, completa la seguente procedura: 1. Scegli un’istanza database nel cluster attivo-attivo e connettiti a tale istanza utilizzando un client SQL. Per ulteriori informazioni sulla connessione a un’istanza database RDS per MySQL, consulta [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). 1. Nel client SQL, esegui le seguenti stored procedure e *group\$1replication\$1user\$1password* sostituiscile con la password dell'`rdsgrprepladmin`utente. In un cluster attivo-attivo, l’utente `rdsgrprepladmin` è riservato alle connessioni di replica di gruppo. La password di tale utente deve essere la stessa su tutte le istanze database di un cluster attivo-attivo. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(1); ``` Questo esempio imposta il valore `binlog retention hours` su `168` in modo che i file di log binari vengano mantenuti per sette giorni nell’istanza database. È possibile modificare questo valore per soddisfare i requisiti specifici. Questo esempio specifica `1` nella stored procedure `mysql.rds_group_replication_start` per inizializzare un nuovo gruppo con l’istanza database corrente. Per ulteriori informazioni sulle stored procedure chiamate nell’esempio, consulta [Gestione di cluster attivi-attivi](mysql-stored-proc-active-active-clusters.md). ## Fase 5: avviare la replica sulle altre istanze database nel cluster attivo-attivo Per ciascuna istanza database del cluster attivo-attivo, utilizza un client SQL per connetterti all’istanza ed esegui queste stored procedure. Sostituire *group\$1replication\$1user\$1password* con la password dell'`rdsgrprepladmin`utente. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(0); ``` Questo esempio imposta il valore `binlog retention hours` su `168` in modo che i file di log binari vengano mantenuti per sette giorni in ciascuna istanza database. È possibile modificare questo valore per soddisfare i requisiti specifici. L’esempio specifica `0` nella stored procedure `mysql.rds_group_replication_start` per unire l’istanza database corrente a un gruppo esistente. **Suggerimento** Assicurati di eseguire queste stored procedure su tutte le altre istanze database del cluster attivo-attivo. ## Fase 6 (consigliata): verificare lo stato del cluster attivo-attivo Per verificare che ogni membro del cluster sia configurato correttamente, connettiti a un’istanza database del cluster attivo-attivo ed esegui questo comando SQL per controllare lo stato del cluster: ``` SELECT * FROM performance_schema.replication_group_members; ``` L’output deve essere `ONLINE` per l’elemento `MEMBER_STATE` di ogni istanza database, come nell’output di esempio seguente: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Per informazioni sui possibili valori `MEMBER_STATE`, consulta [Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) nella documentazione MySQL. ## Fase 7 (facoltativa): importare i dati in un’istanza database del cluster attivo-attivo È possibile importare dati da un database MySQL in un’istanza database nel cluster attivo-attivo. Dopo l’importazione, la replica di gruppo replica i dati nelle altre istanze database del cluster. Per informazioni sull’importazione di dati, consulta [Importazione dei dati in un database Amazon RDS per MySQL con tempo di inattività ridotto](mysql-importing-data-reduced-downtime.md). # Aggiunta di un’istanza database a un cluster attivo-attivo È possibile aggiungere un’istanza database a un cluster attivo-attivo Amazon RDS per MySQL ripristinando uno snapshot di database o un’istanza database in un determinato momento. Nei cluster attivi-attivi possono essere presenti fino a nove istanze database. Quando si ripristina un’istanza database in un determinato momento, in genere vengono incluse transazioni più recenti rispetto a quelle di un’istanza database ripristinata da uno snapshot di database. Se nell’istanza database sono presenti transazioni più recenti, è necessario applicare un numero inferiore di transazioni all’avvio della replica. Di conseguenza, il recupero point-in-time per aggiungere un’istanza database a un cluster è in genere più rapido rispetto al ripristino da uno snapshot di database. **Topics** + [Aggiunta di un’istanza database a un cluster attivo-attivo tramite il recupero point-in-time](#mysql-active-active-clusters-adding-pitr) + [Aggiunta di un’istanza database a un cluster attivo-attivo tramite uno snapshot di database](#mysql-active-active-clusters-adding-snapshot) ## Aggiunta di un’istanza database a un cluster attivo-attivo tramite il recupero point-in-time Per aggiungere un’istanza database aggiuntiva per il cluster attivo-attivo, esegui il recupero point-in-time sull’istanza database nel cluster. Per informazioni sul recupero di un’istanza database in un determinato momento in una Regione AWS diversa, consulta [Replica dei backup automatici su un altro Regione AWS](USER_ReplicateBackups.md). **Per aggiungere un’istanza database a un cluster attivo-attivo tramite il recupero point-in-time** 1. Crea una nuova istanza database eseguendo il recupero point-in-time sull’istanza database nel cluster attivo-attivo. È possibile eseguire il recupero point-in-time su qualsiasi istanza database nel cluster per creare la nuova istanza database. Per istruzioni, consultare [Ripristino di un’istanza database a un punto temporale specifico per Amazon RDS](USER_PIT.md). **Importante** Durante il recupero point-in-time, associa la nuova istanza database a un gruppo di parametri di database con i parametri del cluster attivo-attivo impostati. In caso contrario, la replica di gruppo non verrà avviata sulla nuova istanza database. Per ulteriori informazioni sui parametri e la relativa impostazione per ciascuno, consulta [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md). **Suggerimento** Se si acquisisce uno snapshot dell’istanza database prima di avviare il recupero point-in-time, è possibile ridurre il tempo necessario per applicare le transazioni alla nuova istanza database. 1. Aggiungi l’istanza database al parametro `group_replication_group_seeds` in ogni gruppo di parametri di database associato a un’istanza database nel cluster attivo-attivo, incluso il gruppo di parametri di database associato alla nuova istanza database. Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. In un client SQL, connettiti alla nuova istanza database e chiama la stored procedure [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel). Sostituisci *group\$1replication\$1user\$1password* con la password per l’utente `rdsgrprepladmin`. ``` call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); ``` 1. Utilizzando il client SQL, chiama la stored procedure [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) per avviare la replica: ``` call mysql.rds_group_replication_start(0); ``` ## Aggiunta di un’istanza database a un cluster attivo-attivo tramite uno snapshot di database È possibile aggiungere un’istanza database a un cluster attivo-attivo creando uno snapshot di database di un’istanza database nel cluster e quindi ripristinando lo snapshot di database. Per ulteriori informazioni sulla copia di uno snapshot in una Regione AWS diversa, consulta [Considerazioni sulla copia di snapshot tra Regioni](USER_CopySnapshot.md#USER_CopySnapshot.AcrossRegions). **Per aggiungere un’istanza database a un cluster attivo-attivo tramite uno snapshot di database** 1. Crea uno snapshot di database di un’istanza database nel cluster attivo-attivo. Per creare uno snapshot di database di qualsiasi istanza database del cluster. Per istruzioni, consultare [Creazione di uno snapshot del database per un’istanza database Single-AZ per Amazon RDS](USER_CreateSnapshot.md). 1. Ripristina un’istanza database dallo snapshot di database. Durante il ripristino point-in-time, associa la nuova istanza database a un gruppo di parametri di database con i parametri del cluster attivo-attivo impostati. Per ulteriori informazioni sui parametri e la relativa impostazione per ciascuno, consulta [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md). Per informazioni sul ripristino di un’istanza database da uno snapshot di database, consulta [Ripristino in un’istanza database](USER_RestoreFromSnapshot.md). 1. Aggiungi l’istanza database al parametro `group_replication_group_seeds` in ogni gruppo di parametri di database associato a un’istanza database nel cluster attivo-attivo, incluso il gruppo di parametri di database associato alla nuova istanza database. Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. In un client SQL, connettiti alla nuova istanza database e chiama la stored procedure [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel). Sostituisci *group\$1replication\$1user\$1password* con la password per l’utente `rdsgrprepladmin`. ``` call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); ``` 1. Utilizzando il client SQL, chiama la stored procedure [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) per avviare la replica: ``` call mysql.rds_group_replication_start(0); ``` # Monitoraggio dei cluster attivi-attivi In Amazon RDS per MySQL, il monitoraggio dei cluster attivi-attivi è fondamentale per tenere traccia delle prestazioni, dell’integrità della replica e della sincronizzazione dei nodi. Per monitorare il cluster attivo-attivo, connettiti a un’istanza database nel cluster ed esegui questo comando SQL: ``` SELECT * FROM performance_schema.replication_group_members; ``` L’output deve essere `ONLINE` per l’elemento `MEMBER_STATE` di ogni istanza database, come nell’output di esempio seguente: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Per informazioni sui possibili valori `MEMBER_STATE`, consulta [Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) nella documentazione MySQL. # Arresto della replica di gruppo in un’istanza database in un cluster attivo-attivo È possibile arrestare la replica di gruppo in un’istanza database in un cluster attivo-attivo. Quando si interrompe la replica di gruppo, l'istanza DB viene messa in super-read-only modalità fino al riavvio della replica o alla rimozione dell'istanza DB dal cluster active-active. Per informazioni sulla super-read-only modalità, consulta la documentazione di [MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only). **Per arrestare temporaneamente la replica di gruppo in un cluster attivo-attivo** 1. Connettiti a un’istanza database nel cluster attivo-attivo utilizzando un client SQL. Per ulteriori informazioni sulla connessione a un’istanza database RDS per MySQL, consulta [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). 1. Nel client SQL, chiama la stored procedure [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop): ``` call mysql.rds_group_replication_stop(); ``` # Ridenominazione di un’istanza database in un cluster attivo-attivo È possibile modificare il nome di un’istanza database in un cluster attivo-attivo. Per rinominare più di un’istanza database in un cluster attivo-attivo, esegui un’istanza database alla volta. Rinomina quindi un’istanza database e uniscila nuovamente al cluster prima di rinominare l’istanza database successiva. **Per rinominare un’istanza database in un cluster attivo-attivo** 1. Connettiti all’istanza database in un client SQL e chiama la stored procedure [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop): ``` call mysql.rds_group_replication_stop(); ``` 1. Segui le istruzioni in [Ridenominazione di un'istanza database](USER_RenameInstance.md) per rinominare l’istanza database. 1. Modifica il parametro `group_replication_group_seeds` in ogni gruppo di parametri di database associato a un’istanza database nel cluster attivo-attivo. Nell’impostazione dei parametri, sostituisci il vecchio endpoint dell’istanza database con quello nuovo. Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Connettiti all’istanza database in un client SQL e chiama la stored procedure [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start): ``` call mysql.rds_group_replication_start(0); ``` # Rimozione di un’istanza database da un cluster attivo-attivo Quando si rimuove un’istanza database da un cluster attivo-attivo, viene ripristinata un’istanza database autonoma. **Per rimuovere un’istanza database da un cluster attivo-attivo** 1. Connettiti all’istanza database in un client SQL e chiama la stored procedure [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop): ``` call mysql.rds_group_replication_stop(); ``` 1. Modifica il `group_replication_group_seeds` parametro per le istanze database che rimangono nel cluster attivo-attivo. Nel parametro `group_replication_group_seeds`, elimina l’istanza database da rimuovere dal cluster attivo-attivo. Per informazioni sull’impostazione dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Modifica i parametri dell’istanza database da rimuovere dal cluster attivo-attivo in modo che non appartenga più al cluster. È possibile associare l’istanza database a un gruppo di parametri diverso o modificare i parametri del gruppo di parametri di database associato all’istanza database. I parametri da modificare includono `group_replication_group_name`, `rds.group_replication_enabled` e `group_replication_group_seeds`. Per ulteriori informazioni sui parametri di un cluster attivo-attivo, consulta [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md). Se modifichi i parametri in un gruppo di parametri di database, verifica che il gruppo di parametri di database non sia associato ad altre istanze database nel cluster attivo-attivo. 1. Affinché le nuove impostazioni del parametro abbiano effetto, riavvia l’istanza database rimossa dal cluster attivo-attivo. Per istruzioni, consulta [Riavvio di un'istanza DB DB](USER_RebootInstance.md).