flush privileges引起的mysql root用户无法登录

昨晚同事急急忙忙过来说生产环境一个实例（slave）root用户进不去了，询问得知这一切都源于flush privileges

Reloads the privileges from the grant tables in the mysql database. On Unix, this also occurs if the server receives aSIGHUP signal.The server caches information in memory as a result of GRANT, CREATE USER, CREATE SERVER, and INSTALL PLUGIN statements. This memory is not released by the corresponding REVOKE, DROP USER, DROP SERVER, and UNINSTALL PLUGIN statements, so for a server that executes many instances of the statements that cause caching, there will be an increase in memory use. This cached memory can be freed with FLUSH PRIVILEGES.

第一步：先检查其他业务账号是否正常，因为root不是业务账号不对外提供服务，业务账号一切OK

第二步：开始分析，flush privileges原理如上所示，于是怀疑cache与grant tables信息不一致

第三步：因为问题实例是slave，将外部应用读访问切换到master，通过对slave两次重启将root用户密码初始化

(1)关闭实例，一机多实例、处理故障情况下要格外小心，以免错上加错

mysqladmin -uuser -ppassword shutdown  #如果有shutdown权限账号

kill pid_mysqld  #如果没有shutdown权限账号

(2)启动无需权限验证的mysqld

my.cnf中[mysqld]作用域中添加一行  skip-grant-tables

或在启动mysqld时以参数形式指定   --skip-grant-tables

mysqld --skip-grant-tables &

(3)初始化root用户密码

USE MySQL ;UPDATE user SET Password = password('new-password') WHERE User = 'root' ; flush privileges ;

(4)关闭实例

mysqladmin -uroot -ppassword shutdown

(5)正常启动mysqld

mysqld  &

至此slave的问题解决了，但是还有个潜在的风险，master上没有执行 flush privileges，一旦root密码丢失要用上述两次重启来解决代价和影响很大，然后仔细询问这个实例由来，原来是用mysqldump在另一套环境中将整个实例备份后恢复到今天出问题的master和slave上的，这时候真相大白，全实例备份自然包含mysql数据库，恢复中会先drop grant table，再重建初始化数据，而两个环境的root用户密码不同且同事不清楚，所以走了很多弯路，对于运维工作来说环境不规范带来的风险和工作量是无法估量，这次故障解决是半路介入的，没有掌握全部信息，年后回来故障应急处理能力下降不少，看来还需要多些故障练手！