# 跨IDC同步工具常见问题解析

> 作者/来源: UCloud 运营管理员
> 发布时间: 2023-01-11T05:20:00.000Z
> 分类: 其他
> 标签: AI, 数据库, Java
> 原文链接: http://117.50.162.249:3000/yun/articles/1046

---

# 跨IDC同步工具常见问题解析

> 来源: https://www.ucloud.cn/yun/129887.html
> 作者: IT那活儿
> 发布日期: 发布于2023-01-11 13:20

跨IDC同步工具常见问题解析

一. 数据一致性问题

- 源库中有很多事务，组件是否按照事务同步，增量同步会按照事务来解析binlog，将事务都放在同一个数据批次中，一起入库，遇到极大的事务（例如某个大事务产生10G的binlog文件）会做拆分，但尽量保证事务属于同一批次。
- 增量全量同步能否一起开，不建议一起开启，有小概率产生数据一致性问题，例如ABC三个先后间隔很短的时刻，全量在A时刻完成了数据抽取，B时刻数据有更新且立即被增量同步到了目标端，C时刻全量完成了入库，则B时刻更新的数据将会丢失。
- 保证数据一致性严格的操作顺序：暂停被同步表的业务，不再产生与被同步表相关的binlog；等待增量同步通道追平；停止增量同步，开启全量同步；全量同步完成后继续开启增量同步。
- 常用操作顺序：记录当前增量同步的位点信息；停止增量同步，开启全量同步；全量同步完成后从之前记录 的位点信息继续进行增量同步（最终一致性）。
- 特别注意问题：由于分布式数据库的特性，udal禁止对分片键做update操作；部分业务为了绕过这种限制，设计对分片键的update实际上由两部分组成：一个片中的delete语句+另一个片中的insert语句，当同步场景为udal->oracle时由于时序问题可能会导致数据不一致；解决方式：

1) 避免出现update分片键的情况

2) 将分片键和原主键一起作为新的联合主键

  （需要更改业务）

3) 使用自增的序列作为主键

二. 同步速度参数优化

全量同步速度不理想，建议参数和优化：同步速度空表大于有记录的表，无索引的表大于有索引的表，目标表索引越多，速度越慢，建议索引在同步完成后重建。

|  |
| --- |
| #全量批次大小  syncall.manager.batchSize = 200  #jdbc,batch入库一次处理的数据量  syncall.manager.batchOfInsertUpdate = 10000  # 同步表线程池大小（并发核对目标表的个数）  syncall.manager.taskpoolsize = 1  #初始化table信息线程池大小  syncall.manager.initpoolsize = 10  # 批次任务线程池大小（并发批次任务个数）大于或等于querypoolsize  syncall.manager.jobpoolsize = 40  # 抽取数据线程池大小（抽取并发度控制）小于或等于jobpoolsize  syncall.manager.querypoolsize = 20    # 初始化时建立物理连接的个数  druid.initialSize=10  # 最小连接池数量  druid.minIdle=6  # 最大连接池数量  druid.maxActive=500  # 获取连接时最大等待时间，单位毫秒。  druid.maxWait=60000  # 申请连接时检测连接是否有效  druid.test.OnBorrow=true |

三. 跨IDC同步工具常见问题及解决

**问题1：**Access denied for user （udal--udal）。

|  |
| --- |
| 报错如下：  10:17:07.146 [Druid-ConnectionPool-Create-1846815119] ERROR c.alibaba.druid.pool.DruidDataSource -  create connection SQLException, url: jdbc:mysql://133.0.xxx.xxx:xxx/stt\_iss\_161, errorCode 1044,  state 42000  com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access denied for user sla@% to database stt\_iss\_161 |

**报错原因：**

账号或密码不对，由于源端和目标端的分片数据库密码不一样，在初始化时，两端的密码账号会被程序默认设成一致。

**解决办法：**

需要在初始化完成后，将数据源配置 和 增量管理菜单修改为各自的账号密码。

**问题2：**部署pg到kafka的时候时间相差8小时。

**异常现象：**

PG端时间类型的字段，带default current\_timestamp 时，生成的数据。投递到目标kafka时时间会增加8小时。

**异常原因：**

pg数据库中的表字段类型为`TIMESTAMP WITHOUT TIME ZONE`,未使用时区，跨idc工具投递中会默认为格林威治时间。

**解决办法：**

将pg数据库中的表字段类型改为`TIMESTAMP WITH TIME ZONE`，使用时区。

**问题3：**node节点无法自动创建

**异常原因及解决办法：**

node机器的用户密码过期导致，密码重置后正常。

**问题4：**teledb同步到kafka  show master status has an error!

|  |
| --- |
| **异常报错：**  pid:70 nid:37 exception:canal:canal\_133.0.148.26\_8922\_5:com.alibaba.otter.canal.parse.exception.CanalParseException: command : show master status has an error! Caused by:  java.io.IOException: ErrorPacket [errorNumber=1227, fieldCount=-1, message=Access denied; you need (at least one of) the SUPER, REPLICATION CLIENT privilege(s) for this operation, sqlState=42000, sqlStateMarker=#] with command: show master status at com.alibaba.otter.canal.parse.inbound.AbstractEventParser$3.run(AbstractEventParser.java:194) at java.lang.Thread.run(Thread.java:748) |

**解决办法：**

为idc用户赋予权限

GRANT super,REPLICATION SLAVE, REPLICATION CLIENT ON \*.\* TO idc@%;

**问题5：**全量同步性能差

**异常现象：**

全量同步，表包含大字段等类型，每条记录的大小远超普通表，出现同步性能差/无法同步现象，例如全量日志中取样数据大小日志如下：<<<<<< avg one record use [451.274 KB] space ,one batch data use [881.395 MB] space, memory limit is [10 GB] , set data queue size to [11] >>>>>>

**调整方法：**

调整全量参数，降低每批次数据的大小和数据缓存队列大小

syncall.manager.batchSize=50

syncall.manager.jobpoolsize=100

syncall.stream.dataQueue=100

使用优化的jvm启动脚本，例如launch\_performance.sh脚本来启动manager，分配足够多的内存放到manager目录下  chmod +x launch\_performance.sh  然后指定内存启动，例如  sh launch\_performance.sh memory 60g 60g。

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129887/images/129887_000.png)

END

更多精彩干货分享

点击下方名片关注

IT那活儿

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129887/images/129887_001.png)