系统环境
centos7.5+mysql5.6.46
操作步骤
通过root用户在命令行创建业务用户时报error 1036 table ‘user’ is read only，能正常创建业务表、插入数据
问题排查
1、查看mysql数据目录下的user表是否被修改过
-rw-r----- 1 mysql mysql 10684 May 29 10:39 user.frm
-rw-r----- 1 mysql mysql 760 Jun 7 22:13 user.MYD
-rw-r----- 1 mysql mysql 2048 Jun 7 23:20 user.MYI
2、检查数据库是否有备份（逻辑备份和物理备份）
这里只有物理备份
3、通过strace命令跟踪是否有结果
strace -p mysql_pid -tt -T
这里和正常库对比后发现出问题的库在访问mysq.user表时，读取/etc/sysconfig/下的一个文件，但正常库上则没有该行读取命令，这里暂时没有获取到有用的信息
4、关闭数据库再重启
这里关闭数据库的过程中(mysqladmin方式)，后台日志显示正常关闭，但前端的mysqladmin一直处理hang状态，等了5-8分钟后，直接kill 掉mysqld进程，随后启动数据库，无法正常启动，也没有其他报信息，一时间无法下手
5、通过备份恢复数据
之前是通过innobackupex备份的，会保留最新三天的备份，但遗憾的事情，通过8月3号的备份恢复后数据依然无法启动，也没有报错信息，有点无从下手了。
说明：在恢复过程中，直接在原数据目录的基础上进行恢复的
接着删除了mysql的数据目录，通过8月2号的备份进行恢复，明天看看是否能正常启动？
总结
1、在数据库能正常读写业务表的情况下，物理备份和逻辑备份最好的都有
2、在没有确定具体问i题的情况下，不应该关闭重启数据库（当时想着有物理备份）
3、最好在异机进行恢复，阿里云ECS中恢复270GB的数据，需要2个多小时，恢复时间过后，应该增加备库
4、大粗心了，8月5号今天上午发现的问题，只是简单看了下之前的备份是否成功，但缺少了8月4号的备份，很明显8月4号就出问题了，不是应该关闭数据库（太S了）