[問題現象]

伺服器在執行過程中，因人為意外導致電源被拔，伺服器宕機，mysql重啟不成功，報錯如下

根據提示，輸入systemctl status mysql.service和journalctl -xe檢視日誌，經過一番百度谷歌折騰也是無果。（很多時候，不能因為突發事件就“病急亂投醫”）

最後在mysql 的日誌處看到了報錯日誌

如果centos是通過yum安裝的mysql，那麼日誌一般在/var/log/mysql.log

檢視到日誌

2018-11-29T08:39:18.977374Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2018-11-29T08:39:18.978051Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.22) starting as process 11192 ...
2018-11-29T08:39:18.979893Z 0 [Note] InnoDB: PUNCH HOLE support available
2018-11-29T08:39:18.979910Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-11-29T08:39:18.979914Z 0 [Note] InnoDB: Uses event mutexes
2018-11-29T08:39:18.979916Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2018-11-29T08:39:18.979918Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-11-29T08:39:18.979920Z 0 [Note] InnoDB: Using Linux native AIO
2018-11-29T08:39:18.980073Z 0 [Note] InnoDB: Number of pools: 1
2018-11-29T08:39:18.980135Z 0 [Note] InnoDB: Using CPU crc32 instructions
2018-11-29T08:39:18.981011Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2018-11-29T08:39:18.985294Z 0 [Note] InnoDB: Completed initialization of buffer pool
2018-11-29T08:39:18.986268Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2018-11-29T08:39:18.997726Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2018-11-29T08:39:18.998629Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 23732273189
2018-11-29T08:39:18.998641Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 23732273507
2018-11-29T08:39:18.998881Z 0 [Note] InnoDB: Database was not shutdown normally!
2018-11-29T08:39:18.998887Z 0 [Note] InnoDB: Starting crash recovery.
2018-11-29T08:39:19.110899Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2018-11-29T08:39:19.110915Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2018-11-29T08:39:19.110957Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2018-11-29T08:39:19.149162Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2018-11-29T08:39:19.149810Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2018-11-29T08:39:19.149818Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2018-11-29T08:39:19.150158Z 0 [Note] InnoDB: Waiting for purge to start
2018-11-29 16:39:19 0x7f1219ffb700  InnoDB: Assertion failure in thread 139715722327808 in file fut0lst.ic line 85
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
08:39:19 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
 

通過搜尋

InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA

 瞭解到，大部分都是因為伺服器在資料庫沒用停止服務的情況下宕機，導致資料丟失

解決方法有倆個：

1、如果是大佬，則繼續深入踩坑研究，運氣好能在google查到相似問題解決方案（反正我是沒查到

2、直接備份資料庫，然後初始化資料庫後進行恢復資料

[問題原因]

伺服器宕機導致innodb的資料和實際資料庫的資料不一致，在啟動的時候就報錯了

[解決方法]

1. Forcing InnoDB Recovery

在 /etc/my.cnf中新增如下配置：

[mysqld]
innodb_force_recovery = 1

其中後面的值設定為1、如果1不能啟動成功，再逐步增加為2/3/4等。直到能啟動mysql為止！！！

重啟成功後，測試資料庫是否可以正常連線：

mysql -u root -p 123456

能連進去的話就exit退出

2.資料備份

找一個自己找得到的目錄做資料備份

mysqldump -u root -p 123456 --all-databases > all_mysql_backup.sql
 

3.初始化資料庫

mysqld --initialize
啟動資料庫
service mysqld start

如果報錯，則顯得去刪除mysql的data目錄

這裡的data目錄實際就是你資料庫存放的目錄，比如知道的/var/lib/mysql

4.資料恢復

登入資料庫

mysql -u root -p 123456

恢復

source /備份目錄/all_mysql_backup.sql