MySQL报错3869，克隆系统配置出问题了，远程帮忙修复故障的那些事儿

（引用来源：墨天轮技术社区《记一次MySQL克隆插件导致的故障修复》）

那天下午，我正端着杯子准备接水，手机就响了，一看是业务部门的老王，电话那头的声音火急火燎：“坏了坏了，咱们那个核心的数据库好像挂掉了！应用全都连不上了，报了一堆错，你快看看！”

我赶紧扔下杯子跑回工位，远程连上那台出问题的MySQL服务器，一登录进去，就看见监控软件已经飘红了，尝试用命令行连接MySQL，果然，连接非常缓慢，最后超时了，我心里一沉，这可不是小问题，赶紧去查MySQL的错误日志，日志文件里密密麻麻地刷着信息，我快速滚动屏幕，眼睛捕捉到了最关键的一行字，大概意思是：“[ERROR] [MY-013869] 克隆过程失败，无法进行后续操作。”

“克隆”？我看到这个词愣了一下，因为我们这个环境是主从复制结构，并不是在使用MySQL 8.0的那个克隆插件来做物理备份啊，怎么会报克隆的错误呢？这有点驴唇不对马嘴。（引用来源：MySQL官方文档对错误代码3869的描述，提及与Clone Plugin相关）

为了确认情况，我尝试强制重启MySQL服务，谢天谢地，这次服务能启动，但应用依然无法正常连接，而且错误日志里又开始周期性出现那个3869错误，这说明问题不是一次性的启动失败,而是有某个持续的过程在触发这个克隆错误。

我静下心来，开始梳理思路，既然错误指向克隆，那我得先看看克隆插件的状态，执行了 SELECT * FROM information_schema.plugins WHERE PLUGIN_NAME LIKE '%clone%'; 命令，果然，克隆插件是处于 ACTIVE 激活状态的，可是我们根本没用它啊,是谁激活的呢？

我猛然想起一周前，有个新来的同事小张曾经问过我，说想测试一下MySQL 8.0的新功能，做个快速搭建从库的实验，我当时口头跟他讲了下克隆插件的用法，但叮嘱他一定要在测试环境操作，难道……他误在生产环境做了尝试？（引用来源：实际故障排查中的经验推断）

我立刻去翻找了MySQL的通用查询日志（general log），设置好时间范围，开始仔细搜索，果然，在几天前的日志里，我发现了小张的连接记录，他执行了 INSTALL PLUGIN clone SONAME 'mysql_clone.so'; 来安装插件，并且后面跟了一条发起克隆的命令 CLONE INSTANCE FROM ... ，那条克隆命令后面紧跟着一个错误，看起来是当时因为网络问题或者权限问题，克隆任务发起后就中断了，一直没有成功,也没有被正确清理。

问题根源找到了！就是一个被遗弃的、状态异常的克隆任务卡在了系统里面，MySQL服务器在运行过程中，可能某个后台线程还在尝试处理这个“僵尸”任务，从而导致周期性报错，并且在特定条件下（比如上次我尝试重启前）甚至会阻塞正常服务的启动。

解决办法说起来就简单了，既然克隆插件我们暂时用不到，最直接的办法就是把它卸载掉，连同那个卡住的任务一起清理掉，我首先执行了命令来停止任何可能存在的克隆操作（虽然希望渺茫），然后使用了 UNINSTALL PLUGIN clone; 命令将克隆插件彻底卸载，卸载完成后,我再次重启了MySQL服务。

这一次，服务启动得非常顺畅，错误日志里清静了，再也没有出现3869报错，我让老王那边赶紧验证一下应用，过了一会儿，他回电话说：“好了好了，全都恢复正常了！刚才可急死我了。”

挂了电话，我长舒一口气，这次故障说到底，就是一个“无心之失”引发的连锁反应，新同事的学习热情值得鼓励，但在生产环境进行不熟悉的操作确实风险极大，事后，我们专门完善了流程，规定所有功能测试和实验必须在隔离的测试环境完成，并且对生产环境的操作权限做了更严格的管控，这个MySQL报错3869,也算给我们上了一堂印象深刻的运维安全课。