View a markdown version of this page

Configura la replica ritardata con Amazon Aurora MySQL - Amazon Aurora
Casi d'uso per la replica ritardataConfigura la replica esterna con un ritardoModifica la replica ritardata per una replica di lettura esistenteImposta una posizione per interrompere la replica su una replica di letturaPromuovi una replica lettaArgomenti correlati

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

Configura la replica ritardata con Amazon Aurora MySQL

Puoi utilizzare la replica ritardata come strategia per il disaster recovery con Aurora MySQL. Con la replica ritardata puoi specificare il tempo minimo, in secondi, di ritardo della replica rispetto all'origine nella replica di lettura. In caso di emergenza, come ad esempio l'eliminazione accidentale di una tabella, completa la seguente procedura per risolvere velocemente il problema:

  1. Interrompi la replica sulla replica di lettura prima che l'origine invii la modifica che ha causato il disastro. Usa la procedura archiviata mysql.rds_stop_replication per arrestare la replica.

  2. Avvia la replica e specifica che la replica si arresta automaticamente in corrispondenza di una posizione del file di log. Puoi specificare una posizione prima dell'emergenza utilizzando la procedura archiviata mysql.rds_start_replication_until(Aurora MySQL versione 3).

  3. Promuovi la replica di lettura come nuovo cluster DB di origine utilizzando le istruzioni inPromozione di una replica di lettura a cluster di database per Aurora MySQL.

Nota

Aurora MySQL supporta la replica ritardata per la versione 8.4.8 e successive.

  • Utilizza le procedure archiviate per configurare la replica ritardata. Non è possibile configurare la replica ritardata con, la o l' Console di gestione AWS API Amazon RDS. AWS CLI

  • Puoi utilizzare la replica basata sugli identificatori di transazione globali (GTID) in una configurazione di replica ritardata su Aurora MySQL versione 8.4.8 e successive.

  • Se utilizzate la GTID-based replica, utilizzate la stored procedure anziché la stored procedure. mysql.rds_start_replication_until_gtid (Aurora MySQL versione 3) mysql.rds_start_replication_until(Aurora MySQL versione 3)

  • Aurora MySQL supporta la replica da più fonti con un massimo di 15 canali. Utilizza le varianti di _for_channel procedura per configurare la replica ritardata su canali specifici.

Casi d'uso per la replica ritardata

La replica ritardata su Aurora MySQL si applica alla replica basata su log binari. Ciò include la replica da un cluster Aurora MySQL writer DB a una replica binlog, da una fonte MySQL esterna in un cluster DB Aurora MySQL o su canali di replica multi-sorgente. Non si applica alle repliche Aurora all'interno di un singolo cluster DB, perché vengono lette dallo storage condiviso del cluster anziché dal log binario. I casi d'uso più comuni includono quanto segue:

  • Disaster recovery in caso di errore dell'operatore: mantiene una replica binlog che ritarda l'origine di un intervallo prestabilito. Se un'istruzione distruttiva viene eseguita involontariamente (ad esempio, elimina una tabella), interrompi la replica sulla replica ritardata prima che l'origine applichi la modifica. Quindi vai avanti fino a poco prima dell'evento usando o. mysql.rds_start_replication_until(Aurora MySQL versione 3) mysql.rds_start_replication_until_gtid (Aurora MySQL versione 3) Infine, promuovi la replica. Questo approccio fornisce un percorso di ripristino più rapido rispetto al ripristino point-in-time, che richiede un crash recovery e la riproduzione dei log binari.

  • Protezione dal danneggiamento logico dei dati: una replica ritardata protegge anche da una distribuzione o migrazione errata dell'applicazione che danneggia gradualmente i dati. Poiché la replica mantiene lo stato precedente al danneggiamento per tutta la durata del ritardo, è possibile ripristinarla prima che vengano applicate le transazioni difettose.

  • Versione principale e blue/green aggiornamenti: mantieni una replica del registro binario ritardata durante un aggiornamento o una blue/green distribuzione come rete di sicurezza, in modo da poter tornare a uno stato noto come valido se l'aggiornamento introduce problemi.

  • Change data capture (CDC) da una fonte esterna: quando si importano modifiche in un cluster Aurora MySQL DB da una fonte MySQL esterna, un ritardo intenzionale fornisce un buffer controllato prima che le modifiche vengano applicate a valle.

  • Ispezione della cronologia senza ripristino: interroga la replica ritardata per vedere come apparivano i dati in precedenza. Ciò è utile per eseguire il debug, il controllo o l'analisi delle modifiche, senza eseguire il provisioning di un clone o eseguire un ripristino point-in-time.

  • Verifica del comportamento dell'applicazione in caso di ritardo di replica: utilizzate un ritardo gonfiato artificialmente per convalidare il comportamento dell'applicazione in caso di ritardo di una replica ed eseguire test di regressione per condizioni sensibili al ritardo, senza dover generare un carico elevato per riprodurre il ritardo.

Configura la replica esterna con un ritardo

Per configurare una fonte esterna con replica ritardata, utilizza la mysql.rds_set_external_source_with_delay (Aurora MySQL versione 8.4.8 e successive) stored procedure. Per ulteriori informazioni su tutte le stored procedure di replica, vedere. Configurazione, avvio e arresto della replica dei log binari (binlog)

Esempio (canale predefinito): 

CALL mysql.rds_set_external_source_with_delay(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600);

Esempio (canale specifico): 

CALL mysql.rds_set_external_source_with_delay_for_channel(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600,
  'channel_1');

Parametri:

host_name

Il nome host o l'indirizzo IP della fonte esterna.

host_port

Il numero di porta della fonte esterna.

replication_user_name

L'utente della replica sulla fonte esterna.

replication_user_password

La password per l'utente di replica.

mysql_binary_log_file_name

Il nome del file di registro binario sull'origine esterna.

mysql_binary_log_file_location

La posizione nel file di log binario in cui iniziare la replica.

ssl_encryption

Impostate questo parametro per 1 abilitare la crittografia SSL per la connessione di replica o per 0 disabilitare la crittografia SSL.

delay

Il ritardo minimo in secondi (0—259.200).

channel

(solo variante for_channel) Il nome del canale per la replica da più fonti.

Vincoli:

  • Aurora MySQL supporta un massimo di 15 canali di replica.

  • Ogni canale deve essere replicato da una fonte diversa (combinazione host:porta).

  • Il ritardo deve essere compreso tra 0 e 259.200 secondi (72 ore).

  • Interrompere la replica prima di modificare la configurazione del canale.

Modifica la replica ritardata per una replica di lettura esistente

Per modificare la replica ritardata per una replica di lettura esistente, esegui la stored procedure mysql.rds_set_source_delay (Aurora MySQL versione 8.4.8 e successive). Per ulteriori informazioni su tutte le stored procedure di replica, vedere. Configurazione, avvio e arresto della replica dei log binari (binlog)

Per modificare la replica ritardata per una replica di lettura esistente:

  1. Utilizzando un client MySQL, connettiti alla replica di lettura come utente amministratore.

  2. Usa la procedura archiviata mysql.rds_stop_replication per arrestare la replica.

  3. Eseguire la procedura archiviata mysql.rds_set_source_delay (Aurora MySQL versione 8.4.8 e successive).

  4. Usare la procedura archiviata mysql.rds_start_replication per avviare la replica.

Esempio (canale predefinito): 

CALL mysql.rds_set_source_delay(3600);

Esempio (canale specifico): 

CALL mysql.rds_set_source_delay_for_channel(3600, 'channel_1');

Ciò specifica che la replica sulla replica letta è ritardata di almeno un'ora (3.600 secondi). Il valore del ritardo deve essere compreso tra 0 e 259.200 secondi (72 ore).

Nota

Interrompi la replica prima di impostare il ritardo. Se la replica è in esecuzione, viene visualizzato un messaggio di errore che richiede di chiamare prima mysql.rds_stop_replication (o mysql.rds_stop_replication_for_channel indicare un canale specifico).

Imposta una posizione per interrompere la replica su una replica di lettura

Dopo aver arrestato la replica sulla replica di lettura, puoi avviare la replica e poi arrestarla in corrispondenza della posizione del file di log binario specificato utilizzando la procedura archiviata mysql.rds_start_replication_until(Aurora MySQL versione 3).

Per avviare la replica e fermarla in una posizione specifica:

  1. Utilizzando un client MySQL, connettiti alla replica di lettura come utente amministratore.

  2. Eseguire la procedura archiviata mysql.rds_start_replication_until(Aurora MySQL versione 3).

Esempio:

CALL mysql.rds_start_replication_until(
  'mysql-bin-changelog.000777',
  120);

Questo avvia la replica e replica le modifiche fino a raggiungere la posizione 120 nel file di registro binario. mysql-bin-changelog.000777 In uno scenario di disaster recovery, si supponga che la posizione 120 si trovi poco prima del disastro.

La replica si interrompe automaticamente quando Aurora MySQL raggiunge il punto di arresto. Aurora MySQL genera il seguente evento:. Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure

Se stai usando la GTID-based replica, usa invece la mysql.rds_start_replication_until_gtid (Aurora MySQL versione 3) stored procedure.

Promuovi una replica letta

Dopo l'interruzione della replica, in uno scenario di disaster recovery, è possibile promuovere una replica di lettura come nuovo cluster DB di origine. Per informazioni sulla promozione di una replica di lettura, consulta Promozione di una replica di lettura a cluster di database per Aurora MySQL.

Argomenti correlati