Azure Flexible MySQL服务器周期性中断连接的排查与预防方案咨询

一、排查Burstable实例CPU积分耗尽问题 #

你使用的Standard_B1Ms属于Burstable实例，这类实例依赖CPU积分提供计算能力，积分耗尽后会触发节流机制，直接导致服务器响应中断，1.5小时的周期刚好和积分耗尽的规律匹配：

• 登录Azure门户，查看服务器的CPU Credits Remaining和CPU Usage指标，确认连接中断时段是否出现积分耗尽、CPU被限制的情况。
• 若确认为积分问题，可选择：
  • 切换至General Purpose或Memory Optimized实例类型，这类实例无CPU积分限制，适配持续负载场景。
  • 保留Burstable实例的话，开启CPU Credit Boost功能，允许临时使用额外积分避免节流。

二、检查MySQL服务器核心配置 #

• 查看wait_timeout和interactive_timeout参数，默认值可能较短，若服务器处于节流状态会提前断开闲置连接，可调整为28800秒（8小时）左右。
• 结合Azure门户的Active Connections指标，检查max_connections参数是否达到上限，导致新连接无法建立。

三、优化NodeJS连接池配置 #

• 给连接池添加自动重连机制，以mysql2库为例，配置监听连接错误事件并触发重试：

  const pool = mysql.createPool({
    host: 'your-server.mysql.database.azure.com',
    user: 'your-user',
    password: 'your-password',
    database: 'your-db',
    connectionLimit: 10,
    waitForConnections: true,
    connectTimeout: 10000,
    idleTimeoutMillis: 300000
  });
  
  pool.on('error', (err) => {
    if (err.code === 'PROTOCOL_CONNECTION_LOST') {
      console.log('连接断开，触发重连');
      // 可在此重置连接池或发起新连接
    }
  });
  

• 确保程序在使用连接后调用connection.release()释放资源，避免连接池资源耗尽。

四、分析Azure服务器日志与状态 #

• 进入Azure门户MySQL服务器的Logs选项卡，查看error logs和slow query logs，定位连接中断时段的具体报错，排查是否存在服务器重启、权限异常或内部错误。
• 检查服务器的Restart History，确认连接中断时段是否发生自动重启（可能由补丁更新、资源调整触发）。

五、网络层面排查 #

• 确认客户端IP在Azure MySQL的Firewall rules列表中，避免临时被防火墙拦截。
• 若使用VNet集成，检查网络策略、路由规则是否有变更，导致连接通路中断。
• 使用Azure门户的Connection Checker工具，测试Azure内部到服务器的连接状态，排查公网波动问题。

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