上一篇navicat转储SQL文件报1577错误详解，找到了问题所在，但是强硬替代法显然不行，影响了其它数据库的正常运行。
- 马上将备份替换回去，回到报错1577的时候，这个时候只有mysql一个数据库的一个表有问题，不能因为这一个导致其它数据库都有问题，那就得不偿失了。
现在大概有两条路：
- 将现在数据备份，重新安装MySQL，再次导入备份的数据，这样略显麻烦，也不能保证所有的数据库都能完美成功导入。
- 再一个就是继续研究mysql文件夹中的文件及ibdata1这个文件，修复他们两个。
第一种方法显然没什么挑战性，还麻烦，最烦遇到问题动不动就重装的。目前来看，至少不算什么大问题，好歹phpmyadmin可以正常导入导出啊，起码其它数据库没有什么明显问题啊，所以走第二条路了。继续挑战看是否能完美解决。可能还是要跟mysql_upgrade打交道，毕竟navicat官方就是这么提示的。
替换文件后，检查了数据库情况，照样mysql数据库gtid_executed表提示1146错误，但是运行mysql_upgrade –upgrade-system-tables -uroot -p出现了变数，没再报错，而是其它的提示，如下图。为什么没有报错可能与替换文件后运行过upgrade，见上文最后的补充内容。
The --upgrade-system-tables option was used, databases won't be touched.
Checking if update is needed.
This installation of MySQL is already upgraded to 5.7.24, use --force if you still need to run mysql_upgrade继续了解mysql_upgrade命令及相关参数。
通过加入–force强制执行一下更新，虽然升级过程完成了，但有不少错误，包括之前的1146表不存在错误，结果如图。
查看了一下phpmyadmin中的mysql数据库中的gtid_executed表还是1146错误，可惜没有去navicat验证是否可以转储了。
（补充：到这里就已经可以转储了，下面已验证）
- 继续执行了不带–upgradesystem-tables的命令：mysql_upgrade -uroot -p
- 提示必须带参数–force：mysql_upgrade –force -uroot -p
- 更新过程还是有不少错误，见下图。
继续检查其它数据库，就不再截图了，偶尔也有一些错误，可能是以前的老数据兼容问题吧，具体的升级记录复制保存了一份，到时有需要再查看。
目前为止，navicat可以正常转储SQL文件了，1577错误没有了，可是mysql中表不存在还是不存在，上面提过，可惜第一步升级的时候没有验证是否可以转储了，要不然就不需要第二步了，步骤越少当然越安全了。要不然再还原回去，再来一遍？
说干就干吧
- 停止MySQL服务，因为数据库升级整个数据都已经动了，要还原回去必须整个欢迎，所以这里必须再次将现有情况的备份一下。
- 再把上一个完整备份替换掉现有的数据，因为我的备份只涉及到data数据目录，所以之前的升级操作可能已经无法回头了，这也是为什么之前升级报错，后面没有再报错的原因。
- 替换掉所有的文件后，重新启动MySQL服务
- 通过phpmyadmin及navicat查看是否有什么变化。
- phpmyadmin部分表提示1146，navicat转储报错1577，符合之前的情况。
- 执行命令mysql_upgrade –upgrade-system-tables -uroot -p
- 加入–force再次执行，与上面画红线的图提示一样。
- 现在重启一下MySQL服务，验证一下navicat转储情况。
- 果然可以了。
