使用innodb_force_recovery解決MySQL崩潰無法重啟問題_MySQL教程
推薦:MySQL replace into 語句淺析(二)這篇文章主要介紹了MySQL replace into 語句淺析(二),本文著重給出了幾個特殊案例分析,需要的朋友可以參考下 一 介紹 上一篇文章介紹了replace into的基本原理。本章內(nèi)容通過一個例子說明 replace into 帶來的潛在的數(shù)據(jù)質(zhì)量風險,當涉及replace into操作的表含有自增主
這篇文章主要介紹了使用innodb_force_recovery解決MySQL崩潰無法重啟問題,這只一個成功案例,并不是萬能的解決方法,需要酌情考慮,需要的朋友可以參考下
一 背景
某一創(chuàng)業(yè)的朋友的主機因為磁盤陣列損壞機器crash,重啟MySQL服務(wù)時 報如下錯誤:
代碼如下:
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 9120034833
150125 16:12:51 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 150125 16:12:51 [ERROR] mysqld got signal 11 ;
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.
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 5.5.37-MariaDB-log
key_buffer_size=268435456
read_buffer_size=1048576
max_used_connections=0
max_threads=1002
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2332093 K bytes of memory
41 Hope that.
二 分析
主要關(guān)注 mysqld got signal 11 的問題,從日志內(nèi)容分析來看,數(shù)據(jù)庫在機器crash 導致日志文件損壞,重啟之后無法正常恢復,更無法正常對外提供服務(wù)。
三 解決
因為日志已經(jīng)損壞,這里采用非常規(guī)手段,首先修改innodb_force_recovery參數(shù),使mysqld跳過恢復步驟,將mysqld 啟動,將數(shù)據(jù)導出來然后重建數(shù)據(jù)庫。
innodb_force_recovery可以設(shè)置為1-6,大的數(shù)字包含前面所有數(shù)字的影響。
1. (SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁。
2. (SRV_FORCE_NO_BACKGROUND):阻止主線程的運行,如主線程需要執(zhí)行full purge操作,會導致crash。
3. (SRV_FORCE_NO_TRX_UNDO):不執(zhí)行事務(wù)回滾操作。
4. (SRV_FORCE_NO_IBUF_MERGE):不執(zhí)行插入緩沖的合并操作。
5. (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存儲引擎會將未提交的事務(wù)視為已提交。
6. (SRV_FORCE_NO_LOG_REDO):不執(zhí)行前滾的操作。
注意
a 當設(shè)置參數(shù)值大于0后,可以對表進行select,create,drop操作,但insert,update或者delete這類操作是不允許的。
b 當innodb_purge_threads 和 innodb_force_recovery一起設(shè)置會出現(xiàn)一種loop現(xiàn)象:
代碼如下:
150125 17:07:42 InnoDB: Waiting for the background threads to start
150125 17:07:43 InnoDB: Waiting for the background threads to start
150125 17:07:44 InnoDB: Waiting for the background threads to start
150125 17:07:45 InnoDB: Waiting for the background threads to start
150125 17:07:46 InnoDB: Waiting for the background threads to start
150125 17:07:47 InnoDB: Waiting for the background threads to start
在my.cnf中修改以下兩個參數(shù)
代碼如下:
innodb_force_recovery=6
innodb_purge_thread=0
重啟MySQL
代碼如下:
150125 17:10:47 [Note] Crash recovery finished.
150125 17:10:47 [Note] Server socket created on IP: '0.0.0.0'.
150125 17:10:47 [Note] Event Scheduler: Loaded 0 events
150125 17:10:47 [Note] /vdata/webserver/mysql/bin/mysqld: ready for connections.
Version: '5.5.37-MariaDB-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution
立即對數(shù)據(jù)庫做邏輯導出 ,完成之后將innodb_force_recovery設(shè)置為0 ,innodb_purge_thread=1 ,然后重建數(shù)據(jù)庫 。
另外 MySQL 版本 5.5以及之前 ,當innodb_purge_threads =1,innodb_force_recovery >1 的情況會出現(xiàn)上文提到的循環(huán)報warning 問題(=1 沒有問題),
原因:
MySQL 的源代碼中顯示 當innodb_purge_threads 和 innodb_force_recovery一起設(shè)置會出現(xiàn)loop循環(huán)
代碼如下:
while (srv_shutdown_state == SRV_SHUTDOWN_NONE) {
if (srv_thread_has_reserved_slot(SRV_MASTER) == ULINT_UNDEFINED
|| (srv_n_purge_threads == 1
&& srv_thread_has_reserved_slot(SRV_WORKER)
== ULINT_UNDEFINED)) {
ut_print_timestamp(stderr);
fprintf(stderr, " InnoDB: Waiting for the background threads to start\n");
os_thread_sleep(1000000);
} else {
break;
}
}
所以當需要設(shè)置innodb_force_recovery>1的時候需要關(guān)閉 innodb_purge_threads,設(shè)置為0(默認)。
四 小結(jié)
MySQL crash 或者 MySQL 數(shù)據(jù)庫服務(wù)器 crash 會導致各種各樣的問題 ,比如主備之間的error 1594 (5.6 版本開啟crash-safe ,會最大程度上避免 error 1594的問題,以后會寫5.6新特性介紹該功能 ),error 1236, 日志損壞,數(shù)據(jù)文件損壞 ,等等,本案例只是其中的一種,細心從日志中找的相關(guān)錯誤提示,逐步解決即可。
分享:MySQL replace into 語句淺析(一)這篇文章主要介紹了MySQL replace into 語句淺析(一),本文講解了replace into的原理、使用方法及使用的場景和使用示例,需要的朋友可以參考下 一 介紹 在筆者支持業(yè)務(wù)過程中,經(jīng)常遇到開發(fā)咨詢replace into 的使用場景以及注意事項,這里做個總結(jié)。從功能原理,性能和注
- 防止服務(wù)器宕機時MySQL數(shù)據(jù)丟失的幾種方案
- MySQL Semisynchronous Replication介紹
- MySQL延遲關(guān)聯(lián)性能優(yōu)化方法
- MySQL 5.7增強版Semisync Replication性能優(yōu)化
- MySQL Index Condition Pushdown(ICP)性能優(yōu)化方法實例
- MySQL order by性能優(yōu)化方法實例
- MySQL slave_net_timeout參數(shù)解決的一個集群問題案例
- MySQL replace into 語句淺析(二)
- MySQL replace into 語句淺析(一)
- MySQL定期自動刪除表
- MySQL中的CONCAT函數(shù)使用教程
- MySQL中的RAND()函數(shù)使用詳解
MySQL教程Rss訂閱編程教程搜索
MySQL教程推薦
猜你也喜歡看這些
- 怎樣使用SQLServer數(shù)據(jù)庫查詢累計值
- 使用SQL Server 2008進行服務(wù)器合并
- 帶你深入了解SQL Server 2008獨到之處
- 解析SQL Server 2008企業(yè)級新特性
- Sql Server 2008完全卸載方法(其他版本類似)
- mdf文件和ldf文件導入到sql server 2005實現(xiàn)語句
- 解讀在SQL Server中處理空值時涉及的三個問題
- 微軟已證實最新的關(guān)鍵SQL Server漏洞
- SQL Server2005的XML數(shù)據(jù)類型之基礎(chǔ)篇
- 怎樣用壓縮技術(shù)給SQL Server備份文件瘦身
- 相關(guān)鏈接:
- 教程說明:
MySQL教程-使用innodb_force_recovery解決MySQL崩潰無法重啟問題。