本文为您介绍实时同步的相关问题。
文档概述
问题分类 | 相关文档 |
实时同步任务配置须知 | |
实时同步MySQL数据常见问题 | |
实时同步Oracle、PolarDB、MySQL常见问题 | |
报错信息与解决方案 |
|
实时同步任务配置须知
实时同步任务支持哪些数据源？
实时同步支持的数据源请参考文档：实时同步支持的数据源。
为什么实时同步任务延迟较大？
当您在查询实时同步任务产出的表数据，发现数据未同步时，原因可能是实时同步任务出现延迟，您可以进入运维中心的实时同步任务界面，查看任务的业务延迟数值是否过大。详情请参见实时同步任务延迟解决方案。
若业务延迟较大，其可能原因如下：
报错现象 | 直接原因 | 解决方案 |
读端延迟大 | 源端数据量变更过多。 延迟突然增大，说明某一时间点源端数据量增加。 | 若源端数据更新快，数据量多，但同步延迟大，您可以：
|
同步起始位点设置较早。 | 若起始位点比较早，实时同步任务追平数据需要一定时间。 | |
写端延迟大 | 目标数据库性能、负载等问题 | 当数据库负载较高时，单一的调整同步任务并发并不能解决问题，您需要联系数据库管理员寻求相关帮助。 |
读写端延迟大 | 使用公网同步，网络问题导致同步任务延迟。 | 公网同步无法保障实时同步时效性，建议您打通网络后通过内网同步数据。 说明 公网同步存在以下风险：网络可能不稳定，丢包等时常发生，影响同步性能，安全性不高。 |
若源端和目标端数据库性能差异较大或数据库负载较高，同样会导致延迟较大。 | 当数据库负载较高时，单一的调整同步任务并发并不能解决问题，您需要联系数据库管理员寻求相关帮助。 |
实时同步任务为什么不建议使用公网？
实时同步任务使用公网时，会存在以下风险：
网络可能不稳定，丢包等时常发生，影响同步性能。
安全性不高。
实时同步字段格式问题
数据集成实时同步在同步MySQL、Oracle、Loghub和PolarDB类型的数据至DataHub或Kafka时，会在同步的目标端添加5个附加列，以进行元数据管理、排序去重等操作。详情请参见实时同步字段格式。
实时同步数据时，如何处理TRUNCATE？
实时同步支持TRUNCATE的，在增全量合并的时候会生效。如果选择忽略TRUNCATE，可能会导致进行实时数据同步时出现多的数据。
如何提高实时同步的速度和性能？
如果同步写入速度较慢，可以适当增加写入端并发数，调整JVM参数，JVM参数与同步库数量无关，和变更频率有关。在当前资源组机器允许情况下，内存给的越大，Full GC频率会越小，实时同步性能相应也会越高。
实时同步是否支持在界面运行？
实时同步不支持在DataWorks的界面上直接运行，您需要在配置好实时同步任务后，提交并发布实时同步节点后，进入生产环境运行该节点。详情请参见实时同步任务运维。
实时同步MySQL数据源时速度为什么会变慢？
原因之一就是同步的binlog变多，因为binlog是实例级别，即便配置的同步任务只同步了表A，那么没有在任务中的表B、表C等如果发生变更，也会生成binlog，这些额外增加的binlog就会使同步处理的速度变慢。
实时同步中选择单库与选择多库的内存占用模式为什么会有差异？
选择大于等于2个库时就进入了“整实例”实时同步的模式，此时资源的占用要高于2个单独只有一个库的实时任务。
实时同步任务DDL策略都有哪些？
处理方式如下：
正常处理 | 忽略 | 报警 | 出错 |
此DDL消息将会继续下发给目标数据源，由目标端数据源来处理，不同目标端数据源处理策略可能会不同。 | 丢弃掉此DDL消息，目标端数据源不会做任何处理。 | 丢弃掉此DDL消息，同时发送告警信息。 说明 如果实时任务未配置对应报警规则，则无法收到对应的报警信息。 | 直接让实时同步任务以出错状态终止运行。 说明 如果实时任务配置了任务状态对应的报警规则，则可以收到对应的报警信息。 |
DDL类型划分：
新建表 |
|
删除表 |
|
新增列 |
|
删除列 | 暂不支持正常处理，只能选择忽略、报警、出错。 |
重命名表 | 暂不支持正常处理，只能选择忽略、报警、出错。 |
重命名列 | 暂不支持正常处理，只能选择忽略、报警、出错。 |
修改列类型 |
|
清空表 |
|
写入目标数据源时，对源端DDL及DML操作的注意事项
当源端新增列，并在目标端正常执行后，会有以下限制：
当新增DEFAULT VALUE列后，目标表该新列不会有值，会一直为NULL，后续当源端新增列中新增数据时，实时同步任务会将新增数据同步至该列。
当新增VIRTUAL列后，目标表该新列不会有值，会一直为NULL，后续当源端新增列中新增数据时，实时同步任务会将新增数据同步至该列。
MySQL和PolarDB MySQL源端实时同步，建议您在源端新增列时采用末尾追加列方式，不要采用在中间字段加列方式。如果源端无法避免中间字段加列，需要注意以下约束条件：
全增量解决方案中，在全量同步阶段不要进行中间字段加列，否则会导致实时同步阶段数据异常。
实时同步阶段，同步位点重置时间需要设置在中间字段加列DDL事件之后，否则会导致后续实时同步数据异常。
如果发生数据异常，可以重新进行全量数据初始化方案（只需要将中间加列的表剔除，然后重新进行数据初始化，不需要将整个任务所有表进行全量初始化），恢复正确数据。
源表有默认值，通过数据集成创建的目标表，默认值、非空属性等会保留吗？
创建目标表时候，DataWorks只会保留源表的列名、数据类型、注释等信息，不会保留源表的默认值、约束（包含非空约束、索引等）。
读取Postgres的实时同步任务Failover了，延迟为什么很大？
这是Postgres本身数据库的特性，如果接受不了延迟，您可以停止任务，并重新启动任务做一次全增量数据同步。
实时同步MySQL数据常见问题
实时同步MySQL数据源的数据时，一开始读到数据，一段时间后无法读到数据，怎么处理？
可在数据库执行以下命令，查看当前这个数据库实例正在写入的binlog文件。
show master status对比日志中读到的binlog文件，在日志中搜
journalName=MySQL-bin.000001,position=50，确认是否有数据写入数据库。如果有数据在写入，但是binlog却没有往前推进，请联系DBA处理。
实时同步Oracle、PolarDB、MySQL常见问题
实时同步Oracle、PolarDB、MySQL任务重复报错
现象：实时同步任务重复报错。
实时同步来源为Oracle、PolarDB、MySQL数据源时，默认不支持处理源端DDL消息，当进行除新建表以外的DDL变更时，实时任务将报错退出。断点续传情况下，可能存在源端未产生DDL消息，但同步仍然报错的情况。
说明为避免数据在某时间段内丢失或错乱，禁止使用Rename命令将两列的名称互换。例如，将A列和B列的列名做了调换操作。
原因：由于实时同步支持断点续传，为保障不丢失数据，在重启实时同步回溯位点时可能会往前回溯一部分数据，此过程可能导致之前的DDL消息再次被读取而再次报警。
解决方案：
当源端产生DDL变更时，手动在目标端数据库进行相应的DDL变更。
启动实时同步任务并变更DDL消息处理策略，由出错改为忽略。
说明由于断点续传还会订阅到该DDL事件，为了避免任务依然失败，所以暂时改为忽略。
停止实时同步任务并再次修改DDL消息处理策略，由忽略还原为出错，并再次重启实时同步任务。
报错信息与解决方案
Kafka实时同步报错： Startup mode for the consumer set to timestampOffset, but no begin timestamp was specified.
请重置启动位点。
MySQL实时同步报错：Cannot replicate because the master purged required binary logs.
MySQL实时同步报错：Cannot replicate because the master purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new slave from backup.时，可能是因为在MySQL未找到消费位点的binlog记录，请检查您MySQL的binlog保留时间，同步任务启动时请将该位点配置在这个时间范围内。
如果您订阅不到binlog，可以尝试重置位点到当前时间。
MySQL实时同步报错：MySQLBinlogReaderException
MySQL实时同步报错：MySQLBinlogReaderException: The database you are currently syncing is the standby database, but the current value of log_slave_updates is OFF, you need to enable the binlog log update of the standby database first. 时，可能是因为备库没有开启binlog，如果您要同步备库，需要做备库级联开启binlog，可以找DBA寻求帮助。
开启binlog的操作详情可参见步骤3：开启MySQL的Binlog。
MySQL实时同步报错：show master status' has an error!
MySQL实时同步报错：show master status' has an error!，报错详情为Caused by: java.io.IOException: message=Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation, with command: show master status时，可能是因为数据源没有开启对应数据库的权限。
数据源配置账号需要拥有数据库的SELECT、REPLICATION SLAVE、REPLICATION CLIENT权限。给数据源添加数据库对应权限的操作详情可参见步骤2：创建账号并配置权限。
MySQL实时同步报错：parse.exception.PositionNotFoundException: can't find start position forxxx
同步未找到位点，请重置位点。
MySQL实时同步报错：数据库位点过期，请重新选择位点，源库可用最早位点xxx
重置位点：在启动实时同步任务时，重置位点并选择源库可用的最早位点。
调整Binlog保留时间：如果数据库位点过期，可以考虑在MySQL数据库中调整Binlog的保留时间，例如设置为7天。
数据同步：如果数据已经丢失，可以考虑重新全量同步，或者配置一个离线同步任务来手动同步丢失的数据。
实时同步Hologres报错：permission denied for database xxx
实时同步Hologres数据时，需要在Hologres给当前操作用户Hologres实例的admin权限（需要有创建schema的权限），操作详情可参见Hologres权限模型概述。
实时同步至MaxCompute报错：ODPS-0410051:invalid credentials-accessKeyid not found
当实时同步至MaxCompute数据源且使用临时AK进行同步时，临时AK超过7天会自动过期，同时，将导致任务运行失败。平台检测到临时AK导致任务失败时会自动重启任务，如果任务配置了该类型的监控报警，您将会收到报警信息。
实时同步至Oracle报错：logminer doesn't init, send HeartbeatRecord
实时同步至Oracle任务在初始化找合适的同步位点时，需要加载上一份归档的日志，如果归档日志较大，则需要加载3～5分钟才会完成初始化init阶段。