Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite wird beschrieben, wie Sie die Transaktionsisolation in Microsoft SQL Server- und MySQL-Datenbank-Snapshots in Cloud Data Fusion-Replikationsjobs aktivieren.
Wenn Sie einen Replikationsjob für eine Datenbank einrichten, wird beim Job ein erster Snapshot der Quelltabellen erstellt. Um die Datenkonsistenz zu gewährleisten, legen Sie Sperren für diese Tabellen fest.
Nach dem ersten Snapshot werden inkrementelle Änderungen an der Quelle erfasst und im Rahmen des laufenden Replikationsprozesses auf das BigQuery-Ziel angewendet.
SQL Server
Um Änderungen an den Quelltabellen in einer SQL Server-Datenbank zu erfassen, verwendet der Replikationsjob einen Debezium-Connector. Während der Phase snapshotting erlangt Debezium Sperren gemäß der konfigurierten snapshot.isolation.mode.
In der folgenden Tabelle werden die unterstützten Isolationsmodi für Replikationsjobs verglichen.
Isolierungsmodus
Gekaufte Schlösser
Datenkonsistenz
read_uncommitted
Keine
Nein.
read_committed
Freigegebene Sperren für mehrere Zeilen gleichzeitig
Teilweise. Ein hinzugefügter Datensatz kann zweimal erscheinen: einmal im ersten Snapshot und einmal in der Streamingphase.
repeatable_read (Standard)
Freigegebene Sperren für alle Zeilen
Teilweise. Ein hinzugefügter Datensatz kann zweimal erscheinen: einmal im ersten Snapshot und einmal in der Streamingphase.
Der Standard-Snapshot-Isolationsmodus ist repeatable_read. In diesem Modus werden freigegebene Sperren für alle Daten erstellt, die während der Snapshot-Phase gelesen werden. Sie verhindert, dass andere Transaktionen die vorhandenen Zeilen ändern, und kann das Einfügen neuer Datensätze ermöglichen (siehe Sperreskaskade).
Die Replikation mit Snapshot-Isolation wird empfohlen, wenn sie bereits in der Quelldatenbank aktiviert ist, da sie für vollständige Datenkonsistenz ohne Sperren der Tabellen sorgt. Wenn die Funktion nicht aktiviert ist, informieren Sie sich über die Auswirkungen der Isolationsebenen auf Grundlage der Zeilenversionierung in der SQL Server-Datenbankmodul, bevor Sie sie aktivieren.
Alternativ können Sie den Isolationsmodus read_committed verwenden, bei dem die Tabellen während der Snapshot-Phase nicht gesperrt werden.
Snapshot-Isolation in einem Replikationsjob aktivieren
Aktivieren Sie die Snapshot-Isolation in der SQL Server-Datenbank:
ALTER DATABASE DATABASE_NAME
SET ALLOW_SNAPSHOT_ISOLATION ON
Ersetzen Sie DATABASE_NAME durch den Namen der SQL Server-Datenbank.
Um Änderungen an den Quelltabellen in einer MySQL-Datenbank zu erfassen, verwendet der Replikationsjob einen Debezium-Connector. Während der Phase snapshotting erlangt Debezium Sperren gemäß der konfigurierten snapshot.locking.mode.
Standardmäßig ist der Snapshot-Sperrungsmodus minimal. In diesem Modus hält der Connector die globale Lesesperre für den ersten Teil des Snapshots, während er die Datenbankschemata und andere Metadaten liest. Anschließend ruft der Connector alle Zeilen über eine konsistente Lesevorgang mit der REPEATABLE READ-Transaktion ab, die die Tabellen nicht sperrt.
Legen Sie den Modus auf none fest, um Sperrungen zu vermeiden.
Alternativ können Sie, um Sperren bei MySQL-Datenbanken zu vermeiden, die in Cloud SQL ausgeführt werden, von dem Replikat statt von der Transaktionsdatenbank replizieren.
Sperrverhalten während des Snapshots für MySQL ändern
Wenn Sie das Verhalten der Snapshot-Sperrung in der MySQL-Datenbank ändern möchten, legen Sie für das Laufzeitargument snapshot.locking.mode einen geeigneten Wert für den Sperrungsmodus fest.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]
