MySQL报错MY-011749，LDAP连接池初始化中断导致故障远程修复思路分享

（引用来源：某互联网公司内部数据库团队故障复盘报告及工程师个人工作笔记）

那次遇到MY-011749错误的情况还挺紧急的，当时是晚上，业务部门突然反馈说一个核心的认证服务挂了，日志里全是数据库连接失败的错误，我们远程登录到那台MySQL服务器上，查看错误日志，立刻就看到了这个MY-011749的报错信息，错误信息大致是说，在启动或者运行过程中，LDAP认证插件尝试初始化连接池失败了，导致整个插件无法正常工作，因为我们的用户认证是配置了使用LDAP的，所以MySQL虽然进程还在，但任何需要认证的连接请求，包括我们运维人员的日常管理连接，都因为这个插件初始化失败而被拒绝了，相当于数据库“半瘫痪”了。

（引用来源：MySQL官方文档关于“LDAP Authentication Plugins”的章节及错误代码说明）

我们得搞清楚MY-011749这个错误到底是什么意思，根据MySQL的官方文档描述，这个错误通常与LDAP可插拔认证相关，当MySQL服务器启动或运行时，如果配置了LDAP认证（比如authentication_ldap_simple或authentication_ldap_sasl插件），它会尝试初始化一个到指定LDAP服务器的连接池，这个初始化过程包括建立初始连接、进行绑定（登录）验证配置的账户密码是否有效等步骤，如果在这个过程中任何一环出了问题，比如网络不通、LDAP服务器没响应、账号密码错误、证书问题（如果用了SSL），初始化就会中断，并抛出MY-011749错误，插件初始化失败是致命性的,会导致依赖该插件的认证功能完全失效。

（引用来源：团队内部远程故障处理SOP及当时线上操作记录）

当时的情况是，我们无法通过常规的MySQL命令行客户端直接连接上去修改配置，因为认证链路本身已经断了，所以第一步是想办法“绕开”这个出问题的认证插件，获得一个可以执行命令的数据库会话,我们采取了以下紧急恢复步骤：

1. 启用本地免密登录（--skip-grant-tables）： 这是最关键的一步，我们通过远程管理卡（iDRAC/iLO）或者让机房现场同事协助，重启了MySQL服务器，在启动命令中临时增加了 --skip-grant-tables 参数，这个参数会让MySQL服务器启动时不加载权限系统，所有用户都可以无需密码直接连接，这样就绕过了LDAP认证插件，我们用mysql客户端直接连了上去,拿到了系统控制权。

2. 排查LDAP连接池初始化失败的根本原因： 连上数据库后，我们并没有急于修改配置，而是先查看MySQL的错误日志，寻找更详细的线索，MY-011749是一个总括性的错误，日志里通常会有更具体的上游错误信息，我们当时看到的详细错误是“Failed to connect to LDAP server: Connection timed out”,这立刻把问题指向了网络或LDAP服务器本身。

3. 多维度验证LDAP服务状态：

   • 网络连通性： 我们从MySQL服务器上使用ping和telnet（到LDAP服务器的端口，默认389或636）命令，确认了到LDAP服务器的网络连接确实超时,根本不通。
   • LDAP服务器状态： 立即联系了负责LDAP基础设施的团队，果然，他们那边正在进行一次计划内的网络设备割接，导致我们这台MySQL服务器所在的网段到LDAP服务器集群的访问路由出现了问题，这是一个跨团队的协调失误,我们事先没有接到通知。

4. 制定并执行修复方案：

   • 短期方案（立即执行）： 既然LDAP服务暂时不可用，而业务又需要尽快恢复，我们决定临时修改MySQL的认证方式，在--skip-grant-tables模式下，我们更新了系统表mysql.user中相关用户的plugin字段，将其从authentication_ldap_simple暂时改为mysql_native_password（本地密码认证），并为这些用户设置了一个临时的强密码，我们去掉了--skip-grant-tables参数，正常重启MySQL，重启后，应用使用临时密码成功连接,业务迅速恢复。
   • 长期方案（根本解决）： 与网络和LDAP团队协作，跟踪他们修复网络路由的进度，路由恢复后，我们在业务低峰期，再次将用户认证方式从mysql_native_password改回authentication_ldap_simple，并清理了临时密码，推动建立了跨部门的基础设施变更通告机制,避免类似问题再次发生。

（引用来源：工程师事后总结的经验教训）

这次远程修复MY-011749故障给我们的启示很深。依赖外部认证服务（如LDAP）虽然方便管理，但也引入了单点故障风险，数据库的可用性会受到LDAP服务可用性的直接影响。清晰的日志记录至关重要，如果没有详细的子错误信息（Connection timed out），我们的排查会像无头苍蝇，耗时会更长。要有应急预案，像使用--skip-grant-tables这种“后门”方法，虽然不推荐常规使用，但在紧急情况下是挽救业务的救命稻草，每个DBA都应该熟知其风险和用法，这次故障也促使我们后续考虑在一些极端场景下，为关键数据库账户配置双认证插件（LDAP+本地密码）作为备份方案，虽然这会增加一些管理复杂度,但能有效降低类似风险。

（引用来源：同上）

处理MY-011749错误，核心思路是：第一，通过非常规手段（如--skip-grant-tables）获得数据库访问权；第二，仔细阅读错误日志，定位是网络、LDAP服务、证书还是配置问题；第三，根据根本原因，协调相关团队解决；第四，如需快速恢复业务，可临时切换认证方式；故障恢复后一定要进行复盘，完善监控和流程,防止重蹈覆辙。