使用说明

最近更新时间：2024-04-10 17:04:11

我的收藏

类别
说明
同步对象
1. 只支持同步基础表、视图，不支持同步函数、触发器、存储过程等对象。
2. 只支持同步 InnoDB、MyISAM、TokuDB 三种数据库引擎，如果存在这三种以外的数据引擎表则默认跳过不进行同步。
3. 相互关联的数据对象需要同时同步，否则会导致同步失败。
4. 增量同步阶段，源库的表名如含有“TDSQLagent”、 “tdsql_sub”字符可能会被过滤或者引起同步异常，因为这些表名与 TDSQL 系统的临时表名相同，TDSQLagent 为扩容时的临时表，tdsql_sub 表为 hash-lish 和 hash-range 的子表，因此建议源端待同步的表名不要设置为这些类型。
同步功能
1. 同一个任务可以关联多个 Topic，但同一个 Topic 不能同时被多个同步任务使用，否则会导致数据错乱，消费到的数据是多个不同任务的数据，也可能导致在任务重试等场景中数据处理异常，任务报错。
2. 在全量同步阶段，每同步10万条数据，会在目标端 Kafka 插入一条 checkpoint 消息，标识当前的数据同步位点。
3. DBbridge 同步到目标端 Kafka 的单条消息存在性能上限，建议用户源数据库中的单行数据不要超过8MB，否则在同步过程中可能会报错。
4. 如果用户在同步过程中确定会对某张表使用 rename 操作，投递到目标 kafka 中，分区规则会按照新的表名匹配 topic 和 partition。
源库影响
1. 数据同步时，DBbridge 会使用执行同步任务的账号在源库中写入系统库`__tencentdb__`，用于记录事务标记ID等元信息，需要确保源库对`__tencentdb__`的读写权限。
为保证后续数据对比问题可定位，同步任务结束后不会删除源库中的`__tencentdb__`
`__tencentdb__`系统库占用空间非常小，约为源库存储空间的千分之一到万分之一（例如源库为50GB，则`__tencentdb__`系统库约为5MB - 50MB），并且采用单线程，等待连接机制，所以对源库的性能几乎无影响，也不会抢占资源。
2. 默认采用无锁同步方式，全量数据导出阶段不会对源库加全局锁（FTWRL），仅对无主键的表加表锁。
目标端 Kafka 要求
1. 需要在目标 kafka 中修改消息保留时间和消息大小上限。
消息保存时间建议设置为3天，超过保存时间的数据会被清除，请用户在设置的时间内及时消费；消息大小上限，即 Kafka 可以接收的单个消息内存的大小，设置时需要大于源库表中单行数据的最大值，以确保源库的数据都可以正常投递到 Kafka 中。
2. 建议目标 Topic 为空，同时在同步任务过程中，不要在目标端选择同步的 Topic 中进行数据写入，否则可能会导致消息错乱，任务报错。
重启影响
同步任务过程中，如果发生任务重启（如源库发生 HA 切换会重启，后台检查任务异常会重启），可能会导致同步到目标端 Kafka 的数据出现重复。
DBbridge 是按最小数据单元进行同步的（全量阶段单个表对象的一块数据即为最小数据单元，增量阶段每标记一个位点就是一个数据单元），如果重启时，刚好一个数据单元同步已完成，则不会导致数据重复；如果重启时，一个数据单元还正在同步中，那么再次启动后需要重新同步这个数据单元，这样就会导致数据重复。
用户如果对重复数据比较关注，请在消费数据时设置去重逻辑。
操作限制
1. 在全量导出阶段，请勿在源库上执行库或表结构变更的 DDL 操作。
2. 请勿修改、删除源数据库和目标端中的用户信息（包括用户名、密码和权限）和端口号。
3. 请勿在源库上执行清除 Binlog 的操作。
数据类型
1. TDSQL MySQL作为源库并使用 proxy 方式连接的场景中，浮点数如果源库使用 float 数据类型，会导致全量阶段的数据精度不准确。若需保留数据精度，推荐使用 double 数据类型。全量阶段的精度问题具体影响如下：
全量阶段和增量阶段数据同步的精度不一致。
使用 float 作为键值，全量阶段和增量阶段操作的主键数据不一致。
2. DBbridge 在全量数据同步阶段，将源库数据导出并导入到目标端 Kafka，均使用 utf8mb4 字符集，以避免因字符集不识别导致乱码问题。
3. 不支持 Geometry 相关的数据类型，遇到该类型数据任务报错。
4. 增量同步过程中，若源库产生了类型为 STATEMENT 格式的 Binlog 语句，则会导致同步失败。
5. 投递到Kafka的数据类型选择 OGG JSON (ROW）时，源库的表中不能含有 gtid、current_ts、op_ts、op_type、pos、primary_keys、set_id、table 这些列名。因为这些列名与解析后 JSON 消息头中的字段名重名，如果源库的表中含有这些列名，解析后的 JSON 消息字段值会被覆盖，消费数据异常。
6. 在同步任务前，源库中已经存在的全量数据，因为没有数据写入的准确时间，在消费端 Demo 中 happenAt 字段会显示为1970-01-01 08:00:00，该时间字段无需关注。消费增量数据时，时间字段可以正确显示。
事务
不支持同时包含 DML 和 DDL 语句在一个事务的场景，遇到该情况任务会报错。
HA 切换和扩容
1. 源库如果是非 GTID 数据库，DBbridge 不支持源端 HA 切换，一旦源端 TDSQL MySQL 发生切换可能会导致 DBbridge 增量同步中断。
2. DBbridge 采用 SET 直连 TDSQL MySQL 的场景，不支持 TDSQL MySQL 扩容。采用 Proxy 连接 TDSQL MySQL 的场景，支持 TDSQL MySQL 逻辑扩容，水平扩容时 DBbridge 可能会报错。
分区表同步
1. 一级/二级分区表的语法需要符合规范，一级 Hash 分区表仅支持通过 shardkey 方式创建。
TDSQL MySQL 创建分区表的关键语法如下，详细语法请参考 TDSQL MySQL 创建表语法示例。
一级 Hash 分区：shardkey
一级 Range 分区：TDSQL_DISTRIBUTED BY RANGE
一级 List 分区：TDSQL_DISTRIBUTED BY LIST
一级 Hash 分区 + 二级 Range/List 分区：shardkey + PARTITION BY RANGE/LIST
一级 Range 分区 + 二级 Range/List 分区：TDSQL_DISTRIBUTED BY RANGE + PARTITION BY RANGE/LIST
一级 List 分区 + 二级 Range/List 分区：TDSQL_DISTRIBUTED BY LIST +  PARTITION BY RANGE/LIST
2. 增量同步阶段，不支持进行并发的 DDL 操作，需要等前一个 DDL 生效后再执行下一个，否则可能会因为 DDL 乱序导致报错。同时，也不支持快速地对同名表进行 create、drop、create 操作，否则可能会引起表类型错误。
指定位点同步
1. 如果全量同步和增量同步分开执行，这里请注意，进行全量同步时，DBbridge 已经同步的全量数据位点1与增量同步设置的启动位点2之间，不能存在 DDL 变更数据，否则任务会报错。
2. 从发起指定位点同步，到增量任务开始前（即任务步骤从“寻找指定位点”转化为“同步增量”前），建议源库不要进行主从切换、增加分片、重做备机操作，否则可能会影响 DBbridge 获取源库的 GTID 位点。同时，源端也不能进行 DDL 操作，否则任务会报错。
3. 因为指定位点同步是根据 Binlog 中 context 的时间（SET TIMESTAMP = XXXX）来判断其 GTID，为保证同步数据的正确性，建议用户不要修改该 context。
4. 请确认数据库设置的时区与当前控制台时区（即浏览器时区）一致，或者换算为数据库设置时区所对应的时间，否则可能会导致指定位点同步结果不合预期。
5. 请确认 TDSQL MySQL 各集群节点的时间保持一致，否则可能会导致指定位点同步结果不合预期。
6. 如果指定位点同步时间的第一个 Event 是两阶段 XA 事务，则该 XA 事务不会被同步。
﻿

上一篇: 支持能力下一篇: 数据同步操作指导

类别	说明
同步对象	1. 只支持同步基础表、视图，不支持同步函数、触发器、存储过程等对象。 2. 只支持同步 InnoDB、MyISAM、TokuDB 三种数据库引擎，如果存在这三种以外的数据引擎表则默认跳过不进行同步。 3. 相互关联的数据对象需要同时同步，否则会导致同步失败。 4. 增量同步阶段，源库的表名如含有“TDSQLagent”、 “tdsql_sub”字符可能会被过滤或者引起同步异常，因为这些表名与 TDSQL 系统的临时表名相同，TDSQLagent 为扩容时的临时表，tdsql_sub 表为 hash-lish 和 hash-range 的子表，因此建议源端待同步的表名不要设置为这些类型。
同步功能	1. 同一个任务可以关联多个 Topic，但同一个 Topic 不能同时被多个同步任务使用，否则会导致数据错乱，消费到的数据是多个不同任务的数据，也可能导致在任务重试等场景中数据处理异常，任务报错。 2. 在全量同步阶段，每同步10万条数据，会在目标端 Kafka 插入一条 checkpoint 消息，标识当前的数据同步位点。 3. DBbridge 同步到目标端 Kafka 的单条消息存在性能上限，建议用户源数据库中的单行数据不要超过8MB，否则在同步过程中可能会报错。 4. 如果用户在同步过程中确定会对某张表使用 rename 操作，投递到目标 kafka 中，分区规则会按照新的表名匹配 topic 和 partition。
源库影响	1. 数据同步时，DBbridge 会使用执行同步任务的账号在源库中写入系统库`__tencentdb__`，用于记录事务标记ID等元信息，需要确保源库对`__tencentdb__`的读写权限。为保证后续数据对比问题可定位，同步任务结束后不会删除源库中的`__tencentdb__` `__tencentdb__`系统库占用空间非常小，约为源库存储空间的千分之一到万分之一（例如源库为50GB，则`__tencentdb__`系统库约为5MB - 50MB），并且采用单线程，等待连接机制，所以对源库的性能几乎无影响，也不会抢占资源。 2. 默认采用无锁同步方式，全量数据导出阶段不会对源库加全局锁（FTWRL），仅对无主键的表加表锁。
目标端 Kafka 要求	1. 需要在目标 kafka 中修改消息保留时间和消息大小上限。消息保存时间建议设置为3天，超过保存时间的数据会被清除，请用户在设置的时间内及时消费；消息大小上限，即 Kafka 可以接收的单个消息内存的大小，设置时需要大于源库表中单行数据的最大值，以确保源库的数据都可以正常投递到 Kafka 中。 2. 建议目标 Topic 为空，同时在同步任务过程中，不要在目标端选择同步的 Topic 中进行数据写入，否则可能会导致消息错乱，任务报错。
重启影响	同步任务过程中，如果发生任务重启（如源库发生 HA 切换会重启，后台检查任务异常会重启），可能会导致同步到目标端 Kafka 的数据出现重复。 DBbridge 是按最小数据单元进行同步的（全量阶段单个表对象的一块数据即为最小数据单元，增量阶段每标记一个位点就是一个数据单元），如果重启时，刚好一个数据单元同步已完成，则不会导致数据重复；如果重启时，一个数据单元还正在同步中，那么再次启动后需要重新同步这个数据单元，这样就会导致数据重复。用户如果对重复数据比较关注，请在消费数据时设置去重逻辑。
操作限制	1. 在全量导出阶段，请勿在源库上执行库或表结构变更的 DDL 操作。 2. 请勿修改、删除源数据库和目标端中的用户信息（包括用户名、密码和权限）和端口号。 3. 请勿在源库上执行清除 Binlog 的操作。
数据类型	1. TDSQL MySQL作为源库并使用 proxy 方式连接的场景中，浮点数如果源库使用 float 数据类型，会导致全量阶段的数据精度不准确。若需保留数据精度，推荐使用 double 数据类型。全量阶段的精度问题具体影响如下：全量阶段和增量阶段数据同步的精度不一致。使用 float 作为键值，全量阶段和增量阶段操作的主键数据不一致。 2. DBbridge 在全量数据同步阶段，将源库数据导出并导入到目标端 Kafka，均使用 utf8mb4 字符集，以避免因字符集不识别导致乱码问题。 3. 不支持 Geometry 相关的数据类型，遇到该类型数据任务报错。 4. 增量同步过程中，若源库产生了类型为 STATEMENT 格式的 Binlog 语句，则会导致同步失败。 5. 投递到Kafka的数据类型选择 OGG JSON (ROW）时，源库的表中不能含有 gtid、current_ts、op_ts、op_type、pos、primary_keys、set_id、table 这些列名。因为这些列名与解析后 JSON 消息头中的字段名重名，如果源库的表中含有这些列名，解析后的 JSON 消息字段值会被覆盖，消费数据异常。 6. 在同步任务前，源库中已经存在的全量数据，因为没有数据写入的准确时间，在消费端 Demo 中 happenAt 字段会显示为1970-01-01 08:00:00，该时间字段无需关注。消费增量数据时，时间字段可以正确显示。
事务	不支持同时包含 DML 和 DDL 语句在一个事务的场景，遇到该情况任务会报错。
HA 切换和扩容	1. 源库如果是非 GTID 数据库，DBbridge 不支持源端 HA 切换，一旦源端 TDSQL MySQL 发生切换可能会导致 DBbridge 增量同步中断。 2. DBbridge 采用 SET 直连 TDSQL MySQL 的场景，不支持 TDSQL MySQL 扩容。采用 Proxy 连接 TDSQL MySQL 的场景，支持 TDSQL MySQL 逻辑扩容，水平扩容时 DBbridge 可能会报错。
分区表同步	1. 一级/二级分区表的语法需要符合规范，一级 Hash 分区表仅支持通过 shardkey 方式创建。 TDSQL MySQL 创建分区表的关键语法如下，详细语法请参考 TDSQL MySQL 创建表语法示例。一级 Hash 分区：shardkey 一级 Range 分区：TDSQL_DISTRIBUTED BY RANGE 一级 List 分区：TDSQL_DISTRIBUTED BY LIST 一级 Hash 分区 + 二级 Range/List 分区：shardkey + PARTITION BY RANGE/LIST 一级 Range 分区 + 二级 Range/List 分区：TDSQL_DISTRIBUTED BY RANGE + PARTITION BY RANGE/LIST 一级 List 分区 + 二级 Range/List 分区：TDSQL_DISTRIBUTED BY LIST + PARTITION BY RANGE/LIST 2. 增量同步阶段，不支持进行并发的 DDL 操作，需要等前一个 DDL 生效后再执行下一个，否则可能会因为 DDL 乱序导致报错。同时，也不支持快速地对同名表进行 create、drop、create 操作，否则可能会引起表类型错误。
指定位点同步	1. 如果全量同步和增量同步分开执行，这里请注意，进行全量同步时，DBbridge 已经同步的全量数据位点1与增量同步设置的启动位点2之间，不能存在 DDL 变更数据，否则任务会报错。 2. 从发起指定位点同步，到增量任务开始前（即任务步骤从“寻找指定位点”转化为“同步增量”前），建议源库不要进行主从切换、增加分片、重做备机操作，否则可能会影响 DBbridge 获取源库的 GTID 位点。同时，源端也不能进行 DDL 操作，否则任务会报错。 3. 因为指定位点同步是根据 Binlog 中 context 的时间（SET TIMESTAMP = XXXX）来判断其 GTID，为保证同步数据的正确性，建议用户不要修改该 context。 4. 请确认数据库设置的时区与当前控制台时区（即浏览器时区）一致，或者换算为数据库设置时区所对应的时间，否则可能会导致指定位点同步结果不合预期。 5. 请确认 TDSQL MySQL 各集群节点的时间保持一致，否则可能会导致指定位点同步结果不合预期。 6. 如果指定位点同步时间的第一个 Event 是两阶段 XA 事务，则该 XA 事务不会被同步。