Cette page explique comment activer l'isolation des transactions dans les instantanés de base de données Microsoft SQL Server et MySQL dans les jobs de réplication Cloud Data Fusion.
Lorsque vous configurez une tâche de réplication pour une base de données, elle prend un instantané initial des tables sources. Pour assurer la cohérence des données, placez des verrous sur ces tables.
Après l'instantané initial, les modifications incrémentielles apportées à la source sont capturées et appliquées à la cible BigQuery dans le cadre du processus de réplication en cours.
SQL Server
Pour capturer les modifications apportées aux tables sources d'une base de données SQL Server, le job de réplication utilise un connecteur Debezium. Pendant la phase snapshotting, Debezium acquiert des verrous en fonction de la snapshot.isolation.mode configurée.
Le tableau suivant compare les modes d'isolation compatibles pour les jobs de réplication.
| Mode d'isolation | Serrures acquises | Cohérence des données |
|---|---|---|
read_uncommitted |
Aucun | Non. |
read_committed |
Verrouillages partagés sur un lot de lignes à la fois | Partielle. Un enregistrement ajouté peut apparaître deux fois : une fois dans l'instantané initial et une fois dans la phase de streaming. |
repeatable_read(par défaut) |
Verrous partagés sur toutes les lignes | Partielle. Un enregistrement ajouté peut apparaître deux fois : une fois dans l'instantané initial et une fois dans la phase de streaming. |
snapshot |
Aucun | Complète. |
exclusive |
Verrou exclusif sur toutes les tables | Complète. |
Pour en savoir plus sur les modes d'isolation, consultez Définir le niveau d'isolation des transactions.
Par défaut, le mode d'isolation d'instantané est repeatable_read. Ce mode prend des verrous partagés sur toutes les données lues pendant la phase d'instantané. Il empêche les autres transactions de modifier les lignes existantes et peut potentiellement autoriser l'insertion de nouveaux enregistrements (voir Escalade de verrouillage).
La réplication avec isolation d'instantané est recommandée si elle est déjà activée sur la base de données source, car elle assure une cohérence totale des données sans verrouiller les tables. Si ce n'est pas le cas, renseignez-vous sur l'impact des niveaux d'isolation basés sur le contrôle de version de ligne dans le moteur de base de données SQL Server avant de l'activer.
Vous pouvez également utiliser le mode d'isolation read_committed, qui ne verrouille pas les tables pendant la phase d'instantané.
Activer l'isolation d'instantané dans un job de réplication
Activez l'isolation d'instantané dans la base de données SQL Server :
ALTER DATABASE DATABASE_NAME SET ALLOW_SNAPSHOT_ISOLATION ON
Remplacez
DATABASE_NAMEpar le nom de la base de données SQL Server.Définissez l'argument d'exécution
snapshot.isolation.modesursnapshot. Pour en savoir plus, consultez Transmettre un argument d'exécution à une tâche de réplication.
MySQL
Pour capturer les modifications apportées aux tables sources d'une base de données MySQL, le job de réplication utilise un connecteur Debezium. Pendant la phase snapshotting, Debezium acquiert des verrous en fonction de la snapshot.locking.mode configurée.
Par défaut, le mode de verrouillage des instantanés est défini sur minimal. Dans ce mode, le connecteur détient le verrou de lecture global pour la partie initiale de l'instantané lorsqu'il lit les schémas de base de données et d'autres métadonnées. Le connecteur récupère ensuite toutes les lignes via une lecture cohérente, à l'aide de la transaction REPEATABLE READ, qui ne verrouille pas les tables.
Pour éviter tout verrouillage, définissez le mode sur none.
Pour éviter les verrouillages sur les bases de données MySQL exécutées sur Cloud SQL, vous pouvez également effectuer la réplication à partir de la réplique au lieu de la base de données transactionnelle.
Modifier le comportement de verrouillage pendant l'instantané pour MySQL
- Pour modifier le comportement de verrouillage des instantanés dans la base de données MySQL, définissez la propriété
snapshot.locking.modede l'argument d'exécution sur une valeur de mode de verrouillage appropriée.
Pour en savoir plus, consultez Transmettre un argument Debezium à une tâche de réplication.
Limites
- La réplication dans Cloud Data Fusion est compatible avec le connecteur Debezium version 1.3.
Sources Oracle dans Cloud Data Fusion
La réplication à partir de sources Oracle dans Cloud Data Fusion est optimisée par Datastream. Datastream ne verrouille pas les tables.
Étapes suivantes
- En savoir plus sur la réplication