后续的第一波补救措施如下：
8）使用已有的凌晨固定的物理备份恢复数据，大约为1个小时，mysqldump恢复果断放弃，印象中至少得6个小时以上。
9）使用物理备份模式备份当前数据库
10）重新升级数据库，尤其注意ibdata的配置，如果升级失败则使用物理备份快速回退
11）升级过程再次受阻，这一次是sql_mode，系统数据字典升级成功，但是数据库的表检测中，主要因为sql_mode的数据格式校验，导致很多数据表的格式校验失败，需要执行类似 alter table test.xxxxx force这样的重构操作。
12）因为恢复过程中未知原因，InnoDB的redo log也受到一些影响，日志开始抛错，所以当前恢复的数据库就算升级字典成功，本身也有一些硬伤。
后续的第二波补救措施如下：
13）使用mysqldump备份当前数据库，仅仅备份指定的数据库，不使用all-databases选项，权限单独导出。
14）部署MySQL 5.7的实例，不同的端口，如4390端口
15）sql_mode和5.5版本通配，修改其他参数等
16）导入mysqldump数据至4390的5.7实例
17）建立主从复制关系
18）切换数据库端口，使5.7的新版本服务生效
整个过程也是一波多折，见招拆招，发现想走捷径，最后发现一个坑都没有拉下，而这也给了我深刻的教训，千万不能掉以轻心，不能带着试运气的态度处理问题。
关于嵌入式技术就介绍完了，您有什么想法可以联系小编。