Replica con Amazon Aurora

Esistono varie opzioni di replica con Aurora. Ogni cluster di database Aurora dispone di una replica incorporata tra più istanze database nello stesso cluster. Inoltre, è possibile impostare la replica con il cluster Aurora come origine o destinazione. Quando si replicano dati all'interno o all'esterno di un cluster Aurora, è possibile scegliere tra funzionalità incorporate come database globali Aurora o meccanismi di replica tradizionali per i motori MySQL o PostgreSQL DB. È possibile scegliere le opzioni appropriate in base alle quali offrire la giusta combinazione di disponibilità elevata, convenienza e prestazioni per le esigenze specifiche. Le seguenti sezioni spiegano come e quando scegliere ogni tecnica.

Repliche di Aurora

Quando si crea una seconda istanza database (o una terza e così via) in un cluster di database con provisioning di Aurora, Aurora imposta automaticamente la replica dall'istanza database writer a tutte le altre istanze database. Queste altre istanze database sono di sola lettura e sono note come repliche di Aurora. Vengono anche definite istanze reader in relazione ai modi in cui è possibile combinare istanze database writer e reader all'interno di un cluster.

Le repliche di Aurora hanno due scopi principali. È possibile inviare query per ridimensionare le operazioni di lettura per l'applicazione. Generalmente, si esegue la connessione all'endpoint di lettura del cluster. In questo modo, Aurora può distribuire il carico per le connessioni di sola lettura su tutte le repliche di Aurora presenti nel cluster. Le repliche di Aurora contribuiscono anche ad aumentare la disponibilità. Se l'istanza writer in un cluster non è disponibile, Aurora promuove automaticamente una delle istanze reader affinché prenda il suo posto come nuovo writer.

Un cluster di database di Aurora può contenere fino a 15 repliche di Aurora. È possibile distribuire le repliche di Aurora nelle zone di disponibilità sulle quali si estende un cluster di database in una regione AWS .

I dati nel cluster di database dispongono di funzionalità di elevata disponibilità e affidabilità, indipendentemente dalle istanze database nel cluster. Se hai familiarità con le funzionalità di storage di Aurora, consulta Panoramica dell'archiviazione di Amazon Aurora. Il volume del cluster di database si compone di più copie dei dati per il cluster di database. L'istanza primaria e le repliche di Aurora nel cluster di database vedono tutti i dati nel volume cluster come un singolo volume logico.

Di conseguenza, tutte le repliche di Aurora restituiscono gli stessi dati per i risultati di query con un ritardo di replica minimo. Questo ritardo di replica è solitamente molto inferiore a 100 millisecondi dopo che l'istanza primaria scrive un aggiornamento. Il ritardo di replica varia in base alla velocità di modifica del database. Pertanto, nei periodi in cui si verificano numerose operazioni di scrittura per il database, potresti riscontrare un aumento del ritardo di replica.

Nota

Aurora Replica si riavvia quando perde la comunicazione con l'istanza Writer DB per più di 60 secondi nelle seguenti versioni di Aurora PostgreSQL:

• 14.6 e versioni precedenti

• 13.9 e versioni precedenti

• 12.13 e versioni precedenti

• Tutte le versioni di Aurora PostgreSQL 11

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 cluster di database, è necessaria solo una minima quantità di operazioni per replicare una copia dei dati per ciascuna replica di Aurora.

Per aumentare la disponibilità puoi servirti delle repliche di Aurora come target di failover. Pertanto se l'istanza primaria non va a buon fine, una replica di Aurora viene promossa a istanza primaria. Si verifica una breve interruzione durante la quale le richieste di lettura e scrittura inviate all'istanza primaria falliscono con un'eccezione.

Tuttavia, promuovere una replica di Aurora tramite failover è un'operazione molto più veloce rispetto a ricreare l'istanza primaria. Se il cluster di database Aurora non include nessuna replica Aurora, il cluster di database non sarà disponibile mentre l’istanza database esegue il ripristino dall’errore.

Quando si verifica il failover, alcune repliche di Aurora possono essere riavviate, a seconda della versione del motore di database. Ad esempio, in Aurora MySQL 2.10 e versioni successive, durante un failover Aurora riavvia solo l'istanza database di scrittura e la destinazione del failover. Per ulteriori informazioni sul comportamento di riavvio di diverse versioni del motore di database Aurora, consulta Riavvio di un cluster Amazon Aurora DB o di un'istanza Amazon Aurora DB. Per informazioni su cosa succede alle cache delle pagine durante il riavvio o il failover, consulta Cache delle pagine superstite.

Per gli scenari di disponibilità elevata, è consigliato creare una o più repliche di Aurora Dovrebbero essere della stessa classe delle istanze database dell'istanza primaria e in diverse zone di disponibilità per il cluster DB Aurora. Per ulteriori informazioni sulle repliche Aurora come destinazioni di failover, consulta Tolleranza ai guasti di un cluster DB Aurora.

Non è possibile creare una replica Aurora crittografata per un cluster database Aurora non crittografato. Non è possibile creare una replica Aurora non crittografata per un cluster database Aurora crittografato.

Suggerimento

È possibile utilizzare le repliche di Aurora all'interno di un cluster di Aurora come unica forma di replica per mantenere i dati altamente disponibili. È possibile anche combinare la replica di Aurora incorporata con gli altri tipi di replica. In questo modo è possibile fornire un livello superiore di disponibilità elevata e distribuzione geografica dei dati.

Per informazioni dettagliate su come creare una replica di Aurora, consulta Aggiunta di repliche di Aurora a un cluster di database.

Replica con Aurora MySQL

Oltre alle repliche di Aurora, sono disponibili le seguenti opzioni di replica con Aurora MySQL:

• Cluster Aurora MySQL DB in diverse regioni. AWS

  • È possibile replicare i dati in più regioni utilizzando un database globale di Aurora. Per dettagli, consultare Elevata disponibilità nelle regioni AWS con database globali Aurora.

  • È possibile creare una replica di lettura Aurora di un cluster Aurora MySQL DB in una AWS regione diversa, utilizzando la replica del log binario MySQL (binlog). Ogni cluster può avere fino a cinque repliche di lettura create in questo modo, ciascuna in una regione geografica diversa.

• Due cluster database Aurora MySQL nella stessa regione , utilizzando una replica del log binario (binlog) MySQL.

• Una istanza database RDS per MySQL come origine di dati e un cluster database Aurora MySQL, creando una replica di lettura Aurora di una istanza database RDS per MySQL. In genere, è possibile utilizzare questo approccio per la migrazione a Aurora MySQL piuttosto che per le repliche in corso.

Per ulteriori informazioni sulla replica con Aurora MySQL, consulta Replica con Amazon Aurora MySQL.

Replica con Aurora PostgreSQL

Oltre alle repliche di Aurora, sono disponibili le seguenti opzioni di replica con Aurora PostgreSQL:

• Un database globale Aurora ha un cluster database Aurora primario in una regione e un massimo di cinque cluster database secondari di sola lettura in regioni diverse. In altre parole, Aurora PostgreSQL non supporta le repliche Aurora tra regioni. Tuttavia, puoi utilizzare il database globale Aurora per scalare le funzionalità di lettura del cluster Aurora PostgreSQL DB su più di una regione e per raggiungere gli obiettivi di disponibilità. AWS Per ulteriori informazioni, consulta Utilizzo degli Amazon Aurora Global Database.

• Due cluster di database Aurora PostgreSQL nella stessa regione, utilizzando la caratteristica di replica logica di PostgreSQL.

• Un'istanza del database RDS for PostgreSQL come origine dei dati e un cluster di database Aurora PostgreSQL, creando una replica di lettura Aurora di un'istanza database RDS for PostgreSQL. In genere, è possibile utilizzare questo approccio per la migrazione a Aurora PostgreSQL piuttosto che per le repliche in corso.

Per ulteriori informazioni sulla replica con Aurora PostgreSQL, consulta Replica con Amazon Aurora PostgreSQL.