数据开发治理平台 WeData MySQL 数据源

一、支持版本

目前数据集成已支持 MySQL 单表及整库级实时读取，使用实时读取能力需遵循以下版本限制：

二、使用限制

·需要开启 Binlog 日志，且日志保留时长至少3天，如果全量阶段数据量很大，请延长增量日志保留时长。

·仅支持同步 MySQL 服务器 Binlog 配置格式为 ROW。

·无主键的表由于无法保证 exactly once 可能会有数据重复，因此实时同步任务最好保证有主键。

·不支持 XA ROLLBACK，实时同步的任务不会针对 XA PREPARE 的数据进行回滚的操作，若要处理 XA ROLLBACK 场景，需要手动将 XA ROLLBACK 的表从实时同步任务中移除，再添加表后重新进行同步。

·设置 MySQL 会话超时：

当为大型数据库制作初始一致快照时，你建立的连接可能会在读取表时超时。你可以通过在 MySQL 配置文件中配置 interactive_timeout 和 wait_timeout 来防止这种行为。

·interactive_timeout：服务器在关闭交互式连接之前等待其活动的秒数。请参阅 MySQL :: MySQL 8.0 Reference Manual :: 7.1.8 Server System Variables。

·wait_timeout：服务器在关闭非交互式连接之前等待其活动的秒数。请参阅 MySQL :: MySQL 8.0 Reference Manual :: 7.1.8 Server System Variables。

四、确认 MySQL 版本

数据集成对 MySQL 版本有要求，查看当前待同步的 MySQL 是否符合版本要求。你可以在 MySQL 数据库通过如下语句查看当前 MySQL 数据库版本。

select version();

五、设置 MySQL 服务器权限

你必须定义一个对 Debezium MySQL 连接器监控的所有数据库具有适当权限的 MySQL 用户。

1. 创建 MySQL 用户（可选）:

mysql> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password';

2. 向用户授予所需的权限:

在实时数据同步的情况下，该账号必须拥有数据库的 SELECT、REPLICATION SLAVE 和 REPLICATION CLIENT 权限。执行命令可以参考下面：

mysql> GRANT SELECT, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'user'@'localhost' IDENTIFIED BY 'password';

注意：启用 scan.incremental.snapshot.enabled 时不再需要 RELOAD 权限（默认启用）。

3. 刷新用户的权限：

mysql>FLUSH PRIVILEGES;

查看更多关于 权限说明。

六、开启 MySQL Binlog

1. 检查 binlog 是否开启

show variables like "log_bin";

·返回结果为 ON 时，表示已经开启 Binlog， 如果为备库，使用如下语句：

show variables like "log_slave_updates";

·如果返回为 ON 时，表示已经开启 Binlog，如果已经开启 Binlog，可跳过下面流程。

2. 开启 Binlog

如果确认没有开启 Binlog，则需要进行以下操作：

·对于腾讯云实例 MySQL，默认开启了 binlog。

·对于开源 MySQL，参考产品文档开启 binlog。

3. binlog_row_image

实时同步仅支持同步 MySQL 服务器 binlog_row_image 配置格式为 FULL or full。

使用如下语句查询 binlog_row_image 的使用格式。

show variables like "binlog_row_image";

如果返回非 FULL/full 请修改 binlog_row_image：

·对于开源 MySQL, 参考产品文档：

MySQL :: MySQL 8.0 Reference Manual :: 17.1.6.4 Binary Logging Options and Variables

·对于腾讯云实例 MySQL：

·登录腾讯云 MySQL控制台，找到要开启 Binlog 的实例，点击进入该实例的详细信息页面。

·在上面选项卡中选择数据库管理，找到参数设置选项卡。

·在参数设置选项卡中，找到binlog_row_image参数，将其设置为“FULL”。

七、开启 GTIDs（可选）

GTID（Global Transaction Identifier， 全局事务标识），用于在 binlog 中唯一标识一个事务，使用 GTID 可以避免事务重复执行导致数据混乱或者主从不一致。

开启流程

1. 检查是否开启了 GTID

show global variables like '%GTID%';

返回结果类似如下，证明已经开启 GTID。

+————————–+——-+| Variable_name | Value |+————————–+——-+| enforce_gtid_consistency | ON || gtid_mode | ON |+————————–+——-+

2. 开启 GTID

·对于开源 MySQL，参考产品文档 MySQL :: MySQL 8.0 Reference Manual :: 17.1.4.2 Enabling GTID Transactions Online。

·对于腾讯云实例 MySQL ，默认为开启，不支持关闭。

八、实时整库同步来源配置

MySQL 整库同步过程中，任务使用主键或唯一索引（无主键时）进行切分，当前支持的主键类型包括：

九、实时分库分表来源配置

参见 分库分表配置

十、实时单表读取配置

十一、实时单表写入配置

十三、读取

MySQL 读取支持的数据类型及转换对应关系如下（在处理 MySQL 时，会先将 MySQL 数据源的数据类型和数据处理引擎的数据类型做映射）

十四、写入

MySQL 写入支持的数据类型及转换对应关系如下：

十六、MySQL serverid 冲突

错误信息：

com.github.shyiko.mysql.binlog.network.ServerException: A slave with the same server_uuid/server_id as this slave has connected to the master。

解决办法：目前已经优化增加随机生成 serverid，之前的任务中如果在 MySQL 高级参数中显示指定了 server-id 建议删除，因为可能多个任务使用了相同的数据源，并且 server-id 设置的相同导致冲突。

十七、报 binlog 文件找不到错误信息：

错误信息：

Caused by: org.apache.kafka.connect.errors.ConnectException: The connector is trying to read binlog starting at GTIDs xxx and binlog file 'binlog.xxx', pos=xxx, skipping 4 events plus 1 rows, but this is no longer available on the server. Reconfigure the connector to use a snapshot when needed。

错误原因：

作业正在读取的 binlog 文件在 MySQL 服务器已经被清理时，会产生报错。导致 Binlog 清理的原因较多，可能是 Binlog 保留时间设置的过短；或者作业处理的速度追不上 Binlog 产生的速度，超过了 MySQL Binlog 文件的最大保留时间，MySQL 服务器上的 Binlog 文件被清理，导致正在读的 Binlog 位点变得无效。

解决办法：如果作业处理速度无法追上 Binlog 产生速度，可以考虑增加 Binlog 的保留时间也可以优化作业减轻反压来加速 source 消费。如果作业状态没有异常，可能是数据库发生了其他操作导致 Binlog 被清理，从而无法访问，需要结合 MySQL 数据库侧的信息来确定 Binlog 被清理的原因。

十八、MySQL 报连接被重置

错误信息：

EventDataDeserializationException: Failed to deserialize data of EventHeaderV4 …. Caused by: java.net.SocketException: Connection reset。

错误原因：

1. 网络问题。

2. 作业存在反压，导致 source 无法读取数据，binlog client 空闲，如果 binlog 连接在超时后仍然空闲 mysql 服务器会断开空闲的连接。

解决方法：

1. 如果是网络问题，可以调大 mysql 网络参数 set global slave_net_timeout = 120; (默认30s) set global thread_pool_idle_timeout = 120。

2. 如果是作业反压导致，可以通过调节作业减轻反压，例如增加并行度，提升写入速度，提升 taskmanager 内存减少 gc。

十九、MySQL2dlc 任务 JobManager OO

错误信息：

错误原因和解决方法：

1. 用户数据量比较大，可以调大 jobmanager CU 数，使用 mysql 高级参数 scan.incremental.snapshot.chunk.size 调大 chunk size 大小，默认是8096。

2. 用户数据量不大，但是主键最大值-最小值的差值却很大，导致使用均分 chunk 的策略时划分很多 chunk，修改分布因子，让用户数据走非均匀的数据切分逻辑，split-key.even-distribution.factor.upper-bound=5.0d，默认值分布因子已经修改为10.0d。

20、用户的 binlog 数据格式不对，导致 debezium 解析异常

错误信息：

ERROR io.debezium.connector.mysql.MySqlStreamingChangeEventSource [] – Error during binlog processing. Last offset stored = null, binlog reader near position = mysql-bin.000044/211839464.2023-02-20 21:37:28.480 [blc-172.17.48.3:3306] ERROR io.debezium.pipeline.ErrorHandler [] – Producer failure io.debezium.DebeziumException: Error processing binlog event.

解决方法：

修改 binlog_row_image=full 后需要重启数据库。

21、是否支持 gh-ost？

支持，不会迁移 Online DDL 变更产生的临时表数据，只迁移源库使用 gh-ost 执行的原始 DDL 数据，同时你可以使用默认的或者自行配置 gh-ost 影子表和无用表的正则表达式。