MySQL报错MY-013355，LDAP映射空格问题导致故障，远程帮忙修复思路分享

直接提供“MySQL报错MY-013355，LDAP映射空格问题导致故障，远程帮忙修复思路分享”的内容如下：

这个事是前几天一个朋友在线上环境遇到的，他们公司的MySQL数据库突然有一批应用连不上了，报的错误代码就是MY-013355，当时他急得不行，在线上找我远程帮忙看看，这个错误信息，根据MySQL官方文档的解释，是和LDAP（轻量级目录访问协议）认证插件相关的，就是数据库用外部的LDAP服务（比如公司的统一账号系统）来验证登录用户的时候,出了岔子。

具体到他们这个情况，错误日志里除了代码，还明确提到了“mapping”和“parse”这类关键词，我们一开始以为是LDAP服务器那边出了问题，或者网络不通，但检查了一圈，LDAP服务是好的，网络也是通的，后来，我们仔细对比了能正常登录和不能登录的账号，发现了一个特别不起眼的区别：有几个不能登录的账号，他们在LDAP目录里的“角色名”或者“组名”里面，包含空格，正常的是“DB_Users”，而有问题的是“DB Users”（中间有个空格）。

问题就出在这里，根据MySQL官方手册里关于LDAP认证插件的说明，以及一些社区案例的分享（比如Percona的技术博客里讨论过类似场景），MySQL的LDAP插件在配置时，有一个环节叫“映射”（mapping），这个映射规则，通常是在MySQL的配置文件（如my.cnf）或者创建用户时的IDENTIFIED WITH语句里设定的，它的作用是把LDAP目录里的组（group）或者属性（attribute）,映射成MySQL数据库内部的权限角色。

朋友他们的配置里，映射规则大概是这样写的：'cn=DB Users,ou=groups,dc=company,dc=com'，问题就在于，这个字符串里的“DB Users”中间的空格，在插件解析（parse）的时候，没有被正确地当作整个字符串的一部分来处理，插件可能错误地认为空格是一个分隔符，或者由于引号处理不当，导致它只认“DB”而忽略了后面的“Users”，这样一来，当用户登录时，插件去LDAP服务器核对，虽然用户确实属于“DB Users”这个组，但因为插件解析映射规则时“看错了”，就认为用户不属于任何有权限的组，于是认证失败，抛出了MY-013355错误。

远程帮忙修复的思路，其实核心就是如何让MySQL的LDAP插件正确地“读懂”带空格的组名,我们当时是分了几步走的：

1. 确认并复现问题：我让他从错误日志里精确定位报错的用户和时间点，专门用一个属于“DB Users”这类带空格组名的测试账号去连接，百分百复现了MY-013355错误，而用属于“DB_Users”（无空格）组名的账号登录就正常,这锁定了空格就是罪魁祸首。

2. 检查并修正映射规则格式：这是最关键的一步，我们重点检查了MySQL配置中所有涉及LDAP映射的地方，根据MySQL官方文档的提示和社区经验，对于包含特殊字符（如空格、逗号）的DN（识别名），必须确保整个映射字符串被正确引号包裹，原来他们的配置里，引号的使用可能不完整或者有歧义，我们将其统一修改为使用反引号（`） 或者单引号（‘） 将整个组DN严格地括起来，确保写成 `cn=DB Users,ou=groups,dc=company,dc=com` 这种格式，修改配置后，重启了MySQL的LDAP插件相关组件（注意：不是重启整个数据库，通常可以用UNINSTALL PLUGIN和INSTALL PLUGIN命令重新加载插件，或者重启mysqld服务）。

3. 测试与验证：配置修改完成后，立刻让朋友用之前失败的测试账号进行连接测试，当时很紧张，因为是在线上环境操作，幸运的是，修改后测试账号成功登录，应用连接也恢复了，为了保险起见，还测试了其他不带空格的组映射,确认修改没有影响原有正常的功能。

4. 后续建议：问题解决后，我给他提了个醒，第一，以后在LDAP目录里规划组名或角色名时，尽量避免使用空格、逗号这些在DN里具有特殊含义的字符，可以用下划线或连字符代替，第二，所有涉及到外部系统集成的配置项，像这种映射规则，写的时候一定要严格按照规范，该加引号的地方不能省,并且最好先在测试环境进行充分验证。

整个远程帮忙的过程，大概持续了一个多小时，大部分时间花在排查和确认细节上，核心的修复动作其实就是调整映射规则的引号使用，让插件能完整地识别出“DB Users”这个整体字符串，这件事也说明，有时候最让人头疼的故障,原因往往就藏在一个看似微不足道的空格或者标点符号里。