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.

Le implementazioni blu/verde non sono supportate nelle istanze database di un cluster attivo-attivo. Per ulteriori informazioni, consulta Utilizzo delle implementazioni blu/verde Amazon RDS 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 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.

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.

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.

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 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, consulta Fault-tolerance 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 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 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.

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

I cluster attivi-attivi possono utilizzare SSL per le connessioni tra istanze database. 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.

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 database non viene ripristinata, si consiglia di sostituirla con una nuova istanza eseguendo un recupero 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 recupero 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.