mysql宕機原因,mysql故障

本文目錄一覽：

• 1、python保存mysql頻繁後死機
• 2、mysql在收到大量請求為什麼會宕機？
• 3、如何優化mysql內存佔用高導致宕機
• 4、網站宕機 服務器宕機 數據庫宕機 宕機怎麼辦

python保存mysql頻繁後死機

猜測您的問題是：python保存mysql後頻繁死機是怎麼回事，可能是數據格式不對。

python保存mysql後頻繁死機可能是數據格式不對，建議換一個編碼器打開編輯，重新保存。

Python是一種解釋型、面向對象、動態數據類型的高級程序設計語言。Python由GuidovanRossum於1989年底發明，第一個公開發行版發行於1991年。

mysql在收到大量請求為什麼會宕機？

1.檢查是否有備份，如果備份存在，binlog存在，那麼萬事大吉，一切都有挽回的餘地，慢慢來搞，只要你基礎紮實，數據還原只是時間的問題。

2.對於沒有備份的，那處理這個問題就有些棘手了，還得一步一步的來。

在my.cnf中[mysqld]下加上以下配置，採用強制恢復機制，看是否能夠啟動

[mysqld]

innodb_force_recovery=1

如果設置成1不能啟動，可以逐漸的將數據增大到6，下文會詳細說下1-6是什麼意思，如果在1-6之間啟動成功了，那麼你運氣還不錯，這時候不要恢復業務，趕緊把數據用邏輯方式導出來，再啟個新的實例把數據還原，有人會問，為什麼mysql已經啟動了，還要導出數據呢，原因在這：

當innodb_force_recovery被設置為大於0的時候 ，會阻止用戶insert,update,delete也就是你啟動的mysql不是一個正常的mysql服務，類似於windows系統下的安全模式。以下這段引於其它地方，具體地址不太清楚了，也可以從官方文檔中找到。

如何優化mysql內存佔用高導致宕機

1，首先通過任務管理器進行進程排序，查找佔用內存較大的程序進程。一般佔用內存較大的進程有W3WP、sqlserver、mysqld-nt.exe；

2， 站點進程w3wp 可以在cmd命令行中通過 iisapp 命令來對應是那個網站佔用內存較大。可以通過設置回收時間、內存最大使用值或共用進程池來減少內存的佔用，但是如果要保證網站的訪問質量，還是建議升級至更高型號來解決；

3，數據庫 sql server 也可以通過數據庫的企業管理器來設置最大內存佔用，但是如果網站程序必須要佔用較大內存的話，設置後會發生頁面報錯、打不開等問題；

4，MYSQL本身會佔用較大虛擬內存，如果不使用mysql數據庫的話，可以將其停止。

網站宕機 服務器宕機 數據庫宕機 宕機怎麼辦

最近遇到個比較有意思的問題，服務器宕掉後無法啟動，想了好多辦法，雖然解決了問題，數據沒有丟失，但是沒有按照自已的思路來，未免還是有些不甘。遇到問題不能慌，尤其是線上的環境，更不能緊張，心理素質對DBA來說也是一項挑戰，可能你的手一抖就會導致多少人無法正常使用業務，如果你沒有把握，請先把現場環境備份後再進行操作，避免數據的二次損壞，下面壹基比小喻說一下大概的思路吧。

1.檢查是否有備份，如果備份存在，binlog存在，那麼萬事大吉，一切都有挽回的餘地，慢慢來搞，只要你基礎紮實，數據還原只是時間的問題。

2.對於沒有備份的，那處理這個問題就有些棘手了，還得一步一步的來。

在my.cnf中[mysqld]下加上以下配置，採用強制恢復機制，看是否能夠啟動

[mysqld]

innodb_force_recovery=1

如果設置成1不能啟動，可以逐漸的將數據增大到6，下文會詳細說下1-6是什麼意思，如果在1-6之間啟動成功了，那麼你運氣還不錯，這時候不要恢復業務，趕緊把數據用邏輯方式導出來，再啟個新的實例把數據還原，有人會問，為什麼mysql已經啟動了，還要導出數據呢，原因在這：

當innodb_force_recovery被設置為大於0的時候 ，會阻止用戶insert,update,delete也就是你啟動的mysql不是一個正常的mysql服務，類似於windows系統下的安全模式。以下這段引於其它地方，具體地址不太清楚了，也可以從官方文檔中找到。

innodb_force_recovery被允許的非零值如下。一個更大的數字包含所有更小數字的預防措施。如果你能夠用一個多數是4的選項值來轉儲你的表，那麼你是比較安全的，只有一些在損壞的單獨頁面上的數據會丟失。一個為6的值更誇張，因為數據庫頁被留在一個陳舊的狀態，這個狀態反過來可以引發對B樹和其它數據庫結構的更多破壞。

innodb_force_recovery=1 (SRV_FORCE_IGNORE_CORRUPT)

即使服務器檢測到一個損壞的頁，也讓服務器運行着；試着讓SELECT * FROM tbl_name 跳過損壞的索引記錄和頁，這樣有助於轉儲表。

innodb_force_recovery=2 (SRV_FORCE_NO_BACKGROUND)

阻止主線程運行，如果崩潰可能在凈化操作過程中發生，這將阻止它。

innodb_force_recovery=3 (SRV_FORCE_NO_TRX_UNDO)

恢復後不運行事務回滾。

innodb_force_recovery=4 (SRV_FORCE_NO_IBUF_MERGE)

也阻止插入緩衝合併操作。如果你可能會導致一個崩潰。最好不要做這些操作，不要計算表統計表。

innodb_force_recovery=5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

啟動數據庫之時不查看未完成日誌：InnoDB把未完成的事務視為已提交的。

innodb_force_recovery=6 (SRV_FORCE_NO_LOG_REDO)

不要在恢復連接中做日誌前滾。

數據庫不能另外地帶着這些選項中被允許的選項來使用。作為一個安全措施，當innodb_force_recovery被設置為大於0的值時，InnoDB阻止用戶執行INSERT, UPDATE或DELETE操作.

即使強制恢復被使用，你也可以DROP或CREATE表。如果你知道一個給定的表正在導致回滾崩潰，你可以移除它。你也可以用這個來停止由失敗的大宗導入或失敗的ALTER TABLE導致的失控回滾。你可以殺掉mysqld進程，然後設置innodb_force_recovery為3，使得數據庫被掛起而不需要回滾，然後捨棄導致失控回滾的表。

關於上面進行邏輯備份也可能會遇到問題，可能會備份失敗，如果出錯，建議先按庫一個一個的備份，到哪個庫出錯後，再按照當前庫的表一個一個備份，表出錯根據表中主鍵一點一點備份，最終將大部分數據導出。如果你的數據不重要，可以容忍丟失，那麼可以當我說的都是廢話了。

3.如果還是不可以啟動，那麼恭喜你，你遇到挑戰了。

查看錯誤日誌，看沒有提示因為某個表的原因而導致啟動不了，可以先把損壞的表的ibd文件先從數據目錄mv走，再試着啟動，在數據已經恢復後，我把當時錯誤的文件拿到本地，做了測試，把幾個報錯的ibd文件mv走後，數據庫就可以正常啟動了，但是mv走的這幾個表數據會丟失。怎麼把這個表的數據弄回來呢，曾想過用在線表空間傳輸，但是.cfg文件卻沒有，這種方法沒有行通。後來用Percona Data Recovery Tool for InnoDB工具進行數據恢復，關於這個工具的介紹與操作，網上一大堆，我就不詳細說明了。