Limitazioni e considerazioni relative ai cluster attivi-attivi

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.

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.

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.

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.

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

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

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

È 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

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

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 e 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 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 è 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 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.

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

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.