我正在尝试在 RDS MySQL 实例之间迁移数据。我无法使用快照，因为通过此迁移，我想加密底层磁盘并升级版本（5.1.73a 到 5.5.41）。数据绝大部分位于一个表中；总体而言，数据库重 24.3 GB，其中 23.9 GB 集中在一个表（用户登录表）中。
为了限制停机时间，我正在备份该表中的历史数据 - 即在停机之前，从登录表中传输所有读取的数据，其中 id 小于 89,000,000，在停机期间传输所有读取的数据，其中 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}
虽然有点儿老套，但之前用起来还不错。我从第三台服务器运行它。
但是，这次我遇到了问题。我用几种方法运行它。当我将它作为一个块运行时，吞吐量变化很大，最终整个过程挂起，协调服务器上没有任何网络负载。我还尝试按 id 对行进行分块（即seq 0 100000 89000000），这开始很好，但在某些块上会挂起——例如，中位数为 100k 行的块大约需要 8 秒，但可能十分之一的行需要 300 多秒。有时我甚至不在乎它是否花了那么长时间，但随后也发生了这种情况：
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table at row: 42158
目标实例显示 CPU 使用率为 100%，bin 日志非常繁忙，写入“iops”峰值接近 600，队列深度再次达到峰值，接近 20。我尝试将几乎每个超时都设置为 1000 秒，将 bin 日志大小加倍，但效果甚微。我的同事推测这是写入 IOPS 的问题（这是一个基于 SSD 的实例，没有预配置 IOPS），但我们对类似的服务器采取了同样的策略，没有遇到同样的问题。来源是带有磁盘驱动器的当前生产服务器的最新图像。
我遗漏了什么？谢谢。
答案1
我不会进行转储和重新加载，而是临时在两个 MySQL 服务器之间设置复制，其中主服务器是旧服务器，从服务器是新服务器。然后，您可以让它花费尽可能多的时间来完成，完成后，您可以中断复制，取消将新实例配置为复制从属，并开始使用它来代替原始服务器。当您中断复制并切换应用程序使用的 MySQL 服务器时，这会将所需的停机时间限制在流程结束时的几分钟内。
答案2
在我的情况中，最终似乎有效的方法是禁用 bin 日志，如上所述这里。具体来说，我将参数组设置恢复正常，通过将保留时间重新设置为 0 来关闭 bin 日志，将 SQL 转储到文件中，然后简单地加载它mysql -C -u${target_user} -p${target_password} --host=${target_host} ${database} < ${filename}。
上面提到的所有监控现在都更加稳定了，写入 iops 稳定在 ~600，队列深度稳定在 ~10（bin log 当然为 0）。实际进程平均约为 1 MB/s，可能更快，但仍比我之前遇到的要快三倍左右——当然，我现在不会断开连接。