MySql：在具有大量資源的伺服器上頻繁崩潰
我的 MySQL 伺服器在 Ubuntu 16.x 上執行最新版本的 MySql，每天會崩潰一次或兩次。有時它會很快自我修復（10 分鐘）。有時我必須重新啟動並執行 fsck 才能讓事情再次執行。
什麼會導致這種情況？
到目前為止我嘗試過的事情：
- 將 RAM 從 1.5GB 增加到 5GB。
- 硬體升級：主機板、處理器、RAM (DDR4)，但這並沒有幫助（它執行了 7 年的處理器，現在執行的是第 7 代 Core I5）。
- 設置 UFW 防火牆以確保它不是由攻擊 MySQL 或其他服務的機器人引起的。
- 在 my.cnf 中，將 innodb_buffer_pool_size 從 128MB 更改為 500MB。沒有幫助，但仍然在原地
- 我已經執行了： mysqlcheck -u root -p –auto-repair –optimize –all-databases 多次。沒有幫助
- 在 my.cnf 中，將 mysql max_connections 從 151 減少到 80 並重新啟動 mysql。沒有幫助
- 將 apache MaxRequestWorkers 從 150 減少到 100。沒有幫助。還在崩潰。
- 我已經有一個 1GB 的交換文件。留下它。
- 通過 Apache2 日誌、SysLog 以及任何其他看起來合適但沒有發現任何引起我注意的日誌。
- 關閉伺服器並嘗試將 VM 移動到另一個驅動器，但失敗並顯示文件錯誤。
- 我最近的懷疑是這是由壞塊引起的，但執行壞塊似乎會在完成 25% 時觸發崩潰。在 fsck 期間，我看到：fsck 關鍵介質錯誤，dev sda，扇區 147306432
這是一個典型的mysql錯誤日誌：
2017-04-20T18:43:46.958430Z 0
$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 11791ms。設置可能不是最佳的。（流感棚=92，驅逐=0，在此期間。）
2017-04-20T18：44：11.989905Z 0$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 6822ms。設置可能不是最佳的。（在此期間，flushed=8 和 evicted=0。）
2017-04-20T18:44:49.145162Z 0$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 5021ms。設置可能不是最佳的。（在此期間，flus hed=0 和 evicted=0。）
2017-04-20T18:45:22.322429Z 0$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 26338ms。設置可能不是最佳的。（流感棚=10，驅逐=0，在此期間。）
2017-04-20T18：45：53.926808Z 0$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 4510ms。設置可能不是最佳的。（在此期間，flus hed=0 和 evicted=0。）
2017-04-20T18:46:03.097400Z 0$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 5384ms。設置可能不是最佳的。（在此期間，flus hed=13 和 evicted=0。）
2017-04-20T18:46:39.247467Z 0$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 14848ms。設置可能不是最佳的。（流感棚=8，驅逐=0，在此期間。）
2017-04-20T18：47：16.271672Z 0$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 29107ms。設置可能不是最佳的。（流感棚=8，驅逐=0，在此期間。）
2017-04-20T18：47：53.669557Z 0$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 5969ms。設置可能不是最佳的。（在此期間，flus hed=37 和 evicted=0。）
2017-04-20T18:50:23.879411Z 0$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 37671ms。設置可能不是最佳的。（流感棚=6，驅逐=0，在此期間。）
2017-04-20T18：55：07.190725Z 0$$ Warning $$更改限制：max_open_files：1024（請求 5000）2017-04-20T18:55:07.235759Z 0$$ Warning $$更改限制：table_open_cache：431（請求 2000）
2017-04-20T18:55:10.486670Z 0$$ Warning $$不推薦使用帶有隱式 DEFAULT 值的 TIMESTAMP。請使用 –explicit_defaults_for_times tamp 伺服器選項（有關詳細資訊，請參閱文件）。
2017-04-20T18:55:11.563578Z 0$$ Note $$/usr/sbin/mysqld (mysqld 5.7.17-0ubuntu0.16.04.2) 從程序 24701 開始 …
2017-04-20T18:55:21.979225Z 0$$ Note $$InnoDB：提供打孔支持
2017-04-20T18:55:21.979250Z 0$$ Note $$InnoDB：互斥鎖和 rw_locks 使用 GCC atomic builtins
2017-04-20T18:55:21.979253Z 0$$ Note $$InnoDB：使用事件互斥鎖 2017-04-20T18:55:21.979256Z 0$$ Note $$InnoDB：GCC 內置 __atomic_thread_fence() 用於記憶體屏障
2017-04-20T18:55:21.979259Z 0$$ Note $$InnoDB：壓縮表使用 zlib 1.2.8
2017-04-20T18:55:21.979262Z 0$$ Note $$InnoDB：使用 Linux 原生 AIO 2017-04-20T18:55:22.004800Z 0$$ Note $$InnoDB：池數：1
2017-04-20T18:55:22.060762Z 0$$ Note $$InnoDB：使用 CPU crc32 指令
2017-04-20T18:55:22.104584Z 0$$ Note $$InnoDB：初始化緩衝池，總大小 = 128M，實例 = 1，塊大小 = 128M
2017-04-20T18:55:24.184701Z 0$$ Note $$InnoDB：緩衝池初始化完成
2017-04-20T18:55:24.210160Z 0$$ Note $$InnoDB：如果 mysqld 執行使用者被授權，可以更改頁面清理執行緒優先級。請參閱 setpriority() 的手冊頁。
2017-04-20T18:55:26.405242Z 0$$ Note $$InnoDB：支持的最高文件格式是梭子魚。
2017-04-20T18:55:27.508456Z 0$$ Note $$InnoDB：日誌掃描通過檢查點 lsn 35288448161
2017-04-20T18:55:27.508478Z 0$$ Note $$InnoDB：進行恢復：掃描到日誌序列號 35288448170
2017-04-20T18:55:27.508630Z 0$$ Note $$InnoDB：進行恢復：掃描到日誌序列號 35288448170
2017-04-20T18:55:27.508634Z 0$$ Note $$InnoDB：數據庫未正常關閉！
2017-04-20T18:55:27.508637Z 0$$ Note $$InnoDB：開始崩潰恢復。
2017-04-20T18:56:16.516761Z 0$$ Note $$InnoDB：刪除臨時表空間數據文件：“ibtmp1”
2017-04-20T18:56:16.516785Z 0$$ Note $$InnoDB：為臨時表創建共享表空間
2017-04-20T18:56:16.516817Z 0$$ Note $$InnoDB：將文件 ‘./ibtmp1’ 大小設置為 12 MB。物理上將文件寫滿；請稍候…
2017-04-20T18:56:16.621736Z 0$$ Note $$InnoDB：文件 ‘./ibtmp1’ 大小現在為 12 MB。
2017-04-20T18:56:16.622203Z 0$$ Note $$InnoDB：找到 96 個重做回滾段。96 個重做回滾段處於活動狀態。
2017-04-20T18:56:16.622211Z 0$$ Note $$InnoDB：32 個非重做回滾段處於活動狀態。
2017-04-20T18:56:16.622565Z 0$$ Note $$InnoDB：等待清除開始
2017-04-20T18:56:16.672708Z 0$$ Note $$InnoDB：5.7.17 開始；日誌序列號 35288448170
2017-04-20T18:56:16.672708Z 0$$ Note $$InnoDB: page_cleaner: 1000ms 預期循環耗時 52462ms。設置可能不是最佳的。（在此期間，flushed=0 和 evicted=0。）
2017-04-20T18:56:16.673192Z 0$$ Note $$InnoDB：從 /var/lib/mysql/ib_buffer_pool
2017-04-20T18:56:16.702959Z 0載入緩衝池$$ Note $$外掛 ‘FEDERATED’ 已禁用。
2017-04-20T18:56:16.851553Z 0$$ ERROR $$功能“存檔”已經存在
2017-04-20T18:56:16.851568Z 0$$ Warning $$無法使用 soname ‘ha_archive.so’ 載入名為 ‘archive’ 的外掛。
2017-04-20T18:56:16.851574Z 0$$ ERROR $$功能“黑洞”已經存在
2017-04-20T18:56:16.851575Z 0$$ Warning $$無法使用 soname ‘ha_blackhole.so’ 載入名為 ‘blackhole’ 的外掛。
2017-04-20T18:56:16.851578Z 0$$ ERROR $$功能“聯合”已經退出 2017-04-20T18:56:16.851579Z 0$$ Warning $$無法使用 soname ‘ha_federated.so’ 載入名為 ‘federated’ 的外掛。
2017-04-20T18:56:16.851582Z 0$$ ERROR $$功能“innodb”已經存在 2017-04-20T18:56:16.851583Z 0$$ Warning $$無法使用 soname ‘ha_innodb.so’ 載入名為 ‘innodb’ 的外掛。
2017-04-20T18:56:17.044733Z 0$$ Warning $$由於以下 SSL 庫錯誤而無法設置 SSL：SSL 上下文在沒有證書和私鑰的情況下不可用
2017-04-20T18:56:17.044754Z 0$$ Note $$伺服器主機名（綁定地址）：‘0.0.0.0’；埠：3306
2017-04-20T18:56:17.044761Z 0$$ Note $$- “0.0.0.0”解析為“0.0.0.0”；
2017-04-20T18:56:17.044779Z 0$$ Note $$在 IP 上創建的伺服器套接字：‘0.0.0.0’。2017-04-20T18:56:18.483575Z 0$$ Note $$事件調度程序：載入 0 個事件
2017-04-20T18:56:18.483706Z 0$$ Note $$執行 ‘SELECT * FROM INFORMATION_SCHEMA.TABLES;’ 使用已棄用的分區引擎獲取表列表。您可以使用啟動選項“–disable-partition-engine-check”跳過此檢查。
2017-04-20T18:56:18.483716Z 0$$ Note $$非本地分區表列表的開頭
2017-04-20T18:56:25.478293Z 0$$ Note $$InnoDB：緩衝池載入完成於 170420 13:56:25
2017-04-20T18:56:26.091240Z 0$$ Note $$非本地分區表列表結束
2017-04-20T18:56:26.091423Z 0$$ Note $$/usr/sbin/mysqld：準備連接。版本：‘5.7.17-0ubuntu0.16.04.2’ 套接字：’/var/run/mysqld/mysqld.sock’ 埠：3306 (Ubuntu)
2017-04-20T18:56:26.155810Z 4$$ ERROR $$/usr/sbin/mysqld：表 ‘./example/wp_options’ 被標記為崩潰，應該修復
2017-04-20T18:56:26.155889Z 5$$ ERROR $$/usr/sbin/mysqld：表 ‘./example/wp_options’ 被標記為崩潰，應該修復
2017-04-20T18:56:26.156037Z 4$$ Warning $$檢查表：’./example/wp_options’
2017-04-20T18:56:35.816730Z 4$$ ERROR $$/usr/sbin/mysqld: 表 ‘./example/wp_usermeta’ 被標記為崩潰，應該修復
2017-04-20T18:56:35.816875Z 4$$ Warning $$檢查表：’./example/wp_usermeta’
- 關閉伺服器並嘗試將 VM 移動到另一個驅動器，但失敗並顯示文件錯誤。
- 我最近的懷疑是這是由壞塊引起的，但執行壞塊似乎會在完成 25% 時觸發崩潰。在 fsck 期間，我看到：fsck 關鍵介質錯誤，dev sda，扇區 147306432
不要把時間浪費在數據庫調整和其他事情上，你的驅動器對我來說絕對是有罪的……
嘗試盡可能多地轉儲數據庫，嘗試低級驅動器格式化並啟動干淨的虛擬機。