前天收到用户反馈，部分地区打不开我们的应用，一开始检查猜测是机房网络、对全国各地的连通性不通。后来检查服务器，发现机房的网络对三大运营商的连通性不是三线直连，是单线电信的，所以联通和移动网络访问会出现丢包的问题。 接下来我们就开始迁移备用服务，因为是用的docker环境，所以迁移起来比较方便。 mysql的迁移是数据文件和库表结构文件直接拷贝到新服务器，挂载到同样配置的MySQL服务下。 数据迁移过来之后但此时服务器一直卡住，过段时间直接timeout，启动失败！看mysql日志，出现大量如下错误
InnoDB: Error: page 47 log sequence number 13576757483
InnoDB: is in the future! Current system log sequence number 8214.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
mysql_1 | information that should help you find out what is causing the crash.
This could be because you hit a bug. It is also possible that this binary
[ERROR] mysqld got signal 6 ;
期间 mysql 启动了一次然后就挂了，根据日志提示设置 innodb_force_recovery
[mysqld]
innodb_force_recovery = 1
innodb_force_recovery可以是设置1-6，数字大的包含数字小的功能
1.innodb_force_recovery=1，即使发现了损坏页面也继续让服务器继续运行，这个选项对于备份或者转存当前数据尤为有用
2.innodb_force_recovery=2，阻止恢复主线程的运行，如果清除操作会导致服务器挂掉
3.innodb_force_recovery=3，恢复后不回滚事务
4.innodb_force_recovery=4，如果插入到缓冲区的合并操作会导致系统崩溃，将不会被执行
5.innodb_force_recovery=5，启动数据库时，忽略撤消日志
6.innodb_force_recovery=6，启动数据库时，忽略与恢复相关的前滚日志
innodb_force_recovery 等于3等时候 mysql 可以打开了，根据文档上描述修复，关闭 innodb_force_recovery 后重启启动成功。
关于数据库迁移有hen在迁移之前有三种方案：
1.数据库直接导出，拷贝文件到新服务器，在新服务器上导入。
2.使用【MySQL GUI Tools】中的 MySQLMigrationTool。
3.数据文件和库表结构文件直接拷贝到新服务器，挂载到同样配置的MySQL服务下。
我选择的是第三种 迁移前关闭 mysql 服务，选择在凌晨进行迁移。因为数据量比较大，所以第三种迁移时间比较快，但是会出现像上面那种异常问题，如果数据量不大的话，可以用第二种或者第一种。