今天服務器受到DDOS攻擊，筆者腦殘重啟了一下服務器。結果造成MySQL服務器無法啟動 mysql日志見下圖。 160803 17:43:47 mysqld_safe Starting mysqld daemon with databases from /application/mysql/data
160803 17:43:47 [Note] /application/mysql/bin/mysqld (mysqld 5.5.49) starting as process 1975 ...
160803 17:43:47 [Warning] Using unique option prefix innodb_purge_thread instead of innodb-purge-threads is deprecated and will be removed in a future release. Please use the full name instead.
160803 17:43:47 [Note] Plugin 'FEDERATED' is disabled.
160803 17:43:47 InnoDB: The InnoDB memory heap is disabled
160803 17:43:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160803 17:43:47 InnoDB: Compressed tables use zlib 1.2.3
160803 17:43:47 InnoDB: Using Linux native AIO
160803 17:43:47 InnoDB: Initializing buffer pool, size = 64.0M
160803 17:43:47 InnoDB: Completed initialization of buffer pool
InnoDB: Error: auto-extending data file ./ibdata1 is of a different size
InnoDB: 7296 pages (rounded down to MB) than specified in the .cnf file:
InnoDB: initial 8192 pages, max 0 (relevant if non-zero) pages!
160803 17:43:47 InnoDB: Could not open or create data files.
160803 17:43:47 InnoDB: If you tried to add new data files, and it failed here,
160803 17:43:47 InnoDB: you should now edit innodb_data_file_path in my.cnf back
160803 17:43:47 InnoDB: to what it was, and remove the new ibdata files InnoDB created
160803 17:43:47 InnoDB: in this failed attempt. InnoDB only wrote those files full of
160803 17:43:47 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
160803 17:43:47 InnoDB: remove old data files which contain your precious data!
160803 17:43:47 [ERROR] Plugin 'InnoDB' init function returned error.
160803 17:43:47 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160803 17:43:47 [ERROR] Unknown/unsupported storage engine: InnoDB
160803 17:43:47 [ERROR] Aborting

160803 17:43:47 [Note] /application/mysql/bin/mysqld: Shutdown complete

160803 17:43:47 mysqld_safe mysqld from pid file /application/mysql/data/www.pid ended
實際圖片：

曾試過手動啟動

啟動命令為：mysqld_safe–defaults-file=/data/3306/my.cnf &

停止命令為：mysqladmin -u root -poldboy123 -S /data/3306/mysql.sockshutdown

---

但是發現一直提示沒有pid，百度了一下有一篇文章說需要刪除ib_logfile0和ib_logfile1兩個文件

就可以啟動，對這兩個文件進行了一下科普，如下：

文章

---

mysql的innodb中事務日志ib_logfile
事務日志或稱redo日志，在mysql中默認以ib_logfile0,ib_logfile1名稱存在,可以手工修改參數，調節
開啟幾組日志來服務于當前mysql數據庫,mysql采用順序，循環寫方式，每開啟一個事務時，
會把一些相關信息記錄事務日志中(記錄對數據文件數據修改的物理位置或叫做偏移量);
作用:在系統崩潰重啟時，作事務重做；在系統正常時，每次checkpoint時間點，會將之前寫入事務
應用到數據文件中。
引入一個問題：在m/s環境中,innodb寫完ib_logfile后,服務異常關閉，會不會主庫能用ib_logfile恢復數據，而
binlog沒寫導致從庫同步時少少這個事務？從而導致主從不一致;
redo日志寫入方式：
1.ib_logfile寫入當前事務更新數據，并標上事務準備trx_prepare
2.寫入bin-log
3.ib_logfile當前事務提交提交trx_commit
恢復方式:
如果ib_logfile已經寫入事務準備,那么在恢復過程中，會依據bin-log中該事務是否存在恢復數據。
假設:
1）結束后異常,因沒有寫入bin-log，從庫不會同步這個事務，主庫上，重啟時，在恢復日志中這個
事務沒有commit，即rollback這個事務.
2）結束后異常，這會bin-log已經寫入，從庫會同步這個事務。主庫依據恢復日志和bin-log，也正?；謴痛耸聞?br style="" /> 綜上描述:bin-log寫入完成，主從會正常完成事務；bin-log沒有寫入，主從庫rollback事務;不會出現主從庫不一致問題.
相關參數（全局&靜態）:
innodb_log_buffer_size
innodb_log_file_size
innodb_log_files_in_group
innodb_log_group_home_dir
innodb_flush_log_at_trx_commit
innodb_log_buffer_size:事務日志緩存區,可設置1M~8M,默認8M,延遲事務日志寫入磁盤,
把事務日志緩存區想象形如”漏斗”狀,會不停向磁盤記錄緩存的日志記錄,而何時寫入通過參數
innodb_flush_log_at_trx_commit控制,稍后解釋,啟用大的事務日志緩存,可以將完整運行大事
務日志，暫時存放在事務緩存區中,不必(事務提交前)寫入磁盤保存,同時也起到節約磁盤空間占用;
innodb_log_file_size:控制事務日志ib_logfile的大小,范圍5MB~4G；所有事務日志ib_logfile0+
ib_logfile1+..累加大小不能超過4G，事務日志大，checkpoint會少,節省磁盤IO，但是大的事務日
志意味著數據庫crash時，恢復起來較慢.
引入問題:修改該參數大小，導致ib_logfile文件的大小和之前存在的文件大小不匹配
解決方式：在干凈關閉數據庫情況下，刪除ib_logfile，而后重啟數據庫，會自行創建該文件;
innodb_log_files_in_group:DB中設置幾組事務日志，默認是2；
innodb_log_group_home_dir:事務日志存放目錄，不設置，ib_logfile0…存在在數據文件目錄下
innodb_flush_log_at_trx_commit：控制事務日志何時寫盤和刷盤，安全遞增：0,2,1
事務緩存區:log_buffer;
0:每秒一次事務緩存區刷新到文件系統，同時文件系統到磁盤同步，但是事務提交時，不會觸發log_buffer到文件系統同步；
2:每次事務提交時,會把事務緩存區日志刷新到文件系統中去，且每秒文件系統到磁盤同步;
1:每次事務提交時刷新到磁盤，最安全;
適用環境:
0:磁盤IO能力有限,安全方便較差,無復制或復制延遲可以接受，如日志性業務，mysql損壞丟失1s事務數據;
2:數據安全性有要求，可以丟失一點事務日志，復制延遲也可以接受，OS損壞時才可能丟失數據;
1:數據安全性要求非常高，且磁盤IO能力足夠支持業務，如充值消費，敏感業務; 文章地址

---

由于經費原因，沒有做CDN，所以扛不住DDOS攻擊實屬正常 下圖是阿里云發監控： 網站流量監控 小結：? 防治DDOS的前提是必須要做好監控！ 另外在受到攻擊，重啟服務器是沒有作用的，在實際生產環境是不可以重啟的。這點大家一定要冷靜！

---

由于作者手殘不小心rm -rf ib* 因為表示Innbodb表，所以導致所有數據全都被刪除（已經哭暈在廁所） ?跟我一起忘記rm 命令把！！！！！！！！ ibdata用來儲存文件的數據
而庫名的文件夾里面的那些表文件只是結構而已

---

對于DDOS防范可以參考下面文章： 網站DDOS攻擊防護實戰老男孩經驗心得分享 625某電商網站數據庫宕機故障解決實錄 http://oldboy.blog.51cto.com/2561410/1431161 http://oldboy.blog.51cto.com/2561410/1431172 關于MySQL引擎[innodb文章] http://www.abcdocker.com/abcdocker/77

總結

以上是生活随笔為你收集整理的服务器重启导致无法启动MySQL的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。