翻译|节假日处理数据库集群异常小记( 二 ) 北京市|冬奥_奥运|冬奥_北京冬

经过测试和比对，发现中间件竟然连接不到数据节点，提示是密码错误，感觉就像数据库中间件和数据节点没有做任何配置一样。
mysql -uxxxx -pxxxx -hxxxx -P3309Warning: Using a password on the command line interface can be insecure.ERROR 1045 (28000): Access denied
这个测试情况让我大感吃惊，但是问题的方向已经基本明确了，所以和研发同学初步沟通了问题预计的处理策略和时间，就开始处理这个问题了，我逐个在数据节点的从库服务器端比对了数据库账号情况，发现这个账号的配置竟然在好几年前就失效了，通过数据库账号的配置发现原来的数据库账号只配置了读写中间件的IP ，但是没有只读中间件的IP 。
>>select userhost from mysql.user where user='root';+------+----------------+| user | host |+------+----------------+| xxxx| [中间件读写IP
|| xxxx| localhost |+------+----------------+6 rows in set (0.00 sec)
明白了这个大坑之后，我开始逐个配置数据库账号并逐一在中间件端进行了验证测试。

等待所有的数据节点都验证完毕之后，我重启中间件，只读中间件就好像唤醒了一般，反应很快，很酸爽。

对于这个问题的原因，让我还是很感慨，这算是一个遗忘了近3年的问题，这期间因为一直没有重启过只读中间件，所以原本指向的数据库配置其实是错误的，虽然后续做了配置文件的热加载，但是数据源部分的信息其实一直没有更新，今天因为业务使用了大查询导致了中间件节点OOM接着触发了高可用机制，自动重启了中间件，但是重启之后连接的数据库权限全部失效。
整个问题的处理过程还是比较快的，尤其是在一种半迷离的状态下逐步确定问题方向，让自己确认是数据库的配置和权限出了问题，这对于我来说着实是一种难以相信的事情，但是恰恰是这个问题，也暴露了很多潜在的风险和隐患。

由此可见，之前听过的一种简单粗暴的经验是有道理的：一个运行多年的服务在3年左右还是需要重启一下。