Livelli di isolamento nella replica

Questa pagina descrive come abilitare l'isolamento delle transazioni negli snapshot di database Microsoft SQL Server e MySQL nei job di replica di Cloud Data Fusion.

Quando configuri un job di replica per un database, il job esegue uno snapshot iniziale delle tabelle di origine. Per garantire la coerenza dei dati, inserisci blocchi su queste tabelle.

Dopo lo snapshot iniziale, le modifiche incrementali nell'origine vengono acquisite e applicate alla destinazione BigQuery nell'ambito del processo di replica in corso.

SQL Server

Per acquisire le modifiche nelle tabelle di origine in un database SQL Server, il job di replica utilizza un connettore Debezium. Durante la snapshotting fase, Debezium acquisisce i blocchi in base a snapshot.isolation.mode configurato.

La tabella seguente confronta le modalità di isolamento supportate per i job di replica.

Modalità di isolamento Blocchi acquisiti Coerenza dei dati
read_uncommitted Nessuno No.
read_committed Blocchi condivisi su un batch di righe alla volta Parziale. Un record aggiunto può essere visualizzato due volte: una volta nello snapshot iniziale e una volta nella fase di streaming.
repeatable_read
(valore predefinito)		 Blocchi condivisi su tutte le righe Parziale. Un record aggiunto può essere visualizzato due volte: una volta nello snapshot iniziale e una volta nella fase di streaming.
snapshot Nessuno Completa.
exclusive Blocco esclusivo su tutte le tabelle Completa.

Per saperne di più sulle modalità di isolamento, consulta Impostare il livello di isolamento delle transazioni.

Per impostazione predefinita, la modalità di isolamento degli snapshot è repeatable_read. Questa modalità acquisisce blocchi condivisi su tutti i dati letti durante la fase di snapshotting. Impedisce ad altre transazioni di modificare le righe esistenti e può potenzialmente consentire l'inserimento di nuovi record (vedi escalation dei blocchi).

La replica con isolamento degli snapshot è consigliata se è già abilitata nel database di origine perché fornisce una coerenza completa dei dati senza bloccare le tabelle. Se non è abilitata, scopri di più sull'impatto dei livelli di isolamento basati sul controllo delle versioni delle righe nel motore di database SQL Server prima di abilitarla.

In alternativa, utilizza la modalità di isolamento read_committed, che non blocca le tabelle durante la fase di snapshotting.

Abilitare l'isolamento degli snapshot in un job di replica

  1. Abilita l'isolamento degli snapshot nel database SQL Server:

    ALTER DATABASE DATABASE_NAME
SET ALLOW_SNAPSHOT_ISOLATION ON

    Sostituisci DATABASE_NAME con il nome del database SQL Server.

  2. Imposta l'argomento di runtime snapshot.isolation.mode su snapshot. Per saperne di più, consulta Trasmettere un argomento di runtime a un job di replica.

MySQL

Per acquisire le modifiche nelle tabelle di origine in un database MySQL, il job di replica utilizza un connettore Debezium. Durante la snapshotting fase, Debezium acquisisce i blocchi in base a snapshot.locking.mode configurato.

Per impostazione predefinita, la modalità di blocco degli snapshot è minimal. In questa modalità, il connettore mantiene il blocco di lettura globale per la parte iniziale dello snapshot mentre legge gli schemi di database e altri metadati. Il connettore recupera quindi tutte le righe tramite una lettura coerente, utilizzando la transazione REPEATABLE READ, che non blocca le tabelle.

Per impedire qualsiasi blocco, imposta la modalità su none.

In alternativa, per impedire i blocchi sui database MySQL in esecuzione su Cloud SQL, esegui la replica dalla replica anziché dal database transazionale.

Modificare il comportamento di blocco durante lo snapshot per MySQL

  • Per modificare il comportamento di blocco degli snapshot nel database MySQL, imposta l'argomento di runtime, la proprietà snapshot.locking.mode, su un valore di modalità di blocco appropriato.

Per saperne di più, consulta Trasmettere un argomento Debezium a un job di replica.

Limitazioni

  • La replica in Cloud Data Fusion supporta la versione 1.3 del connettore Debezium.

Origini Oracle in Cloud Data Fusion

La replica da origini Oracle in Cloud Data Fusion è basata su Datastream. Datastream non blocca le tabelle.

Passaggi successivi