在mysql期间缓慢插入和更新命令以进行红移复制

dil*_*ngh 6 binlog amazon-redshift

我正在尝试将复制服务器从MySQL转换为redshift,为此,我正在解析MySQL binlog.对于初始复制,我正在进行mysql表的转储,将其转换为CSV文件并将其上传到S3,然后使用redshift copy命令.为此,性能是有效的.

在初始复制之后,对于我在读取binlog时的连续同步,必须按顺序运行插入和更新,这非常慢.

有什么可以提高性能吗?

我能想到的一个可能的解决方案是将语句包装在事务中,然后立即发送事务,以避免多个网络调用.但这并不能解决redshift中单个更新和插入语句运行速度非常慢的问题.单个更新语句需要6秒.知道redshift的局限性(它是一个柱状数据库和单行插入会很慢)可以做些什么来解决这些限制?


编辑1:关于DMS:我想用红移作为仓库解决方案,其中只是复制我们的MySQL不断,我不想denormalise数据,因为我有在MySQL 170+表.在进行复制期间,DMS在一天内多次显示许多错误,并在一两天后完全失败,并且很难解密DMS错误日志.此外,当我删除并重新加载表时,它会删除redshift上的现有表并创建新表,然后开始插入导致我的情况下停机的数据.我想要的是创建一个新表,然后用新表切换旧表并删除旧表

Jon*_*ott 0

要使 DMS 正常工作,您需要执行以下操作

1)使用“迁移和持续复制”和“删除目标上的表”创建并运行 dms 任务

2)这可能会失败,不用担心。“停止”dms 任务。

3)在redshift上对表进行以下更改

  • 将所有日期和时间戳更改为 varchar (因为 dms 用于 redshift 复制的选项无法处理您在 mysql 中获得的“00:00:00 00:00”日期)
  • 将所有 bool 更改为 varchar - 由于 dms 中的错误。

4)在dms上-将“目标表准备模式”中的任务修改为“截断”

5)重新启动dms任务-完全重新加载

现在 - 初始副本和正在进行的二进制日志复制应该可以工作。

确保您使用的是最新的复制实例软件版本

确保您已完全按照此处的说明进行操作

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html

如果您的源是 aurora,还要确保您已将 binlog_checksum 设置为“none”(错误文档)