AWS RDS的mysqldump挂起

我正在尝试在RDS MySQL实例之间迁移数据。 我无法使用快照，因为通过此迁移，我想要encryption底层磁盘和升级版本（5.1.73a到5.5.41）。 数据压倒一张桌子; 整体而言，数据库的重量为24.3 GB，23.9 GB集中在一个表（用户login表）中。

为了限制停机时间，我正在备份该表中的历史数据 – 即在停机之前，从id小于89,000,000的login表中转移所有读取，并且在id大于或等于89,000,000。 该命令是：

mysqldump -u${source_user} --opt --skip-add-drop-table -p${source_password} --host=${source_host} ${database} ${table_name} --where="${where_clause}" | sed 's/CREATE TABLE/CREATE TABLE IF NOT EXISTS/g' | mysql -C -u${target_user} -p${target_password} --host=${target_host} ${database} 

这是hacky，但以前运作良好。 我从第三台服务器运行它。

不过，这一次我遇到了问题。 我用几种方法运行它。 当我把它作为一个块运行时，吞吐量是非常可变的，并且最终整个过程在协调服务器上显示的没有任何networking负载的情况下结束。 我也试图通过id（即seq 0 100000 89000000 ）将行分块（ seq 0 100000 89000000 ），这个行开始很好，但是挂在特定的块上 – 例如，中值100k行块大约需要8秒，但是十行中可能有一行300+秒。 我甚至不在乎是否花了那么长时间，但是这也发生了：

• 如何将MySQL 5.6升级到MariaDB
• 只有从失败的HD移动后才能读取MySQL Tables
• 完整的LAMP包装
• MySQL：无法通过SSH连接到服务器。 '读取初始通信包'，系统错误：0
• 无法使用SSL连接到MySQL 5.5

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table at row: 42158

目标实例显示100％的CPU使用率，非常繁忙的bin日志，写入接近600的“iops”尖峰和队列深度，再次接近20的spikey。我尝试将每个超时设置为1000秒，将bin日志大小加倍，效果甚微。 我的同事推测，这是写入IOPS（这是一个基于SSD的实例，没有提供IOPS的记​​录）的问题，但我们已经采取了类似的服务器这一点，并没有经历过这个相同的问题。 源代码是带有磁盘驱动器的当前生产服务器的最新映像。

我错过了什么？ 谢谢。