资讯专栏INFORMATION COLUMN

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

IT那活儿 / 3448人阅读
跨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。


END


更多精彩干货分享

点击下方名片关注

IT那活儿

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129887.html

相关文章

  • 数据库的 Consistency 与 Leaky Abstraction

    摘要:最近在学习各大互联网公司是如何处理数据一致性的。目前已知的有这么几种数据库做到情况下的强一致性淘宝淘宝顶级科学家阳振坤微博号阿里正祥,发出一则消息。然后因为数据库是的,内部把改动到了北美,君就可以看到消息了。 最近在学习各大互联网公司是如何处理数据一致性的。因为之前从事的不是这个方向的工作,所以并非什么经验之谈,只是一些学习笔记。所有资料来自互联网。 Consistent => Ev...

    Wildcard 评论0 收藏0
  • 数据库的 Consistency 与 Leaky Abstraction

    摘要:最近在学习各大互联网公司是如何处理数据一致性的。目前已知的有这么几种数据库做到情况下的强一致性淘宝淘宝顶级科学家阳振坤微博号阿里正祥,发出一则消息。然后因为数据库是的,内部把改动到了北美,君就可以看到消息了。 最近在学习各大互联网公司是如何处理数据一致性的。因为之前从事的不是这个方向的工作,所以并非什么经验之谈,只是一些学习笔记。所有资料来自互联网。 Consistent => Ev...

    wanghui 评论0 收藏0
  • 云迁移过程中的数据同步及一致性校验实践(二)

    摘要:另外对于需要尽量减少应用重启的系统也可以优先考虑这种方式来保障数据一致性。只需要保证这三类程序都是停止的,那么就可以保证没有同步服务以外的程序对数据进行修改,从而保障数据一致性。在《跨云迁移过程中的数据同步及一致性校验实践(一)》中我们主要介绍了跨云迁移中数据同步阶段的存储组件MySQL、文件存储和对象存储的数据迁移过程,本文将重点围绕跨云迁移的数据规整阶段(清理测试时产生的脏数据)和数据割...

    Tecode 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<