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à.

# Limitazioni e considerazioni relative ai cluster attivi-attivi
<a name="mysql-active-active-clusters-considerations-limitations"></a>

Active-active i cluster in Amazon RDS offrono disponibilità e scalabilità migliorate distribuendo 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
<a name="mysql-active-active-clusters-limitations"></a>

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).
+ Blue/green le distribuzioni non sono supportate per le istanze DB in 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 DB in un cluster Multi-AZ DB non possono essere aggiunte a un cluster attivo-attivo. Tuttavia, le istanze DB in una distribuzione di istanze Multi-AZ DB possono essere aggiunte a un cluster attivo-attivo. Per ulteriori informazioni, consulta [Configurazione e gestione di una Multi-AZ distribuzione 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.
+ Non-InnoDB le tabelle non vengono replicate in un cluster attivo-attivo.
+ Active-active i cluster non supportano istruzioni DML e DDL simultanee su diverse istanze DB del cluster.
+ Non è possibile configurare un cluster attivo-attivo per utilizzare la modalità primaria singola per la modalità di replica di gruppo. Per questa configurazione, consigliamo invece di utilizzare un cluster DB. Multi-AZ Per ulteriori informazioni, consulta [Multi-AZ Implementazioni di cluster DB per Amazon RDS](multi-az-db-clusters-concepts.md).
+ Multi-source la replica non è supportata per le istanze DB in 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
<a name="mysql-active-active-clusters-considerations"></a>

Prima di utilizzare i cluster attivi-attivi di RDS per MySQL, esamina le considerazioni e le best practice seguenti:
+ Active-active i cluster non possono avere più di nove istanze DB.
+ 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, [ Fault-tolerance](https://dev.mysql.com/doc/refman/8.0/en/group-replication-fault-tolerance.html)consulta la documentazione di 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 database impostando il relativo parametro `rds.group_replication_enabled` su `1` nel gruppo di parametri del database, ma la replica non è iniziata o non è stato possibile avviarla, l’istanza database viene posta in modalità super-read-only per evitare incoerenze nei dati. Per informazioni sulla modalità super-read-only, consulta la [documentazione 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 DB in una distribuzione di istanze Multi-AZ DB a un cluster attivo-attivo esistente. È inoltre possibile convertire un'istanza Single-AZ DB in un cluster attivo-attivo in una Multi-AZ distribuzione di istanze DB. Se un'istanza DB primaria in una Multi-AZ distribuzione fallisce, l'istanza primaria passa all'istanza di standby. La nuova istanza database primaria si unisce automaticamente allo stesso cluster al termine del failover. Per ulteriori informazioni sulla distribuzione delle istanze Multi-AZ DB, consulta. [Multi-AZ Implementazioni di istanze DB 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).
+ Active-active i cluster possono utilizzare SSL per le connessioni tra istanze DB. Per configurare le connessioni SSL, impostare i parametri [ group\_replication\_recovery\_use\_ssl](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_recovery_use_ssl) e [ group\_replication\_ssl\_mode](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\_replication\_ssl\_mode](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\_replication\_enforce\_update\_everywhere\_checks](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.
+ Active-active i cluster supportano solo RDS per istanze DB 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 database non viene ripristinata, si consiglia di sostituirla con una nuova istanza eseguendo un ripristino point-in-time con un’istanza database integra nel cluster. Per istruzioni, consulta [Aggiunta di un’istanza database a un cluster attivo-attivo tramite il ripristino 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.