Configura la replica da più fonti per Amazon Aurora MySQL

Con la replica da più fonti, puoi configurare un cluster Amazon Aurora MySQL DB come replica che riceve eventi di log binari da più di un database MySQL di origine. Ogni fonte può essere un'istanza DB RDS per MySQL, un altro cluster DB Aurora MySQL o un database MySQL eseguito all'esterno di Amazon RDS.

Multi-source la replica è supportata per i cluster DB Aurora MySQL che eseguono le seguenti versioni del motore:

• Aurora MySQL 8.4.8 e versioni successive

Per ulteriori informazioni sulla replica multi-source di MySQL, vedi MySQL Replication nella documentazione MySQL. Multi-Source

Nota

Multi-source la replica su Aurora MySQL utilizza l'istanza writer (primaria) del cluster Aurora DB come destinazione di replica. Tutte le stored procedure di replica devono essere richiamate mentre si è connessi all'istanza di scrittura del cluster.

Casi d’uso per la replica da più origini

Prendi in considerazione l'utilizzo della replica da più fonti su Aurora MySQL nei seguenti casi:

• Consolidamento degli shard: applicazioni che devono unire o combinare dati provenienti da più shard ospitati su istanze DB separate in un singolo cluster DB Aurora MySQL.

• Reporting consolidato: applicazioni che devono generare report da dati consolidati da più fonti, sfruttando le funzionalità di scalabilità in lettura di Aurora.

• Long-term backup: requisiti per creare backup consolidati a lungo termine dei dati distribuiti tra più istanze DB. MySQL-compatible

• Cross-engine migrazione: consolidamento dei dati da più istanze RDS per MySQL o server MySQL esterni in un singolo cluster Aurora MySQL durante la migrazione.

• Multi-tenant aggregazione: consolidamento di più database single-tenant in un cluster Aurora multi-tenant per l'ottimizzazione dei costi e una gestione semplificata.

Prerequisiti per la replica da più origini

Prima di configurare la replica da più fonti sul cluster Aurora MySQL DB, completate i prerequisiti standard per la replica binaria dei log, come descritto in. Configurazione del processo di replica dei log binari per Aurora MySQL Ciò include l'abilitazione della registrazione binaria su ogni sorgente, la conservazione dei log binari, la creazione di un utente di replica e la creazione di una copia o di un dump di ciascuna fonte. Per la replica da più fonti, ripeti questi passaggi per ogni istanza DB di origine.

Oltre ai prerequisiti standard, assicurati di soddisfare i seguenti requisiti specifici per la replica da più fonti.

• Verifica la versione e la configurazione del cluster di destinazione Aurora MySQL

  • Il cluster Aurora MySQL DB deve eseguire una versione del motore supportata (Aurora MySQL 8.4.8 e versioni successive).

  • Abilita l'autocommit sull'istanza del writer Aurora MySQL. Imposta il autocommit parametro su 1 nel gruppo di parametri del tuo cluster DB.

• Configura la connettività di rete per ogni fonte

  Per ogni istanza DB di origine, assicurati che l'istanza del writer Aurora MySQL possa connettersi all'origine sulla porta specificata. Le opzioni includono:

  • Se sia l'origine che la destinazione si trovano nello stesso VPC, configura il gruppo di sicurezza sull'istanza DB di origine per consentire le connessioni in entrata sulla porta 3306 (o sulla tua porta personalizzata) dal gruppo di sicurezza del cluster Aurora MySQL.

  • Se si trovano in VPC diversi, configura il peering VPC o utilizza un gateway di transito. Per ulteriori informazioni, consulta UN DB cluster in un VPC a cui accede un'istanza EC2 in un VPC diverso.

  • Se la fonte è esterna a AWS, assicurati che i percorsi di rete siano disponibili (ad esempio, tramite o una connessione VPN).

Nota

Poiché la replica da più fonti coinvolge più fonti, è necessario verificare la connettività a ciascuna fonte in modo indipendente. Assicurati che i gruppi di sicurezza e il routing soddisfino tutti gli endpoint di origine contemporaneamente.

Configura i canali di replica da più fonti sui cluster Aurora MySQL DB

La configurazione dei canali di replica da più fonti su Aurora MySQL è simile alla configurazione della replica da un'unica fonte. Per la replica da più fonti, è necessario innanzitutto abilitare la registrazione binaria sulle istanze di origine, importare i dati dalle sorgenti nel cluster Aurora MySQL e quindi avviare la replica da ciascuna origine utilizzando le coordinate di log binario o il posizionamento automatico GTID.

Importante

Tutte le stored procedure di replica da più fonti devono essere richiamate mentre si è connessi all'istanza writer del cluster DB Aurora MySQL. Se si verifica un failover, è necessario riconnettersi alla nuova istanza del writer.

Fase 1: Importazione dei dati dalle istanze DB di origine nel cluster Aurora MySQL

Esegui i seguenti passaggi per ogni istanza DB di origine.

1. Determina il file di log binario corrente e la posizione sull'istanza DB di origine.

   Per MySQL 8.4

   SHOW BINARY LOG STATUS;

   Per MySQL 8.0 e versioni precedenti

   SHOW MASTER STATUS;

   Output di esempio:

   +----------------------------+----------+
   | File                       | Position |
   +----------------------------+----------+
   | mysql-bin-changelog.000031 |      107 |
   +----------------------------+----------+

   Registra i valori e. File Position Ne avrai bisogno in una fase successiva.

2. Copia il database dall'istanza DB di origine al cluster Aurora MySQL utilizzando. mysqldump

   mysqldump --databases database_name \
     --single-transaction \
     --compress \
     --order-by-primary \
     -u RDS_user_name \
     -p'RDS_password' \
     --host=source-endpoint.region.rds.amazonaws.com | mysql \
     --host=aurora-cluster-endpoint.cluster-xxxxxx.region.rds.amazonaws.com \
     --port=3306 \
     -u aurora_user_name \
     -p'aurora_password'

   Suggerimento

   Per database di grandi dimensioni, prendi in considerazione l'utilizzo AWS DMS o la creazione di un'istantanea e il ripristino per ridurre i tempi di trasferimento dei dati.

3. Una volta completata l'importazione dei dati, puoi riattivare le scritture sull'istanza DB di origine se in precedenza l'avevi impostata su sola lettura.

Fase 2: Avviare la replica dalle istanze DB di origine al cluster Aurora MySQL

Per ogni istanza DB di origine, connettiti all'istanza writer del cluster DB Aurora MySQL ed esegui le stored procedure per configurare e avviare la replica su un canale.

Opzione A: utilizzo della posizione binaria del file di registro

CALL mysql.rds_set_external_source_for_channel(
  'source-endpoint.region.rds.amazonaws.com',
  3306,
  'repl_user',
  'password',
  'mysql-bin-changelog.000031',
  107,
  0,
  'channel_1'
);

CALL mysql.rds_start_replication_for_channel('channel_1');

Opzione B: utilizzo del posizionamento automatico GTID

Se le istanze DB di origine utilizzano la GTID-based replica, puoi utilizzare il posizionamento automatico invece di specificare le coordinate di log binarie:

CALL mysql.rds_set_external_source_with_auto_position_for_channel(
  'source-endpoint.region.rds.amazonaws.com',
  3306,
  'repl_user',
  'password',
  0,
  0,
  'channel_1'
);

CALL mysql.rds_start_replication_for_channel('channel_1');

Nota

Quando si utilizza il posizionamento automatico GTID, assicuratevi che enforce_gtid_consistency i parametri gtid_mode and siano configurati in modo coerente in tutte le istanze di origine e nel cluster Aurora MySQL.

Ripeti questi passaggi per ogni istanza DB di origine, specificando un nome di canale univoco per ciascuna (ad esempio,,). channel_1 channel_2 channel_3

Utilizza i filtri con la replica da più fonti

È possibile utilizzare i filtri di replica per specificare quali database e tabelle vengono replicati nella replica multi-source di Aurora MySQL. Per ulteriori informazioni sui filtri di replica, vedere. Configurazione dei filtri di replica con Aurora MySQL Di seguito vengono descritte le funzionalità di filtro aggiuntive a livello di canale disponibili con la replica da più fonti.

Con la replica da più fonti, è possibile configurare i filtri di replica a due livelli:

• Filtri globali: si applicano a tutti i canali. Impostato utilizzando il gruppo di parametri del cluster Aurora MySQL DB (ad esempio,replicate-do-db). replicate-ignore-db

• Channel-level filtri: si applicano solo a canali specifici, sovrascrivendo i filtri globali per quel canale.

Comportamento chiave

• È necessario riavviare la replica dopo aver modificato i filtri a livello di canale.

• Se non è configurato alcun filtro specifico per il canale, Aurora MySQL applica i filtri globali per quel canale.

• Se un filtro viene applicato sia a livello globale che a livello di canale, viene applicato solo il filtro a livello di canale per quel canale.

Monitora i canali di replica da più fonti

È possibile monitorare i singoli canali su una replica multi-source di Aurora MySQL utilizzando i seguenti metodi.

Usa SHOW REPLICA STATUS

Connettiti all'istanza writer del cluster Aurora MySQL DB ed esegui:

-- View status for all channels
SHOW REPLICA STATUS\G

-- View status for a specific channel
SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G

Campi chiave da monitorare:

Campo	Description
Replica_IO_Running	Se il I/O thread del canale è in esecuzione
Replica_SQL_Running	Se il thread SQL per il canale è in esecuzione
Seconds_Behind_Source	Ritardo di replica in secondi per il canale
Last_IO_Error	Ultimo I/O errore riscontrato sul canale
Last_SQL_Error	Ultimo errore SQL riscontrato sul canale
Source_Log_File	Il file di registro binario corrente che viene letto dall'origine
Exec_Source_Log_Pos	La posizione nel log binario applicata dal thread SQL

Usa le CloudWatch metriche

Monitora la ReplicationChannelLag CloudWatch metrica per ogni canale di replica. Questa metrica fornisce i dati di ritardo di replica per canale con un periodo di 60 secondi ed è disponibile per 15 giorni. Per individuare il ritardo del canale di replica, utilizzate l'identificatore dell'istanza del cluster Aurora DB e il nome del canale di replica come dimensioni. È possibile configurare gli CloudWatch allarmi per ricevere notifiche quando il ritardo supera una soglia specifica. Per ulteriori informazioni, consulta Monitoraggio dei parametri in un cluster di database Amazon Aurora.

Gestisci le stored procedure di replica da più fonti

Per informazioni sull'utilizzo delle stored procedure per configurare e gestire i canali di replica da più fonti, consulta. Gestione della replica da più origini

Considerazioni e best practice

Per consigli generali sull'ottimizzazione della replica, tra cui il formato di log binario, i worker paralleli e l'Enhanced Binlog, vedere. Ottimizzazione della replica dei log binari per Aurora MySQL Le considerazioni seguenti sono specifiche per la replica da più fonti.

Pianificazione delle risorse

Quando si eseguono più canali di replica, il numero totale di thread di replica allocati sulla replica è: (replica_parallel_workers+ 1 thread coordinatore) × numero di canali. Ad esempio, con il replica_parallel_workers valore predefinito di 4 e 10 canali, Aurora MySQL alloca 50 thread di replica. Prendi in considerazione l'utilizzo di una classe di istanze DB più grande (come db.r6g.2xlarge o superiore) in base al throughput totale della sorgente e al numero di canali. Ogni canale riceve lo stesso numero di lavoratori paralleli. MySQL non supporta l'impostazione di conteggi di lavoratori paralleli diversi per canale.

Evitare i conflitti

La replica multisource di MySQL non fornisce il rilevamento o la risoluzione dei conflitti. È necessario assicurarsi che le modifiche provenienti da diverse fonti non siano in conflitto. Le strategie più comuni includono:

• Ogni fonte scrive su un database o set di tabelle diverso.

• Utilizzate i filtri di replica (replicate-do-db) per assicurarvi che ogni canale replichi solo i database di cui è responsabile.

• Utilizzate l'replicate-rewrite-dbopzione per rimappare il nome di uno schema dall'origine a un nome diverso sulla replica, se necessario.

Per evitare scritture in conflitto dalle applicazioni che si connettono direttamente alla replica multisorgente, abilitate la modalità di sola lettura sul cluster Aurora MySQL: CALL mysql.rds_set_read_only(1);

Best practice operative

• Un canale alla volta: esegui le operazioni di gestione (ad esempio modifiche alla configurazione, ignoramento degli errori o starting/stopping replica) su un canale alla volta. Evita modifiche simultanee a più canali da connessioni diverse.

• Monitora il ritardo per canale: monitora il ritardo di replica per ogni canale utilizzando la metrica. ReplicationChannelLag CloudWatch

• Gestione del failover all'origine: se un'istanza DB di origine fallisce (ad esempio, un Multi-AZ failover Amazon RDS), il canale di replica potrebbe interrompersi con un errore. I/O Dopo che la fonte sarà nuovamente disponibile:

  • Chiama mysql.rds_start_replication_for_channel per riprendere la replica.

  • Se si verifica l'errore 1236 (file di registro non trovato), chiama mysql.rds_next_source_log_for_channel per passare al file di registro binario successivo.

• Failover Aurora writer: se l'istanza Aurora MySQL writer esegue il failover su un lettore, le configurazioni del canale di replica vengono conservate nello storage condiviso del cluster. Al termine del failover, i thread di replica vengono riavviati automaticamente sulla nuova istanza del writer.

Limitazioni

Le seguenti limitazioni sono specifiche della replica multi-source di Aurora MySQL. Per le limitazioni generali della replica multisorgente di MySQL (come la configurazione parallela dei lavoratori per canale), consulta MySQL Replication nella documentazione MySQL. Multi-Source

• Multi-source la replica è supportata solo su Aurora MySQL versione 8.4.8 e successive.

• Aurora MySQL supporta la configurazione di un massimo di 15 canali per una replica multi-sorgente.

Risoluzione dei problemi

Per la risoluzione generale dei problemi di replica, vedere. Problemi di replica relativi a Amazon Aurora MySQL Di seguito sono riportate note specifiche per la risoluzione dei problemi relativi alla replica da più fonti.

La configurazione del canale non è stata ripristinata dopo il ripristino dell'istantanea

Le istantanee del cluster DB non includono configurazioni con più canali di origine. Dopo il ripristino da un'istantanea:

• Riconfigurare ciascun canale utilizzando mysql.rds_set_external_source_for_channel o. mysql.rds_set_external_source_with_auto_position_for_channel

• Se si utilizza il posizionamento automatico GTID, la replica può riprendere automaticamente dal punto in cui era stata interrotta.

• Se si utilizzano posizioni binarie nei file di log, determinate la posizione corrente confrontando il log binario di origine con l'ultima transazione applicata sul cluster ripristinato.

Il ritardo di replica aumenta su uno o più canali

• Controlla la CPU e le metriche dell'istanza writer. I/O Se l'utilizzo delle risorse è elevato, aumenta la classe dell'istanza.

• Prendi in considerazione l'idea replica_parallel_workers di aumentarlo per migliorare la velocità effettiva dei thread SQL.

• Verifica che non vi siano transazioni o operazioni DDL di lunga durata sul canale che potrebbero bloccare il thread SQL.

• Verifica la presenza di configurazioni di filtro in conflitto che potrebbero causare l'elaborazione della replica, quindi elimina un numero elevato di eventi.

Esempio: configurazione completa da più fonti con tre fonti

L'esempio seguente dimostra la configurazione di un cluster Aurora MySQL DB come replica multisource di tre RDS per le istanze di origine MySQL.

Fase 1: Registrare le posizioni dei log binari su ogni sorgente

Connettiti a ciascuna fonte e registra le coordinate del log binario:

-- On source 1 (orders-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000045, Position: 3892

-- On source 2 (inventory-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000012, Position: 1567

-- On source 3 (analytics-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000078, Position: 9421

Fase 2: Importazione dei dati da ciascuna fonte

# Import from source 1
mysqldump --databases orders_db --single-transaction --compress \
 -u admin -p --host=orders-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

# Import from source 2
mysqldump --databases inventory_db --single-transaction --compress \
 -u admin -p --host=inventory-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

# Import from source 3
mysqldump --databases analytics_db --single-transaction --compress \
 -u admin -p --host=analytics-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

Fase 3: Configurazione e avvio dei canali di replica

Connettiti all'istanza Aurora MySQL writer:

-- Configure channel for source 1 (orders)
CALL mysql.rds_set_external_source_for_channel(
 'orders-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000045', 3892, 0, 'orders_channel'
);

-- Configure channel for source 2 (inventory)
CALL mysql.rds_set_external_source_for_channel(
 'inventory-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000012', 1567, 0, 'inventory_channel'
);

-- Configure channel for source 3 (analytics)
CALL mysql.rds_set_external_source_for_channel(
 'analytics-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000078', 9421, 0, 'analytics_channel'
);

-- Start all channels
CALL mysql.rds_start_replication_for_channel('orders_channel');
CALL mysql.rds_start_replication_for_channel('inventory_channel');
CALL mysql.rds_start_replication_for_channel('analytics_channel');

Passaggio 4: verifica lo stato della replica

SHOW REPLICA STATUS\G

Conferma che per ogni canale:

• Replica_IO_Running: Yes

• Replica_SQL_Running: Yes

• Seconds_Behind_Source: 0(o un valore basso)

Risorse correlate

• MySQL Multi-Source Replication — documentazione MySQL

• Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)— Guida per l'utente di Aurora

• Ottimizzazione della replica dei log binari per Aurora MySQL— Guida per l'utente di Aurora

• Configurazione dei filtri di replica con Aurora MySQL— Guida per l'utente di Aurora

• Utilizzo della GTID-based replica— Guida per l'utente di Aurora