使用Azure数据库在线迁移服务时遇到连接错误

• 源库连接资源不足：本地MySQL的max_connections设置过低，或是针对迁移服务的IP做了连接数限制，迁移大表时占满可用连接，后续连接请求被拒绝，最终连接池里的8个连接全部失效且无法重建。
• 连接超时被主动断开：大表迁移时单条数据传输或查询耗时过长，触发了MySQL的wait_timeout或interactive_timeout设置，服务器主动断开闲置/超时连接，连接池中的连接全部变成无效状态。
• 网络链路不稳定：源端到Azure的网络存在丢包、高延迟，导致连接频繁中断，连接池来不及重建有效连接，最终全池失效。
• 源库资源耗尽：大表迁移占用过多CPU、内存或磁盘IO，MySQL服务器无法响应新的连接请求，连接池里的连接因超时被标记为失效。
• 迁移服务连接池机制限制：Azure迁移服务的连接池固定为8个，若大表迁移过程中每个连接都因异常断开且无法自动重建，就会出现全池无有效连接的情况。

• 检查连接相关配置：执行SHOW VARIABLES LIKE '%connection%';，重点看max_connections、wait_timeout、interactive_timeout，确认是否存在连接数上限太低或超时时间过短的问题。
• 实时监控连接状态：执行SHOW PROCESSLIST;或SELECT * FROM information_schema.processlist;，查看迁移服务IP对应的连接状态，是否有大量Sleep/Error状态的连接，或是已经达到max_connections上限。
• 排查资源占用：用SHOW GLOBAL STATUS LIKE 'Threads_%';查看线程运行状态，同时通过操作系统的top、iostat工具监控CPU、内存、磁盘IO的使用率，确认是不是资源耗尽导致无法处理连接请求。
• 查看错误日志：找到源MySQL的错误日志路径（通常是/var/log/mysql/error.log，或自定义路径），搜索连接断开、资源不足相关的报错信息。
• 手动测试连接：从和迁移服务同网络的环境，用mysql -h xx.xxx.xx.43 -u 用户名 -p手动连接源库，保持连接一段时间，看是否会出现自动断开的情况，排查网络稳定性。

• 检查连接数限制：在Azure门户查看MySQL服务器的SKU对应的连接数上限，通过Azure监控的“连接数”指标查看实时连接情况，确认是否达到上限。
• 查看诊断日志：启用并查看Azure MySQL的慢查询日志、错误日志，排查是否有来自源端的连接被拒绝、超时等记录。
• 监控网络指标：在Azure门户查看MySQL服务器的“网络延迟”“入站流量”指标，确认是否存在网络异常导致连接中断。
• 调整迁移配置：尝试在Azure迁移服务中降低大表迁移的并行度，减少单批次的连接占用；如果有连接超时设置选项，适当延长超时时间。
• 反向连通性测试：在Azure MySQL所在的VNet中创建虚拟机，从虚拟机连接源数据库，测试网络连通性和稳定性。

内容的提问来源于stack exchange，提问作者Erika