复制中的隔离级别

本页面介绍如何在 Cloud Data Fusion 复制作业中为 Microsoft SQL Server 和 MySQL 数据库快照启用事务隔离。

为数据库设置复制作业时，该作业会获取源表的初始快照。为确保数据一致性，请锁定这些表。

在初始快照之后，系统会捕获源中的增量更改，并将其应用于 BigQuery 目标，作为正在进行的复制过程的一部分。

SQL Server

如需捕获 SQL Server 数据库中源表的变化，复制作业会使用 Debezium 连接器。在 snapshotting阶段， Debezium 会根据配置的 snapshot.isolation.mode获取锁。

下表比较了复制作业支持的隔离模式。

隔离模式	获取的锁	数据一致性
read_uncommitted	无	不需要
read_committed	一次对一批行使用共享锁	部分。添加的记录可能会出现两次：一次在初始 快照中，一次在流式传输阶段。
repeatable_read （默认）	对所有行使用共享锁	部分。添加的记录可能会出现两次：一次在初始 快照中，一次在流式传输阶段。
snapshot	无	完整。
exclusive	对所有表使用独占锁	完整。

如需详细了解隔离模式，请参阅 设置事务隔离级别。

默认情况下，快照隔离模式为 repeatable_read。在此模式下，系统会对快照阶段读取的所有数据使用共享锁。它可以防止其他事务修改现有行，并且可能会允许插入新记录（请参阅锁升级）。

如果源数据库已启用快照隔离，建议使用快照隔离进行复制，因为它可以在不锁定表的情况下提供完整的数据一致性。如果未启用，请先详细了解基于 行版本控制的隔离级别在 SQL Server 数据库引擎 中的影响，然后再启用。

或者，您也可以使用 read_committed 隔离模式，该模式在快照阶段不会锁定表。

**警告**： 如果您使用 read_committed 模式，请确保在快照阶段不会对数据库应用任何架构更改，因为这可能会导致复制中的数据不一致。

在复制作业中启用快照隔离

1. 在 SQL Server 数据库中启用快照隔离：

   ALTER DATABASE DATABASE_NAME
   SET ALLOW_SNAPSHOT_ISOLATION ON
   

   将 DATABASE_NAME 替换为 SQL Server 数据库的名称。

2. 将运行时实参 snapshot.isolation.mode 设置为 snapshot。如需了解详情，请参阅 向复制作业传递运行时实参。

MySQL

如需捕获 MySQL 数据库中源表的变化，复制作业会使用 Debezium 连接器。在 snapshotting阶段， Debezium 会根据配置的 snapshot.locking.mode获取锁。

默认情况下，快照锁定模式为 minimal。在此模式下，连接器会在读取数据库架构和其他元数据的初始快照部分中保留全局读取锁。然后，连接器会使用 REPEATABLE READ 事务通过一致性读取来提取所有行，该事务不会锁定表。

如需阻止任何锁，请将模式设置为 none。

警告 ：如果您使用none，请确保在快照阶段不会对 数据库应用任何架构更改，因为这可能会导致复制中的数据不一致。

或者，如需防止锁定在 Cloud SQL 上运行的 MySQL 数据库，请从 副本 而不是事务型数据库进行复制。

更改 MySQL 快照期间的锁定行为

• 如需更改 MySQL 数据库中的快照锁定行为，请将运行时 实参 snapshot.locking.mode 属性设置为适当的 锁定模式 值。

注意： 即使该属性设置为 none，使用 MyISAM 引擎定义的表仍会被锁定。

如需了解详情，请参阅向复制作业传递 Debezium 实参。

限制

• Cloud Data Fusion 中的复制支持 Debezium 连接器版本 1.3。

Cloud Data Fusion 中的 Oracle 来源

Cloud Data Fusion 中 Oracle 来源的复制由 Datastream 提供支持。Datastream 不会锁定表。

后续步骤

• 详细了解复制。