Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describe cómo habilitar el aislamiento de transacciones en las instantáneas de bases de datos de Microsoft SQL Server y MySQL en los trabajos de replicación de Cloud Data Fusion.
Cuando configuras un trabajo de replicación para una base de datos, este toma una
instantánea inicial de las tablas de origen. Para garantizar la coherencia de los datos, coloca bloqueos en esas tablas.
Después de la instantánea inicial, se capturan los cambios incrementales en la fuente y se aplican al destino de BigQuery como parte del proceso de replicación en curso.
SQL Server
Para capturar los cambios en las tablas de origen de una base de datos de SQL Server, el trabajo de replicación usa un conector de Debezium. Durante la fase snapshotting, Debezium adquiere bloqueos según el snapshot.isolation.mode configurado.
En la siguiente tabla, se comparan los modos de aislamiento admitidos para las tareas de replicación.
Modo de aislamiento
Cerraduras adquiridas
Coherencia de los datos
read_uncommitted
Ninguno
No.
read_committed
Bloqueos compartidos en un lote de filas a la vez
Parcial. Un registro agregado puede aparecer dos veces: una vez en la instantánea inicial y una vez en la fase de transmisión.
repeatable_read (predeterminada)
Bloqueos compartidos en todas las filas
Parcial. Un registro agregado puede aparecer dos veces: una vez en la instantánea inicial y una vez en la fase de transmisión.
De forma predeterminada, el modo de aislamiento de instantáneas es repeatable_read. Este modo toma bloqueos compartidos en todos los datos que se leen durante la fase de creación de instantáneas. Evita que otras transacciones modifiquen las filas existentes y, en teoría, puede permitir la inserción de registros nuevos (consulta derivación de bloqueos).
Para capturar los cambios en las tablas de origen de una base de datos de MySQL, el trabajo de replicación usa un conector de Debezium. Durante la fase snapshotting, Debezium adquiere bloqueos según el snapshot.locking.mode configurado.
De forma predeterminada, el modo de bloqueo de instantáneas es minimal. En este modo, el conector mantiene el bloqueo de lectura global para la parte inicial de la instantánea mientras lee los esquemas de la base de datos y otros metadatos. Luego, el conector recupera todas las filas a través de una lectura coherente, con la transacción REPEATABLE READ, que no bloquea las tablas.
Para evitar bloqueos, establece el modo en none.
Como alternativa, para evitar bloqueos en las bases de datos de MySQL que se ejecutan en
Cloud SQL, replica desde la
réplica
en lugar de la base de datos transaccional.
Cambia el comportamiento de bloqueo durante la instantánea de MySQL
Para cambiar el comportamiento de bloqueo de instantáneas en la base de datos de MySQL, establece el argumento de tiempo de ejecución, la propiedad snapshot.locking.mode, en un valor apropiado de modo de bloqueo.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[[["\u003cp\u003eThis document details how to manage transaction isolation and locking during the snapshotting phase of replication jobs in Microsoft SQL Server and MySQL databases within Cloud Data Fusion.\u003c/p\u003e\n"],["\u003cp\u003eFor SQL Server, setting the \u003ccode\u003esnapshot.isolation.mode\u003c/code\u003e to \u003ccode\u003esnapshot\u003c/code\u003e provides full data consistency without locking tables, though it requires enabling snapshot isolation in the SQL Server database.\u003c/p\u003e\n"],["\u003cp\u003eSQL Server's default isolation mode \u003ccode\u003erepeatable_read\u003c/code\u003e uses shared locks, potentially allowing duplicate records; alternatively \u003ccode\u003eread_committed\u003c/code\u003e can be used but requires caution against schema changes.\u003c/p\u003e\n"],["\u003cp\u003eIn MySQL, the \u003ccode\u003esnapshot.locking.mode\u003c/code\u003e can be set to \u003ccode\u003enone\u003c/code\u003e to prevent locks, but schema changes during snapshotting should be avoided to ensure consistency, alternatively, you can replicate from the replica instead of the transactional database.\u003c/p\u003e\n"],["\u003cp\u003eOracle source replication via Datastream does not lock tables, ensuring minimal disruption.\u003c/p\u003e\n"]]],[],null,["# Isolation levels in replication\n\nThis page describes how to enable *transaction isolation* in Microsoft SQL\nServer and MySQL database snapshots in Cloud Data Fusion\nreplication jobs.\n\nWhen you set up a replication job for a database, the job takes an\ninitial snapshot of the source tables. To ensure data consistency, place\nlocks on those tables.\n\nAfter the initial snapshot, incremental changes at the source are captured and\napplied to the BigQuery target as part of the ongoing replication\nprocess. \n\n### SQL Server\n\nTo capture changes in the source tables in a SQL Server database, the\nreplication job uses a Debezium connector. During the\n[`snapshotting`](/data-fusion/docs/concepts/replication#table_states) phase,\nDebezium acquires locks according to the configured\n[`snapshot.isolation.mode`](https://debezium.io/documentation/reference/1.3/connectors/sqlserver.html#sqlserver-property-snapshot-isolation-mode).\n\nThe following table compares the supported isolation modes for\nreplication jobs.\n\nFor more information about isolation modes, see\n[Set transaction isolation level](https://learn.microsoft.com/en-us/sql/t-sql/statements/set-transaction-isolation-level-transact-sql).\n\nBy default, the snapshot isolation mode is `repeatable_read`. This mode takes\nshared locks on all data that's read during the snapshotting phase. It\nprevents other transactions from modifying the existing rows, and can\npotentially allow insertion of new records (see\n[lock escalation](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver16#lock-escalation)).\n\nReplication with snapshot isolation is recommended if it's already enabled on\nthe source database because it provides full data consistency without locking\nthe tables. If it's not enabled, learn more about the impact of\n[row versioning-based isolation levels in the SQL Server Database Engine](https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?#Row_versioning)\nbefore you enable it.\n\nAs an alternative, use the `read_committed` isolation mode, which\ndoesn't lock the tables during the snapshotting phase.\n| **Warning:** If you use `read_committed` mode, ensure that no schema changes are applied on the database during the snapshotting phase, as it may cause data inconsistency in replication.\n\nEnable snapshot isolation in a replication job\n----------------------------------------------\n\n1. Enable snapshot isolation in the SQL Server database:\n\n ```\n ALTER DATABASE DATABASE_NAME\n SET ALLOW_SNAPSHOT_ISOLATION ON\n ```\n\n Replace \u003cvar translate=\"no\"\u003eDATABASE_NAME\u003c/var\u003e with the name of the SQL Server\n database.\n2. Set the runtime argument `snapshot.isolation.mode` to `snapshot`. For more\n information, see\n [Pass a runtime argument to a replication job](/data-fusion/docs/how-to/pass-runtime-args-in-replication).\n\n### MySQL\n\nTo capture changes in the source tables in a MySQL database, the\nreplication job uses a Debezium connector. During the\n[`snapshotting`](/data-fusion/docs/concepts/replication#table_states) phase,\nDebezium acquires locks according to the configured\n[`snapshot.locking.mode`](https://debezium.io/documentation/reference/1.3/connectors/mysql.html#mysql-property-snapshot-locking-mode).\n\nBy default, the snapshot locking mode is `minimal`. In this mode, the\nconnector holds the global read lock for the initial portion of the snapshot\nas it reads the database schemas and other metadata. Then the connector\nfetches all rows through a consistent read, using the `REPEATABLE READ`\ntransaction, which doesn't lock the tables.\n\nTo prevent any locks, set the mode to `none`.\n| **Warning:** If you use `none`, ensure that no schema changes are applied on the database during the snapshotting phase, as it may cause data inconsistency in replication.\n\nAs an alternative, to prevent locks on MySQL databases running on\nCloud SQL, replicate from the\n[Replica](https://debezium.io/documentation/reference/1.3/connectors/mysql.html#mysql-supported-topologies_debezium)\ninstead of the transactional database.\n\nChange the locking behavior during the snapshot for MySQL\n---------------------------------------------------------\n\n- To change snapshot locking behavior in the MySQL database, set the runtime argument, `snapshot.locking.mode` property, to an appropriate [locking mode](https://debezium.io/documentation/reference/1.3/connectors/mysql.html#mysql-property-snapshot-locking-mode) value.\n\n| **Note:** Tables defined with the MyISAM engine continue to be locked despite the property being set to `none`.\n\nFor more information, see [Pass a Debezium argument to a replication job](/data-fusion/docs/how-to/pass-runtime-args-in-replication#debezium-arguments).\n\nLimitations\n-----------\n\n- Replication in Cloud Data Fusion supports Debezium Connector version 1.3.\n\nOracle sources in Cloud Data Fusion\n-----------------------------------\n\nReplication from Oracle sources in Cloud Data Fusion is powered by\nDatastream. Datastream [doesn't lock tables](/datastream/docs/faq#general-source).\n\nWhat's next\n-----------\n\n- Learn more about [Replication](/data-fusion/docs/concepts/replication)."]]
