我正在尝试制作一个从MySQL到红移的复制服务器，为此，我正在解析MySQL binlog。对于初始复制，我将转储mysql表，将其转换为CSV文件，并将其上传到S3，然后使用redshift-copy命令。为此，性能是高效的。
在初始复制之后，对于连续同步，当我读取binlog时，插入和更新必须按顺序运行，这非常慢。
有什么可以做的来提高性能吗？
我能想到的一个可能的解决方案是将语句封装在事务中，然后立即发送事务，以避免多次网络调用。但这并不能解决redshift中单个更新和插入语句运行速度非常慢的问题。一个更新语句需要6秒。知道红移的局限性(它是一个柱状数据库，单行插入会很慢)，如何解决这些局限性？
编辑1：关于DMS：我想使用redshift作为一个仓库解决方案，它只是不断地复制我们的MYSQL，我不想去规范化数据，因为我在MYSQL中有170+个表。在正在进行的复制过程中，DMS在一天中多次显示许多错误，一两天后就会完全失败，而且很难破译DMS错误日志。此外，当我放置和重新加载表时，它会在红移时删除现有表，创建一个新表，然后开始插入数据，这会导致我的情况下停机。我想要的是创建一个新表，然后用新表切换旧表并删除旧表
以下是让DMS运行所需的操作
1) 创建并运行带有"迁移和正在进行的复制"one_answers"在目标上删除表"的dms任务
2) 这可能会失败，不要担心。"停止"dms任务。
3) 在红移时，对表进行以下更改
- 将所有日期和时间戳更改为varchar(因为使用的选项redshift副本的by dms无法处理"00:00:00 00:00"日期进入mysql)
- 由于dms中的一个错误，将所有bool更改为varchar
4)在dms上-在"目标表准备模式"中将任务修改为"截断">
5) 重新启动dms任务-完全重新加载
现在，初始复制和正在进行的binlog复制应该可以工作了。
确保您使用的是最新的复制实例软件版本
确保您完全按照这里的说明进行操作
http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html
如果你的来源是aurora，也要确保你已经将binlog_checksum设置为"none"(糟糕的文档)