Cette page explique comment activer l'isolation de transaction dans Microsoft SQL Server et les instantanés de base de données MySQL dans des tâches de réplication Cloud Data Fusion.
Lorsque vous configurez un job de réplication pour une base de données, la tâche 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 à 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 dans une base de données SQL Server, le job de réplication utilise un connecteur Debezium. Pendant la phase snapshotting, Debezium acquiert des serrures en fonction de la configuration snapshot.isolation.mode.
Le tableau suivant compare les modes d'isolation compatibles avec les tâches de réplication.
| Mode d'isolation | Serrures acquises | Cohérence des données |
|---|---|---|
read_uncommitted |
Aucun | Non. |
read_committed |
Verrous partagés sur un lot de lignes à la fois | Partiel. Un enregistrement ajouté peut apparaître deux fois: une fois dans l'instantané initial et une fois lors de la phase de streaming. |
repeatable_read(par défaut) |
Verrous partagés sur toutes les lignes | Partiel. Un enregistrement ajouté peut apparaître deux fois: une fois dans l'instantané initial et une fois lors de la phase de streaming. |
snapshot |
Aucun | Complet. |
exclusive |
Verrouillage exclusif sur toutes les tables | Complet. |
Pour en savoir plus sur les modes d'isolation, consultez la section Définir le niveau d'isolation des transactions.
Par défaut, le mode d'isolation d'instantané est repeatable_read. Ce mode accepte des verrouillages partagés sur toutes les données lues pendant la phase de création d'instantanés. Cela empêche les autres transactions de modifier les lignes existantes et peut potentiellement autoriser l'insertion de nouveaux enregistrements (consultez la section Escalade des verrouillages).
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 fournit une cohérence totale des données sans verrouiller les tables. Si elle n'est pas activée, renseignez-vous sur l'impact des niveaux d'isolation basés sur la gestion des versions des lignes 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 de création d'instantanés.
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 la section Transmettre un argument d'exécution à une tâche de réplication.
MySQL
Pour capturer les modifications apportées aux tables sources dans une base de données MySQL, le job de réplication utilise un connecteur Debezium. Pendant la phase snapshotting, Debezium acquiert des serrures en fonction de la configuration snapshot.locking.mode.
Par défaut, le mode de verrouillage d'instantané est minimal. Dans ce mode, le connecteur conserve le verrou global en lecture pour la partie initiale de l'instantané pendant qu'il lit les schémas de base de données et d'autres métadonnées. Ensuite, le connecteur extrait toutes les lignes via une lecture cohérente, à l'aide de la transaction REPEATABLE READ, qui ne verrouille pas les tables.
Pour empêcher tout verrouillage, définissez le mode sur none.
Une autre solution consiste à répliquer à partir de l'instance répliquée plutôt que la base de données transactionnelle pour éviter les verrouillages sur les bases de données MySQL exécutées sur Cloud SQL.
Modifier le comportement de verrouillage pendant l'instantané pour MySQL
- Pour modifier le comportement de verrouillage d'instantanés dans la base de données MySQL, définissez l'argument d'exécution, propriété
snapshot.locking.mode, sur une valeur de mode de verrouillage appropriée.
Pour en savoir plus, consultez la section 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 basée sur Datastream. Datastream ne verrouille pas les tables.
Étapes suivantes
- Apprenez-en plus sur la réplication.