Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari) - Amazon Aurora
Impostazione della replica con MySQL e un altro cluster di database AuroraSincronizzazione delle password tra origine di replica e destinazioneFermare la replica tra Aurora e MySQL o tra Aurora e un altro cluster di database AuroraUtilizzo di Amazon Aurora per dimensionare le letture per il database MySQLOttimizzazione della replica dei log binariConfigurazione del file di log binario avanzato

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

Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari)

In quanto Amazon Aurora MySQL è compatibile con MySQL, puoi impostare la replica tra un database MySQL e un cluster di database Amazon Aurora MySQL. Questo tipo di replica utilizza la replica dei log binari MySQL ed è comunemente indicato come replica binlog. Se si utilizza la replica dei log binari con Aurora, si consiglia di eseguire sul database MySQL versione 5.5 o successiva. È possibile impostare la replica in cui il cluster Aurora MySQL del database è il master di replica o la replica. È possibile eseguire la replica con un'istanza DB Amazon RDS MySQL, un database MySQL esterno su Amazon RDS o un altro cluster DB Aurora MySQL.

Nota

Non è possibile utilizzare la replica binlog da o verso determinati tipi di cluster di database Aurora. In particolare, la replica binlog non è disponibile per i cluster Aurora Serverless v1. Se l'istruzione SHOW MASTER STATUS e SHOW SLAVE STATUS (Aurora MySQL versione 2) o SHOW REPLICA STATUS (Aurora MySQL versione 3) non restituisce alcun output, controlla che il cluster in uso supporti la replica binlog.

In Aurora MySQL versione 3 non è possibile replicare nel database di sistema mysql utilizzando la replica del log binario. Le password e gli account non vengono replicati dalla replica binlog in Aurora MySQL versione 3. Pertanto, le istruzioni Data Control Language (DCL) come CREATE USER, GRANT e REVOKE non vengono replicate.

Puoi anche eseguire una replica con un'istanza database RDS per MySQL o un cluster di database Aurora MySQL in un'altra Regione AWS. Quando esegui la replica su più server Regioni AWS, assicurati che i cluster e le istanze DB siano accessibili pubblicamente. Se i cluster di database Aurora MySQL si trovano in sottoreti private nel VPC, usa il peering VPC tra le Regioni AWS. Per ulteriori informazioni, consulta Un cluster database in un VPC a cui accede un'istanza EC2 in un VPC diverso.

Se si desidera configurare la replica tra un cluster Aurora MySQL DB e un cluster Aurora MySQL DB in un altro, è possibile creare un cluster Aurora MySQL DB come replica di lettura Regione AWS in un cluster DB diverso da quello di origine. Regione AWS Per ulteriori informazioni, consulta Repliche di cluster di database Amazon Aurora MySQL tra Regioni AWS.

Con Aurora MySQL versione 2 e 3, è possibile effettuare la replica tra Aurora MySQL e un'origine o una destinazione esterna che utilizza gli identificatori globali di transazione (GTID) per la replica. Assicurati che i parametri basati su GTID nel cluster di database Aurora MySQL presentino impostazioni compatibili con lo stato GTID del database esterno. Per informazioni su come effettuare questa operazione, consulta Utilizzo della replica basata su GTID. In Aurora MySQL versione 3.01 e successive, puoi scegliere come assegnare GTID alle transazioni replicate da una fonteche non utilizza GTID. Per informazioni sulla procedura archiviata che controlla tale impostazione, vedere mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL versione 3).

avvertimento

Quando esegui la replica tra Aurora MySQL e MySQL, assicurati di utilizzare solo tabelle InnoDB. Se hai tabelle MyISAM, che desideri replicare, puoi convertirle in InnoDB prima di impostare la replica con il seguente comando. 

alter table <schema>.<table_name> engine=innodb, algorithm=copy;

Impostazione della replica con MySQL e un altro cluster di database Aurora

L'impostazione della replica MySQL con Aurora MySQL prevede le seguenti fasi che vengono discusse in dettaglio:

1. Abilitare l'accesso binario nella fonte di replica

2. Mantieni i log binari nel master di replica fino a quando non sono più necessari

3. Crea una copia o un dump della tua fonte di replica

4. Carica il dump nella destinazione della replica (se necessario)

5. Creazione di un utente di replica sull’origine di replica

6. Abilitare la replica nel target di replica

7. Monitora la replica

1. Abilitare l'accesso binario nella fonte di replica

Seguono le istruzioni su come abilitare l'accesso binario nella fonte di replica per il motore del database.

2. Mantieni i log binari nel master di replica fino a quando non sono più necessari

Quando si utilizza la replica dei log binari MySQL, Amazon RDS non gestisce il processo di replica. Come risultato, devi assicurarti che i file binlog nel master di replica siano mantenuti finché le modifiche vengono applicate alla replica. Questa manutenzione aiuta a ripristinare il database di origine in caso di errore.

Utilizza le istruzioni seguenti per mantenere i registri binari per il motore di database.

3. Crea una copia o un dump della tua fonte di replica

Si utilizza un'istantanea, un clone o un dump della fonte di replica per caricare una copia di base dei dati sulla replica. Quindi si inizia a replicare da quel punto.

Utilizza le seguenti istruzioni per creare una copia o un dump della fonte di replica per il tuo motore di database.

4. Carica il dump nella destinazione della replica (se necessario)

Se prevedi di caricare dati da un dump di un database MySQL esterno ad Amazon RDS, potresti voler creare un'istanza EC2 su cui copiare i file di dump. Quindi puoi caricare i dati nel tuo cluster DB o nell'istanza DB da quell'istanza EC2. Utilizzando questo approccio, puoi comprimere i file dump prima di copiarli nell'istanza EC2 per ridurre i costi di rete associati con la copia dei dati in Amazon RDS. Puoi anche crittografare il file o i file dump per assicurare i dati mentre vengono trasferiti nella rete.

Nota

Se crei un nuovo cluster Aurora MySQL DB come destinazione della replica, non è necessario caricare un file di dump:

Utilizza le seguenti istruzioni per caricare il dump della fonte di replica nella destinazione di replica per il motore di database.

5. Creazione di un utente di replica sull’origine di replica

Crea un ID utente sull’origine utilizzato solamente per la replica. L'esempio seguente riguarda RDS for MySQL o database di origine MySQL esterni.

mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';

Per i database di origine Aurora MySQL, il parametro del cluster skip_name_resolve DB è impostato su 1 (ON) e non può essere modificato, quindi è necessario utilizzare un indirizzo IP per l'host anziché un nome di dominio. Per ulteriori informazioni, consulta skip_name_resolve nella documentazione di MySQL.

mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';

L'utente richiede i privilegi REPLICATION CLIENT e REPLICATION SLAVE. Concedi questi privilegi all'utente.

Se non hai bisogno di utilizzare la replica crittografata, richiedi le connessioni SSL per l'utente replica. Ad esempio, è possibile utilizzare una delle seguenti istruzioni per richiedere connessioni SSL sull'account utente. repl_user

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';

GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
Nota

Se REQUIRE SSL non è incluso, la connessione di replica potrebbe ridiventare una connessione non crittografata.

6. Abilitare la replica nel target di replica

Raccomandiamo di fare una snapshot manuale del cluster di database Aurora MySQL o del target di replica dell'istanza database RDS for MySQL, prima di abilitare la replica. Se c'è un problema e devi ristabilire la replica con il cluster di database o il target di replica dell'istanza database, puoi ripristinare il cluster di database o l'istanza database da questa snapshot invece di dover importare di nuovo i dati nel target di replica.

Utilizza le istruzioni seguenti per attivare la replica del motore di database.

Se la replica ha esito negativo, può verificarsi un notevole aumento di I/O non intenzionale sulla replica, che può compromettere le prestazioni. Se la replica non riesce o non è più necessaria, è possibile eseguire la stored procedure mysql.rds_reset_external_master (Aurora MySQL versione 2) o mysql.rds_reset_external_source (Aurora MySQL versione 3) per rimuovere la configurazione della replica.

Definire una posizione per arrestare la replica su una replica di lettura

In Aurora MySQL versione 3.04 e successive, puoi avviare una replica e quindi arrestarla in una posizione di file di log binario specifica mediante la stored procedure mysql.rds_start_replication_until (Aurora MySQL versione 3).

Per avviare la replica su una replica di lettura e arrestare la replica in corrispondenza di una posizione specifica

  1. Utilizzando un client MySQL, connettiti alla replica del cluster Aurora MySQL DB come utente principale.

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

    L'esempio seguente avvia la replica e replica le modifiche fino a raggiungere la posizione 120 nel file di log binario mysql-bin-changelog.000777. In caso di disaster recovery, presumere che la posizione 120 si riferisca al momento immediatamente precedente l'errore.

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

La replica si arresta automaticamente quando viene raggiunto il punto di arresto. Viene generato il seguente evento RDS: Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure.

Se si utilizza la replica basata su GTID, scegliere la stored procedure mysql.rds_start_replication_until_gtid (Aurora MySQL versione 3) invece della mysql.rds_start_replication_until (Aurora MySQL versione 3). Per ulteriori informazioni sulla replica basata su GTID, consultare Utilizzo della replica basata su GTID.

7. Monitora la replica

Quando imposti la replica MySQL con un cluster di database Aurora MySQL, devi monitorare gli eventi di failover per il cluster di database Aurora MySQL quando è il target di replica. Se accade un failover, il cluster di database che è il target di replica potrebbe essere ricreato in un nuovo host con un indirizzo di rete diverso. Per informazioni su come monitorare gli eventi di failover, consulta Utilizzo della notifica degli eventi di Amazon RDS.

È anche possibile monitorare quanto è indietro la destinazione della replica rispetto all'origine eseguendo la connessione alla destinazione della replica e il comando SHOW SLAVE STATUS (Aurora MySQL versione 2) o SHOW REPLICA STATUS (Aurora MySQL versione 3). Nell'output del comando, il campo Seconds Behind Master indica quanto è indietro il target di replica rispetto al master di replica.

Sincronizzazione delle password tra origine di replica e destinazione

Quando si modificano gli account utente e le password nell'origine di replica utilizzando le istruzioni SQL, tali modifiche vengono replicate automaticamente nella destinazione di replica.

Se si utilizza l'API AWS Management Console AWS CLI, the o RDS per modificare la password principale sull'origine della replica, tali modifiche non vengono replicate automaticamente nella destinazione di replica. Se si desidera sincronizzare l'utente principale e la password principale tra il sistema di origine e quello di destinazione, è necessario apportare la stessa modifica alla destinazione di replica.

Fermare la replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora

Per fermare la replica dei log binari con un'istanza database MySQL, un database MySQL esterno o un altro cluster di database Aurora, segui questa procedura, che viene illustrata nel dettaglio nel seguente argomento.

1. Arrestare la replica dei log binari nella destinazione di replica

2. Disabilitare l'accesso binario alla fonte di replica

1. Arrestare la replica dei log binari nella destinazione di replica

Usa le seguenti istruzioni per arrestare la replica dei log binari del motore di database.

2. Disabilitare l'accesso binario alla fonte di replica

Usa le seguenti istruzioni per disattivare la registrazione dei log binari nell'origine della replica per il motore del database.

Utilizzo di Amazon Aurora per dimensionare le letture per il database MySQL

Puoi utilizzare Amazon Aurora con l'istanza database MySQL per usufruire delle funzionalità di dimensionamento della lettura di Amazon Aurora ed espandere il reale carico di lavoro della tua istanza database MySQL. Per utilizzare Aurora per ridimensionare le operazioni di lettura dell'istanza database MySQL, crea un cluster di database Amazon Aurora MySQL e rendilo una replica di lettura per l'istanza database MySQL. Ciò si applica a un'istanza database RDS for MySQL o a un database MySQL in esecuzione esternamente a Amazon RDS.

Per informazioni su come creare un cluster di database Amazon Aurora, consulta Creazione di un cluster database Amazon Aurora.

Quando si configura la replica tra l'istanza database MySQL e il cluster di database Amazon Aurora, assicurarsi di seguire queste linee guida:

  • Utilizzare l'indirizzo dell'endpoint del cluster di database di Amazon Aurora quando si fa riferimento al cluster di database Amazon Aurora MySQL. Se si verifica un failover, la replica di Aurora promossa a istanza principale per il cluster di database Aurora MySQL continua a utilizzare l'indirizzo dell'endpoint del cluster di database.

  • Conservare i binlog sull'istanza di scrittura finché non si ha la conferma che siano stati applicati alla replica di Aurora. Questa manutenzione assicura il ripristino dell'istanza di lettura nel caso di errori.

Importante

Quando si utilizza la replica auto-gestita, si ha la responsabilità di monitorare e risolvere eventuali problemi di replica. Per ulteriori informazioni, consulta Diagnosi e risoluzione del ritardo tra repliche di lettura.

Nota

Le autorizzazioni richieste per avviare la replica su un cluster di database Aurora MySQL sono limitate e non disponibili per l'utente master Amazon RDS. Pertanto sarà necessario utilizzare le procedure mysql.rds_set_external_master (Aurora MySQL versione 2) o mysql.rds_set_external_source (Aurora MySQL versione 3) e mysql.rds_start_replication per impostare la replica tra il cluster di database Aurora MySQL e l'istanza database MySQL.

Avvio della replica tra un'istanza di origine esterna e un cluster di database Aurora MySQL

  1. Rendere di sola lettura l'istanza database MySQL di origine: 

    mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;

  2. Eseguire il comando SHOW MASTER STATUS nell'istanza database MySQL di origine per determinare la posizione di binlog. Viene restituito un output simile all'esempio seguente: 

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

  3. Copia il database dall'istanza database MySQL esterna al cluster di database Amazon Aurora MySQL utilizzando mysqldump. Per database di dimensioni particolarmente elevate, è possibile utilizzare la procedura in Importazione dei dati in un'istanza database MySQL o MariaDB riducendo i tempi di inattività nella Guida per l'utente di Amazon Relational Database Service.

    PerLinux, o: macOS Unix

    mysqldump \
    --databases <database_name> \
    --single-transaction \
    --compress \
    --order-by-primary \
    -u local_user \
    -p local_password | mysql \
        --host aurora_cluster_endpoint_address \
        --port 3306 \
        -u RDS_user_name \
        -p RDS_password

    Per Windows:

    mysqldump ^
    --databases <database_name> ^
    --single-transaction ^
    --compress ^
    --order-by-primary ^
    -u local_user ^
    -p local_password | mysql ^
        --host aurora_cluster_endpoint_address ^
        --port 3306 ^
        -u RDS_user_name ^
        -p RDS_password
    Nota

    Assicurati che non siano presenti spazi tra l'opzione -p e la password immessa.

    Utilizza le opzioni --host, --user (-u), --port e -p nel comando mysql per specificare il nome host, il nome utente e la password per eseguire la connessione al cluster di database Aurora. Il nome host è il nome DNS per l'endpoint del cluster di database Amazon Aurora, ad esempio, mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com. Il valore dell'endpoint è disponibile nei dettagli del cluster nella console di gestione Amazon RDS.

  4. Rendere nuovamente scrivibile l'istanza database MySQL di origine:

    mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;

    Per ulteriori informazioni sulla creazione di backup da utilizzare con la replica, vedere Backing up a source or replica by making it read only nella documentazione di MySQL.

  5. Nella console di gestione Amazon RDS aggiungi l'indirizzo IP del server che ospita il database MySQL di origine al gruppo di sicurezza VPC per il cluster di database Amazon Aurora. Per ulteriori informazioni sulla modifica di un gruppo di sicurezza VPC, consulta Gruppi di sicurezza per il VPC nella Guida per l'utente di Amazon Virtual Private Cloud.

    Potrebbe anche essere necessario configurare la rete locale per consentire le connessioni dall'indirizzo IP del cluster di database Amazon Aurora, affinché possa comunicare con l'istanza di MySQL di origine. Per individuare l'indirizzo IP del cluster di database Amazon Aurora, utilizzare il comando host.

    host aurora_endpoint_address

    Il nome host è il nome DNS dell'endpoint del cluster di database Amazon Aurora.

  6. Utilizzando il client scelto, eseguire la connessione all'istanza di MySQL esterna e creare un utente MySQL da utilizzare per la replica. Questo account viene utilizzato unicamente per la replica e deve essere limitato al dominio personale per aumentare la sicurezza. Di seguito è riportato un esempio.

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';

  7. Per un'istanza di MySQL esterna, concedere i privilegi REPLICATION CLIENT e REPLICATION SLAVE all'utente della replica. Per concedere ad esempio i privilegi REPLICATION CLIENT e REPLICATION SLAVE su tutti i database per l'utente "repl_user" del proprio dominio, eseguire questo comando.

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
    IDENTIFIED BY 'password';

  8. Acquisire uno snapshot manuale del cluster di database Aurora MySQL da impostare come replica di lettura prima di impostare la replica. Se è necessario ridefinire la replica con il cluster di database come replica di lettura, è possibile ripristinare il cluster di database Aurora MySQL da tale snapshot anziché dover importare i dati dall'istanza database MySQL in un nuovo cluster di database Aurora MySQL.

  9. Configurare il cluster di database Amazon Aurora come replica. Esegui la connessione al cluster di database Amazon Aurora come utente master e identifica il database MySQL di origine come master di replica utilizzando le procedure mysql.rds_set_external_master (Aurora MySQL versione 2) o mysql.rds_set_external_source (Aurora MySQL versione 3) e mysql.rds_start_replication.

    Utilizzare il nome e la posizione del file log principale, recuperati nella fase 2. Di seguito è riportato un esempio.

    For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);

For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.mydomain.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);

  10. Nel cluster di database Amazon Aurora chiama la procedura mysql.rds_start_replication per avviare la replica.

    CALL mysql.rds_start_replication;

Dopo aver definito la replica tra l'istanza database MySQL di origine e il cluster di database Amazon Aurora sarà possibile aggiungere le repliche di Aurora al cluster di database Amazon Aurora. È possibile quindi connettere le repliche di Aurora per il dimensionamento della lettura dei dati. Per informazioni sulla creazione di una replica di Aurora, consulta Aggiunta di repliche di Aurora a un cluster di database.

Ottimizzazione della replica dei log binari

Di seguito, è possibile imparare a ottimizzare le prestazioni di replica dei log binari e risolvere i problemi correlati in Aurora MySQL.

Suggerimento

Questa discussione presuppone che tu abbia familiarità con il meccanismo di replica dei log binari MySQL e del suo funzionamento. Per informazioni di base, consulta Implementazione della replica nella documentazione di MySQL.

Replica di log binari multithread

Con la replica del log binario multithread, un thread SQL legge gli eventi dal log di inoltro e li mette in coda per l'applicazione dei thread SQL worker. I thread di lavoro SQL sono gestiti da un thread coordinatore. Gli eventi di log binari vengono applicati in parallelo quando possibile.

La replica di log binari multithread è supportata in Aurora MySQL versione 3 e in Aurora MySQL versione 2.12.1 e successive.

Quando un'istanza DB Aurora MySQL è configurata per utilizzare la replica binaria dei log, per impostazione predefinita l'istanza di replica utilizza la replica a thread singolo per le versioni di Aurora MySQL precedenti alla 3.04. Per abilitare la replica multithread, si aggiorna il parametro replica_parallel_workers a un valore maggiore di zero nel gruppo di parametri personalizzati.

Per Aurora MySQL versione 3.04 e successive, la replica è multithread per impostazione predefinita, con impostazione predefinita su. replica_parallel_workers 4 È possibile modificare questo parametro nel gruppo di parametri personalizzato.

Le opzioni di configurazione seguenti consentono di ottimizzare la replica multithread. Per informazioni sull'utilizzo, consulta Opzioni e variabili di replica e registrazione binaria nel Manuale di riferimento MySQL.

La configurazione ottimale dipende da diversi fattori. Ad esempio, le prestazioni per la replica dei log binari sono influenzate dalle caratteristiche del carico di lavoro del database e dalla classe di istanza database su cui è in esecuzione la replica. Pertanto, si consiglia di testare a fondo tutte le modifiche a questi parametri di configurazione prima di applicare nuove impostazioni dei parametri a un'istanza di produzione:

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking

  • replica_preserve_commit_order

  • replica_parallel_type

  • replica_parallel_workers

In Aurora MySQL versione 3.06 e successive, è possibile migliorare le prestazioni per le repliche di log binari durante la replica di transazioni per tabelle di grandi dimensioni con più di un indice secondario. Questa funzionalità introduce un pool di thread per applicare le modifiche all'indice secondario in parallelo su una replica binlog. La funzionalità è controllata dal parametro del cluster aurora_binlog_replication_sec_index_parallel_workers DB, che controlla il numero totale di thread paralleli disponibili per applicare le modifiche all'indice secondario. Il parametro è impostato su 0 (disabilitato) per impostazione predefinita. L'attivazione di questa funzionalità non richiede il riavvio dell'istanza. Per abilitare questa funzionalità, interrompi la replica in corso, imposta il numero desiderato di thread di lavoro paralleli e quindi riavvia la replica.

È inoltre possibile utilizzare questo parametro come variabile globale, dove n è il numero di thread di lavoro paralleli:

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

Ottimizzazione della replica binlog (Aurora MySQL 2.10 e versioni successive)

In Aurora MySQL 2.10 e versioni successive, Aurora applica automaticamente un'ottimizzazione nota come cache I/O binlog alla replica del log binario. Inserendo nella cache gli eventi binlog più recenti, questa ottimizzazione è progettata per migliorare le prestazioni del thread di dump di binlog limitando al contempo l'impatto sulle transazioni in primo piano sull'istanza di origine binlog.

Nota

Questa memoria utilizzata per questa funzione è indipendente dall'impostazione binlog_cache MySQL.

Questa funzione non si applica alle istanze DB Aurora che utilizzano le classi di istanza db.t2 e db.t3.

Non è necessario regolare alcun parametro di configurazione per attivare questa ottimizzazione. In particolare, se si regola il parametro di configurazioneaurora_binlog_replication_max_yield_seconds su un valore diverso da zero nelle versioni Aurora MySQL precedenti, impostarlo su zero per Aurora MySQL 2.10 e versioni successive.

Le variabili di stato aurora_binlog_io_cache_reads e aurora_binlog_io_cache_read_requests sono disponibili in Aurora MySQL versione 2.10 e successive. Queste variabili di stato aiutano a monitorare la frequenza con cui i dati vengono letti dalla cache I/O binlog.

  • aurora_binlog_io_cache_read_requests: mostra il numero di richieste di lettura I/O binlog dalla cache.

  • aurora_binlog_io_cache_reads: mostra il numero di letture I/O binlog che recuperano informazioni dalla cache.

La seguente query SQL calcola la percentuale di richieste di lettura binlog che sfruttano le informazioni memorizzate nella cache. In questo caso, più il rapporto è vicino a 100, migliore è. 

mysql> SELECT
  (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
  / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
  * 100
  as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
|         99.99847949080622 |
+---------------------------+

La funzione di cache I/O binlog include anche nuovi parametri relativi ai thread di dump di binlog. I thread di dump sono i thread creati quando le nuove repliche di binlog sono collegate all'istanza fonte binlog.

I parametri del thread di dump vengono stampati nel log del database ogni 60 secondi con il prefisso [Dump thread metrics]. I parametri includono informazioni per ogni replica binlog, ad esempio Secondary_id, Secondary_uuid, il nome del file binlog e la posizione in cui ogni replica sta leggendo. I parametri includono anche Bytes_behind_primary che rappresenta la distanza in byte tra l'origine della replica e la replica. Questo parametro misura il ritardo del thread I/O di replica. Tale cifra è diversa dal ritardo del thread dell'applicatore SQL della replica, rappresentato dal parametro seconds_behind_master sulla replica binlog. È possibile determinare se le repliche di binlog stiano recuperando l'origine o rimangano indietro controllando se la distanza diminuisce o aumenta.

Ottimizzazione della replica binlog (Aurora MySQL versione 2 fino alla 2.09)

Per ottimizzare la replica dei log binari per Aurora MySQL, è possibile regolare i seguenti parametri di ottimizzazione a livello di cluster. Questi parametri consentono di specificare il giusto equilibrio tra latenza nell'istanza di origine dei log binari e ritardo di replica.

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

Nota

Per i cluster compatibili con MySQL 5.7, è possibile utilizzare questi parametri in Aurora MySQL versione 2 fino alla 2.09.*. In Aurora MySQL versione 2.10.0 e successive, questi parametri sono sostituiti dall'ottimizzazione della cache I/O binlog e non è necessario utilizzarli.

Panoramica delle ottimizzazioni del buffer di lettura di grandi dimensioni e di max-yield

È possibile che si verifichi una riduzione delle prestazioni di replica dei log binari quando il thread di dump dei log binari accede al volume del cluster Aurora mentre il cluster elabora un numero elevato di transazioni. È possibile utilizzare i parametri aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds e aurora_binlog_read_buffer_size per ridurre al minimo questo tipo di conflitto.

Supponi di avere una situazione in cui aurora_binlog_replication_max_yield_seconds è impostato su maggiore di 0 e il file binlog corrente del thread di dump è attivo. In questo caso, il thread di dump dei log binari attende fino a un numero specificato di secondi affinché il file binlog corrente venga riempito dalle transazioni. Questo periodo di attesa evita conflitti che possono derivare dalla replica di ciascun evento dei log binari singolarmente. Tuttavia, in questo modo aumenta il ritardo di replica per le repliche dei log binari. Tali repliche possono rimanere indietro rispetto all'origine dello stesso numero di secondi dell'impostazione aurora_binlog_replication_max_yield_seconds.

Il file binlog corrente indica il file binlog che il thread di dump sta attualmente leggendo per eseguire la replica. Consideriamo che un file binlog è attivo quando il file binlog è in aggiornamento o aperto per essere aggiornato dalle transazioni in entrata. Dopo che Aurora MySQL ha riempito il file binlog attivo, MySQL crea e passa a un nuovo file binlog. Il vecchio file binlog diventa inattivo. Non viene più aggiornato dalle transazioni in entrata.

Nota

Prima di modificare questi parametri, misurare la latenza e la velocità effettiva delle transazioni nel tempo. È possibile che le prestazioni di replica dei log binari siano stabili e abbiano una bassa latenza anche in caso di conflitti occasionali.

aurora_binlog_use_large_read_buffer

Se questo parametro è impostato su 1, Aurora MySQL ottimizza la replica dei log binari in base alle impostazioni dei parametri aurora_binlog_read_buffer_size e aurora_binlog_replication_max_yield_seconds. Se aurora_binlog_use_large_read_buffer è 0, Aurora MySQL ignora i valori dei parametri aurora_binlog_read_buffer_size e aurora_binlog_replication_max_yield_seconds.

aurora_binlog_read_buffer_size

I thread di dump binari con buffer di lettura più grande riducono al minimo il numero di operazioni di I/O di lettura leggendo più eventi per ogni I/O. Il parametro aurora_binlog_read_buffer_size imposta la dimensione del buffer di lettura. Il buffer di lettura di grandi dimensioni può ridurre i conflitti di log binari per carichi di lavoro che generano una grande quantità di dati binlog.

Nota

Questo parametro ha effetto solo quando anche il cluster ha l'impostazione aurora_binlog_use_large_read_buffer=1.

L'aumento delle dimensioni del buffer di lettura non influisce sulle prestazioni della replica dei log binari. I thread di dump dei log binari non attendono l'aggiornamento delle transazioni per riempire il buffer di lettura.

aurora_binlog_replication_max_yield_seconds

Se il carico di lavoro richiede una bassa latenza delle transazioni ed è possibile tollerare alcuni ritardi di replica, è possibile aumentare il parametro aurora_binlog_replication_max_yield_seconds. Questo parametro controlla la proprietà di rendimento massimo della replica dei log binari nel cluster.

Nota

Questo parametro ha effetto solo quando anche il cluster ha l'impostazione aurora_binlog_use_large_read_buffer=1.

Aurora MySQL riconosce immediatamente qualsiasi modifica al valore del parametro aurora_binlog_replication_max_yield_seconds. Non è necessario riavviare l'istanza database. Tuttavia, quando si attiva questa impostazione, il thread di dump inizia a produrre solo quando il file dei log binari corrente raggiunge la dimensione massima di 128 MB e viene ruotato in un nuovo file.

Parametri correlati

Utilizza i seguenti parametri del cluster di database per attivare l'ottimizzazione binlog.

Parametro Default Valori validi Descrizione
aurora_binlog_use_large_read_buffer 1 0, 1 Interruttore per attivare la funzionalità di miglioramento della replica. Quando il valore è 1, il thread di dump dei log binari utilizza aurora_binlog_read_buffer_size per la replica dei log binari, altrimenti viene utilizzata la dimensione del buffer predefinita (8 K). Non utilizzato in Aurora MySQL versione 3.
aurora_binlog_read_buffer_size 5242880 8192-536870912 Dimensione del buffer di lettura utilizzata dal thread di dump dei log binari quando il parametro aurora_binlog_use_large_read_buffer è impostato su 1. Non utilizzato in Aurora MySQL versione 3.
aurora_binlog_replication_max_yield_seconds 0 0-36000

Per Aurora MySQL version 2.07.*, il valore massimo accettato è 45. È possibile ottimizzarlo con un valore più alto nella versione 2.09 e successive.

Per la versione 2, questo parametro funziona solo quando il parametro aurora_binlog_use_large_read_buffer è impostato su 1.

Attivazione del meccanismo max-yield di replica dei log binari

È possibile attivare l'ottimizzazione max-yield di replica dei log binari come descritto di seguito. In questo modo si riduce al minimo la latenza per le transazioni sull'istanza di origine binlog. Tuttavia, è possibile che si verifichi un ritardo di replica più elevato.

Per attivare l'ottimizzazione max-yield dei log binari per un cluster Aurora MySQL

  1. Creare o modificare un gruppo di parametri del cluster di database utilizzando le seguenti impostazioni dei parametri:

    • aurora_binlog_use_large_read_buffer: si attiva con il valore ON o 1.

    • aurora_binlog_replication_max_yield_seconds: specificare un valore maggiore di 0.

  2. Associare il gruppo di parametri del cluster di database al cluster Aurora MySQL che funge da origine binlog. A tale scopo, seguire la procedura descritta in Utilizzo di gruppi di parametri.

  3. Verificare che la modifica del parametro abbia effetto. A tale scopo, eseguire la seguente query sull'istanza di origine binlog. 

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    L'output visualizzato dovrebbe essere simile al seguente. 

    +---------------------------------------+-----------------------------------------------+
| @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds |
+---------------------------------------+-----------------------------------------------+
|                                     1 |                                            45 |
+---------------------------------------+-----------------------------------------------+

Disattivare l'ottimizzazione max-yield di replica dei log binari

È possibile disattivare l'ottimizzazione max-yield di replica dei log binari come descritto di seguito. In questo modo si riduce al minimo il ritardo di replica. Tuttavia, è possibile che si verifichi una latenza maggiore per le transazioni sull'istanza di origine binlog.

Per disattivare l'ottimizzazione max-yield dei log binari per un cluster Aurora MySQL

  1. Verificare che il gruppo di parametri del cluster di database associato al cluster Aurora MySQL abbia il parametro aurora_binlog_replication_max_yield_seconds impostato su 0 Per ulteriori informazioni sull'impostazione dei parametri di configurazione mediante i gruppi di parametri, consultare Utilizzo di gruppi di parametri.

  2. Verificare che la modifica del parametro abbia effetto. A tale scopo, eseguire la seguente query sull'istanza di origine binlog. 

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    L'output visualizzato dovrebbe essere simile al seguente. 

    +-----------------------------------------------+
| @@aurora_binlog_replication_max_yield_seconds |
+-----------------------------------------------+
|                                             0 |
+-----------------------------------------------+

Disattivazione del buffer di lettura di grandi dimensioni

È possibile disattivare l'intera funzionalità di buffer di lettura di grandi dimensioni come di seguito.

Per disattivare il buffer di lettura dei log binari di grandi dimensioni per un cluster Aurora MySQL

  1. Reimpostare aurora_binlog_use_large_read_buffer su OFF o 0.

    Verificare che il gruppo di parametri del cluster di database associato al cluster Aurora MySQL abbia il parametro aurora_binlog_use_large_read_buffer impostato su 0 Per ulteriori informazioni sull'impostazione dei parametri di configurazione mediante i gruppi di parametri, consultare Utilizzo di gruppi di parametri.

  2. Nell'istanza di origine binlog eseguire la query seguente. 

    SELECT @@ aurora_binlog_use_large_read_buffer;

    L'output visualizzato dovrebbe essere simile al seguente. 

    +---------------------------------------+
| @@aurora_binlog_use_large_read_buffer |
+---------------------------------------+
|                                     0 |
+---------------------------------------+

Configurazione del file di log binario avanzato

Il file di log binario avanzato riduce il sovraccarico delle prestazioni di elaborazione causato dall'attivazione del file di log binario, che in alcuni casi può arrivare fino al 50%. Con il file di log binario avanzato, questo sovraccarico può essere ridotto a circa il 13%. Per ridurre il sovraccarico, il file di log binario avanzato scrive i log binari e i log delle transazioni nello spazio di archiviazione in parallelo, il che riduce al minimo i dati scritti al momento del commit della transazione.

L'utilizzo del file di log binario avanzato migliora anche i tempi di ripristino del database dopo riavvii e failover fino al 99% rispetto al file di log binario della community MySQL. Il file di log binario avanzato è compatibile con i carichi di lavoro esistenti basati sul file di log binario e viene utilizzato nello stesso modo in cui si utilizza il file di log binario della community MySQL.

Enhanced binlog è disponibile su Aurora MySQL versione 3.03.1 e successive.

Configurazione dei parametri del file di log binario avanzato

È possibile passare dal file di log binario della community MySQL al file di log binario avanzato attivando/disattivando i relativi parametri. Gli utenti esistenti di file di log binario possono continuare a leggere e consumare i file di log binario senza interruzioni nella sequenza di file di log binario.

Per attivare il file di log binario avanzato
Parametro Predefinito Descrizione
binlog_format – Impostare il parametro binlog_format sul formato di registrazione binaria desiderato per attivare il file di log binario avanzato. Assicurarsi che binlog_format parameter non sia impostato su OFF. Per ulteriori informazioni, consultare Configurazione del log binario di Aurora MySQL.
aurora_enhanced_binlog 0 Impostare il valore di questo parametro su 1 nel gruppo di parametri del cluster database associato al cluster Aurora MySQL. Quando si modifica il valore di questo parametro, è necessario riavviare l'istanza di scrittura quando il valore di DBClusterParameterGroupStatus viene visualizzato come pending-reboot.
binlog_backup 1 Disattivare questo parametro per attivare il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 0.
binlog_replication_globaldb 1 Disattivare questo parametro per attivare il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 0.
Importante

È possibile disattivare i parametri binlog_backup e binlog_replication_globaldb  solo in caso di utilizzo del file di log binario avanzato.

Per disattivare il file di log binario avanzato
Parametro Descrizione
aurora_enhanced_binlog Impostare il valore di questo parametro su 0 nel gruppo di parametri del cluster database associato al cluster Aurora MySQL. Ogni volta che si modifica il valore di questo parametro, è necessario riavviare l'istanza di scrittura quando il valore di DBClusterParameterGroupStatus viene visualizzato come pending-reboot.
binlog_backup Attivare questo parametro quando si disattiva il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 1.
binlog_replication_globaldb Attivare questo parametro quando si disattiva il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 1.

Per verificare se il file di log binario avanzato è attivo, usare il seguente comando nel client MySQL:

mysql>show status like 'aurora_enhanced_binlog';
              
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)

Quando il file di log binario avanzato è attivo, l'output mostra ACTIVE per aurora_enhanced_binlog.

Altri parametri correlati

Quando si attiva il file di log binario avanzato, questa operazione interessa i seguenti parametri:

  • Il parametro max_binlog_size è visibile ma non modificabile. Il relativo valore predefinito 134217728 viene impostato automaticamente su 268435456 quando il file di log binario avanzato è attivato.

  • A differenza file di log binario avanzato della community MySQL, binlog_checksum non agisce come parametro dinamico quando il file di log binario avanzato è attivato. Affinché la modifica a questo parametro abbia effetto, è necessario riavviare manualmente il cluster database anche quando ApplyMethod è immediate.

  • Il valore impostato per il parametro binlog_order_commits non ha alcun effetto sull'ordine dei commit quando il file di log binario avanzato è attivato. I commit vengono sempre ordinati senza ulteriori implicazioni in termini di prestazioni.

Differenze tra file di log binario avanzato e file di log binario avanzato della community MySQL

Il binlog avanzato interagisce in modo diverso con i cloni, i backup e il database globale Aurora rispetto al binlog MySQL della community. Si consiglia di analizzare le seguenti differenze prima di utilizzare il file di log binario avanzato.

  • I file binlog avanzati del cluster DB di origine non sono disponibili su un cluster DB clonato.

  • I file binlog avanzati non sono inclusi nei backup di Aurora. Pertanto, i file di log binario avanzati del cluster database di origine non sono disponibili dopo il ripristino di un cluster database nonostante il relativo periodo di conservazione impostato.

  • Se utilizzati con un database globale Aurora, i file di log binario avanzati del cluster database primario non vengono replicati nel cluster database nelle regioni secondarie.

Examples (Esempi)

Negli esempi seguenti vengono illustrate le differenze tra file di log binario avanzati e file di log binario della community MySQL.

Su un cluster database ripristinato o clonato

Quando il file di log binario avanzato è attivato, i file di log binario storici non sono disponibili nel cluster database ripristinato o clonato. Dopo un'operazione di ripristino o clonazione, se binlog è attivato, il nuovo cluster DB inizia a scrivere la propria sequenza di file binlog, a partire da 1 (.000001). mysql-bin-changelog

Per attivare il file di log binario avanzato dopo un'operazione di ripristino o clonazione, impostare i parametri del cluster database richiesti sul cluster database ripristinato o clonato. Per ulteriori informazioni, consulta Configurazione dei parametri del file di log binario avanzato.

Esempio Operazione di clonazione o ripristino eseguita quando il file di log binario avanzato è attivato

Cluster database di origine:

mysql> show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

In un cluster database ripristinato o clonato, non viene eseguito il backup dei file di log binario quando è attivato il file di log binario avanzato. Per evitare discontinuità nei dati del file di log binario, non sono disponibili nemmeno i file di log binario scritti prima di attivare il file di log binario avanzato. 

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> New sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
Esempio Operazione di clonazione o ripristino eseguita quando il binlog avanzato è disattivato

Cluster DB di origine:

mysql>show binary logs;
                                                
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

In un cluster database ripristinato o clonato, sono disponibili file di log binario scritti dopo aver disattivato il file di log binario avanzato.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)

Su un database globale Amazon Aurora

Su un database globale Amazon Aurora, i dati del file di log binario del cluster database primario non vengono replicati nei cluster database secondari. Dopo un processo di failover tra regioni, i dati del file di log binario non sono disponibili nel cluster database primario appena promosso. Se binlog è attivato, il cluster DB appena promosso avvia la propria sequenza di file binlog, a partire da 1 (mysql-bin-changelog.000001).

Per attivare il file di log binario avanzato dopo il failover, è necessario impostare i parametri del cluster database richiesti sul cluster database secondario. Per ulteriori informazioni, consulta Configurazione dei parametri del file di log binario avanzato.

Esempio L'operazione di failover del database globale viene eseguita quando il file di log binario avanzato è attivato

Vecchio cluster database primario (prima del failover):

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

Nuovo cluster database primario (dopo il failover):

I file di log binario non vengono replicati nelle regioni secondarie quando il file di log binario avanzato è attivato. Per evitare discontinuità nei dati del file di log binario, i file di log binario scritti prima di attivare il file di log binario avanzato non sono disponibili.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
Esempio L'operazione di failover del database globale viene eseguita quando il file di log binario avanzato è disattivato

Cluster database di origine:

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)

Cluster database ripristinato o clonato:

I file di log binario scritti dopo aver disattivato il file di log binario avanzato vengono replicati e sono disponibili nel cluster database appena promosso.

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)

CloudWatch Metriche di Amazon per binlog migliorato

Le seguenti CloudWatch metriche di Amazon vengono pubblicate solo quando è attivato il binlog avanzato.

CloudWatch metrica Descrizione unità
ChangeLogBytesUsed Quantità di spazio di archiviazione in byte utilizzato dal file di log binario avanzato. Byte
ChangeLogReadIOPS Numero di operazioni I/O di lettura eseguite nel file di log binario avanzato in intervalli di 5 minuti. Conteggio per 5 minuti
ChangeLogWriteIOPS Numero di operazioni I/O di scrittura su disco eseguite nel file di log binario avanzato in intervalli di 5 minuti. Conteggio per 5 minuti

Limitazioni del file di log binario avanzato

Le seguenti limitazioni si applicano ai cluster database Amazon Aurora quando il file di log binario avanzato è attivato.

  • Enhanced binlog è supportato solo su Aurora MySQL versione 3.03.1 e successive.

  • I file di log binario avanzati scritti sul cluster database primario non vengono copiati nei cluster database clonati o ripristinati.

  • Se utilizzati con un database globale Amazon Aurora, i file di log binario avanzati del cluster database primario non vengono replicati nei cluster database secondari. Pertanto, dopo il processo di failover, i dati dei file di log binario storici non sono disponibili nel nuovo cluster database primario.

  • I seguenti parametri di configurazione del file di log binario vengono ignorati:

    • binlog_group_commit_sync_delay

    • binlog_group_commit_sync_no_delay_count

    • binlog_max_flush_queue_time

  • Non è possibile eliminare o rinominare una tabella danneggiata in un database. Per eliminare queste tabelle, puoi contattare. AWS Support

  • La cache I/O del file di log binario è disabilitata quando il file di log binario avanzato è attivato. Per ulteriori informazioni, consulta Ottimizzazione della replica dei log binari.

    Nota

    Il file di log binario avanzato è caratterizzato da miglioramenti delle prestazioni di lettura simili a quelli della cache I/O del file di log binario e da ulteriori ottimizzazioni delle prestazioni di scrittura.

  • La funzionalità Backtrack non è supportata. Il file di log binario avanzato non può essere attivato in un cluster database nelle seguenti condizioni:

    • Cluster database con la funzionalità Backtrack abilitata.

    • Cluster DB in cui la funzionalità backtrack era precedentemente abilitata, ma ora è disabilitata.

    • Cluster database ripristinato da un cluster database di origine o da uno snapshot con la funzionalità Backtrack abilitata.