2. 程式人生 > >梳理下MySQL崩潰恢復過程

梳理下MySQL崩潰恢復過程

阿新 • • 發佈：2019-01-02

基於MySQL5.7版本，5.7版本在恢復過程做了優化，本文描述不考慮之前版本。

1 初始化崩潰恢復

    資料庫關閉只有2種情況，正常關閉，非正常關閉（包括資料庫例項crash及伺服器crash）。

    正常關閉情況，所有buffer pool裡邊的髒頁都會都會重新整理一遍到磁碟，同時記錄最新LSN到ibdata檔案的第一個page中。而非正常關閉來不及做這些操作，也就是沒及時把髒資料flush到磁碟，也沒有記錄最新LSN到ibdata file。

    當我們重啟資料庫例項的時候，資料庫做2個階段性操作：redo log處理，undo log及binlog 處理。

1.1 redo log處理

  • 開啟系統表空間ibdata，讀取第一個page中的LSN，若第一個頁損壞，則依次往後面的page讀，知道有個完整的page能夠提供LSN，這個LSN當作上次shutdown時的checkpoint點，後續恢復，從這個LSN點開始恢復
  • 進入redo log檔案，讀取第一個redo log檔案頭的checkpoint LSN， 並根據該LSN定位到redo日誌檔案中對應的位置，從該checkpoint點開始掃描，進行3次redo log檔案掃描：
    • 第一次，找 MLOG_CHECKPOINT日誌
      • 如果是正常關閉，這個日誌是不做記錄的，也就是掃描的過程中不回找到對應的MLOG_CHECKPOINT日誌，不會進行接下來的兩次掃描，因為屬於正常關閉資料庫服務，不需要考慮奔潰恢復情況；
      • 如果是非正常關閉，則會查詢到 MLOG_CHECKPOINT （如果是多個，則說明redo檔案已損壞，恢復報錯），獲取MLOG_FILE_NAME中指定後續需要恢復的ibd檔案；
    • 第二次，從redo log讀到的LSN，找到checkpoint點開始重複掃描儲存日誌物件
      • 根據MLOG_CHECKPOINT日誌，讀取對應LSN之後的日誌解析到hash表中，如果剩下的日誌解析結束後還沒有填滿hash表格，則不需要進行第三次掃描；
      • 進行到這裡，則說明資料庫是非正常關閉，會在errorlog中提示：Database was not shutdown normally!詳見下圖。
    • 第三次，若第二次掃描hash表空間不足，則發起第三次掃描，清空hash表空間，重新從新的checkpoint點開始掃描
      • 如果第二次掃掃描就把hash表填滿，那麼會先把hash表裡邊的記錄重做到buffer pool中的資料頁，然後再來載入redo log 記錄到被清空的hash表中，hash表滿後立即執行恢復操作，知道所有需要redo 的redo log 被應用結束。

    恢復的過程中，注意兩個點：開啟ibd檔案形式，讀取資料庫到buffer pool的改進。

    根據hash表中的相應資訊讀取資料頁， 讀資料頁的時候，5.7之前版本採用把所有表空間都開啟，所有表格僅執行ReadOnly，5.7版本做了優化，新增了 MLOG_FILE_NAME 記錄在checkpoint之後，所有被修改過的資訊，根據這些資訊，在恢復過程中，只需要開啟相應的ibd檔案即可，不涉及恢復的表格支援正常DML跟DDL操作，涉及恢復的表格則僅執行ReadOnly功能。

    當把資料頁讀取到buffer pool中，以往版本是隻讀取對應的單個頁面，而現在的是直接讀取與該頁面相鄰的32個data page 也一起載入的buffer pool，因為一個數據頁的修改，可能周圍的頁面也被修改，一次性讀取，可以避免後面根據hash表中再重新讀取其相鄰的頁面。

1.2 undo log及binlog 處理

      上一階段中，把redo log中的操作都apply到資料頁中，但是對於prepare狀態的事務卻還沒有進行回滾處理，這個階段則是針對prepare狀態的事務進行處理，需要使用到binlog和undo log。

  • 根據最後一個binlog檔案，為啥不是所有binlog檔案呢？因為每一個binlog檔案切換的時候，都會確保當前binlog檔案的所有操作已落盤，所以只需要考慮最後一個binlog檔案。跟進最後一個binlog檔案，獲取所有可能沒有提交事務的xid列表；
  • 根據undo log中的 insert_undo_list，upddate_undo_list事務鏈，構建undo_list，在根據undo_list構建未提交事務連結串列;
  • 從未提交事務連結串列中，提取出xid，凡是存在於xid列表中的，則需要提交，不存在的，則回滾。

      整個恢復過程，可以參考下來自 www.sysdb.cn 網站作者  boyce 畫的說明圖，圖片版權屬於該作者，本處僅為引用分享給大家，作圖很詳細，一言不合開原始碼分析！遺憾的是，作者只寫了2篇博文就停止更新了，心疼默哀十分鐘.....

2 innodb關閉恢復涉及引數

2.1 關閉引數：innodb_fast_shutdown

    資料庫關閉的時候，innodb需要完成所有full purge何insert buffer操作，這需要一些時間，甚至幾個小時完成

  • 0
    • 關閉時，需要完成所有full purge，insert buffer， flush dirty pages操作
    • 做 innodb plugin升級時，會設定為0，再正常關閉資料庫。
  • 1
    • 預設值，表示不需要完成full purge和insert buffer操作，但是緩衝池的髒資料需要重新整理到磁碟
  • 2
    • 既不完成full purge和insert buffer操作，也不把緩衝池的髒資料重新整理到磁碟，而是將日誌寫入日誌檔案，這樣不回有資料丟失，但是下次mysql啟動的時候，需要根據日誌檔案執行恢復操作

2.2 恢復引數：innodb_force_recovery

    這裡注意，數字越小，則忽略檢查的內容越少，每個大的數字都包含了前面小數字忽略檢查的內容。當引數設定大於0後，可以對錶格進行DML操作，但是DDL操作時不允許的。

    當innodb_force_recovery 值為1-3時，僅允許SELECT TABLE ，DROP or CREATE tables；innodb_force_recovery 值為>=4時，5.7.17之前版本支援DROP TABLE，5.7.18後版本不支援。

    引數說明如下圖：

3 測試情況

    測試內容：     begin;insert into orders select * from orders.orders limit 100000;     插入結束後不提交事務，執行 kill mysql程序     tailf error.log檢視

3.1 預設配置測試：innodb_fast_shutdown=1，innodb_force_recovery=0

   配置說明：異常停止DB服務時，不需要完成 full purge 和 insert buffer 操作，但是緩衝池的髒資料需要重新整理到磁碟；服務啟動的時候，做所有需要的檢查跟事務操作。

3.1.1 操作過程

複製程式碼 
 1 #1 tailf error.log檢視mysql錯誤日誌,動態滾動檢視
 2 mysql> show global variables like 'log_error';
 3 tailf /data/mysql/mysql3310/data/error.log
 4 
 5 #2 測試庫中開啟事務，insert 10w行記錄，不提交事務
 6 mysql> begin;insert into orders select * from orders.orders limit 100000;
 7 Query OK, 0 rows affected (0.00 sec)
 8 
 9 Query OK, 100000 rows affected (37.55 sec)
10 Records: 100000  Duplicates: 0  Warnings: 0
11 
12 #3 查詢mysql程序號，殺程序
13 [[email protected] opt]# ps axu | grep mysql
14 [[email protected] opt]# kill -9 mysql的程序號
15 
16 #4 啟動mysql服務
17 mysqld --defaults-file=/data/mysql/mysql3310/mysql3310.cnf &
18 
19 #5 到tailf error.log視窗檢視錯誤
複製程式碼

3.1.2 error log解析

啟動mysqld程序 2017-03-16T16:28:13.812074Z 0 [Note] mysqld (mysqld 5.7.14-log) starting as process 28091 ... 讀取ibdata的LSN 讀取redo檔案的checkpoint，從該點的LSN開始查詢MLOG_CHECKPOINT 發現MLOG_CHECKPOINT日誌，提示：Database was not shutdown normally !   2017-03-16T16:28:16.572276Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 898634772645 2017-03-16T16:28:16.572418Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 898634772654 2017-03-16T16:28:16.693771Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 898634772654 2017-03-16T16:28:16.693880Z 0 [Note] InnoDB: Database was not shutdown normally! 2017-03-16T16:28:16.693913Z 0 [Note] InnoDB: Starting crash recovery. 檢測需要重做跟回滾的事務 由於沒有需要redo的事務，但是有undo事務，開始undo操作 載入redo log中的96個系統回滾段 rollbak segment，32個不需要redo 的臨時表空間的回滾段 2017-03-16T16:28:17.360953Z 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 100000 row operations to undo 獲取binlog回滾xid列表，結合undo log做回滾操作 2017-03-16T16:28:17.361122Z 0 [Note] InnoDB: Trx id counter is 5716480 2017-03-16T16:28:17.625441Z 0 [Note] InnoDB: Last MySQL binlog file position 0 37774, file name bin_log.000016 2017-03-16T16:28:17.787684Z 0 [Note] InnoDB: Starting in background the rollback of uncommitted transactions 2017-03-16T16:28:17.788022Z 0 [Note] InnoDB: Rolling back trx with id 5715975, 100000 rows to undo 啟動innodb，載入buffer pool 2017-03-16T16:28:17.838323Z 0 [Note] InnoDB: Waiting for purge to start 2017-03-16T16:28:18.015792Z 0 [Note] InnoDB: 5.7.14 started; log sequence number 898634772654 mysqld正常執行提供使用者使用 2017-03-16T16:28:18.772035Z 0 [Note] mysqld: ready for connections. Version: '5.7.14-log'  socket: '/tmp/mysql3310.sock'  port: 3310  MySQL Community Server (GPL) 這個時候，recovery可能還沒結束，比如這個例子中，recovery就還在進行，其涉及的表僅提供ReadOnly操作，其他表格可正常操作 ，慢慢恢復，最後undo回滾事務完成，Rollback of non-prepared transactions completed  2 3 4 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 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 1002017-03-16T16:29:24.353056Z 0 [Note] InnoDB: Rollback of trx with id 5715975 completed 2017-03-16T16:29:24.353267Z 0 [Note] InnoDB: Rollback of non-prepared transactions completed 整個過程16:28:13啟動，16:28:18 DB提供部分服務，16:29:24全庫恢復，db部分提供服務耗時5s，全庫提供服務耗時71s 。  實驗1 error log詳細內容

3.2 innodb_fast_shutdown=1，innodb_force_recovery=3

    配置說明：異常停止DB服務時，不需要完成full purge和insert buffer操作，但是緩衝池的髒資料需要重新整理到磁碟；服務啟動的時候，忽略檢查corrupt頁，也阻止主執行緒的執行，並且不執行事務回滾操作。     當innodb_force_recovery 值為1-3時，允許SELECT TABLE ，DROP or CREATE tables；innodb_force_recovery 值為>=4時，5.7.17之前版本支援DROP TABLE，5.7.18後版本不支援。     這個配置適用於這種情況：有某些大表執行alter或者大量資料修改操作生成大量undo宕機，那麼這個情況下，可以進入cnf配置檔案修改innodb_force_recovery=3，然後把再做undo操作的表格資料匯出來或者利用備份檔案的資料，再drop掉這個表格，進入cnf配置檔案，修改引數為0，重啟DB服務，會發現，rollback過程非常快執行結束，因為找不到對應表格，所以rollback非常快。     Tips: 如何查詢在undo操作的表格？     資料庫crash後，第一個正常啟動恢復連線，連進資料庫裡邊，操作所有表格，不支援insert update 的表格都屬於正在undo的表。

3.2.1 操作過程

複製程式碼 
 1 #1 tailf error.log檢視mysql錯誤日誌,動態滾動檢視
 2 mysql> show global variables like 'log_error';
 3 tailf /data/mysql/mysql3310/data/error.log
 4 
 5 #2 測試庫中開啟事務，insert 10w行記錄，不提交事務
 6 mysql> begin;insert into orders select * from orders.orders limit 100000;
 7 Query OK, 0 rows affected (0.00 sec)
 8 
 9 Query OK, 100000 rows affected (37.55 sec)
10 Records: 100000  Duplicates: 0  Warnings: 0
11 
12 #3 查詢mysql程序號，殺程序
13 [[email protected] opt]# ps axu | grep mysql
14 [[email protected] opt]# kill -9 mysql的程序號
15 
16 #4 在cnf檔案中指定innodb_force_recovery=3,啟動服務，檢查是否修改成功
17 [[email protected] ~]# vim /data/mysql/mysql3310.cnf
18 #新增innodb_force_recovery引數設定
19 [mysqld]
20 innodb_force_recovery=3
21 
22 #5 啟動mysql服務
23 [[email protected] ~]# mysqld --defaults-file=/data/mysql/mysql3310.cnf &
24 
25 #6 到tailf error.log視窗檢視錯誤
26 #發現沒有進行undo操作，同時全庫僅支援select drop create，不支援其他所有操作
複製程式碼

3.2.2 error log解析

啟動mysqld程序 2017-03-17T15:12:14.317391Z 0 [Note] mysqld (mysqld 5.7.14-log) starting as process 32094 ... 讀取ibdata的LSN 讀取redo檔案的checkpoint，從該點的LSN開始查詢MLOG_CHECKPOINT 發現MLOG_CHECKPOINT日誌，提示：Database was not shutdown normally !   2017-03-17T15:12:16.478403Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 898935661420 2017-03-17T15:12:16.478579Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 898935661429 2017-03-17T15:12:16.532923Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 898935661429 2017-03-17T15:12:16.533063Z 0 [Note] InnoDB: Database was not shutdown normally! 2017-03-17T15:12:16.533105Z 0 [Note] InnoDB: Starting crash recovery. 檢測需要重做跟回滾的事務 由於沒有需要redo的事務，但是有undo事務，開始undo操作 載入redo log中的96個系統回滾段 rollbak segment，32個不需要redo 的臨時表空間的回滾段 2017-03-17T15:12:17.052734Z 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 100000 row operations to undo 獲取binlog回滾xid列表，但是這裡注意，沒有做 回滾操作 2017-03-17T15:12:17.053009Z 0 [Note] InnoDB: Trx id counter is 5718016 2017-03-17T15:12:17.321987Z 0 [Note] InnoDB: Last MySQL binlog file position 0 37774, file name bin_log.000016 啟動innodb，載入buffer pool ，警告當前 innodb_force_recovery 設定為3 2017-03-17T15:12:17.518732Z 0 [Note] InnoDB: 5.7.14 started; log sequence number 898935661429 2017-03-17T15:12:17.518789Z 0 [Note] InnoDB: !!! innodb_force_recovery is set to 3 !!! 2017-03-17T15:12:17.519305Z 0 [Note] InnoDB: Loading buffer pool(s) from /data/mysql/mysql3310/data/ib_buffer_pool mysqld正常執行提供使用者使用，但是，全庫僅提供readonly 2017-03-17T15:12:18.521680Z 0 [Note] mysqld: ready for connections. Version: '5.7.14-log'  socket: '/tmp/mysql3310.sock'  port: 3310  MySQL Community Server (GPL) 2017-03-17T15:13:03.125686Z 2 [ERROR] InnoDB: innodb_force_recovery is on. We do not allow database modifications by the user. Shut down mysqld and edit my.cnf to set innodb_force_recovery=0     整個過程15:12:14啟動，15:12:18 DB提供部分服務，耗時4s。但是由於沒有做undo操作，錯誤日誌提醒 We do not allow database modifications by the user. 不支援當前使用者進行資料庫修改操作，僅支援select table，drop table，create table操作，其他所有操作都不支援。     這種情況下啟動資料庫後，可以支援你dump出正在做undo的表格資料，然後drop掉它，如果你有備份檔案恢復，那麼則不需要dump，直接drop，然後修改cnf配置檔案，設定innodb_force_recovery=0 ，重啟資料庫服務，這個時候，innodb 的undo recovery非常快，因為找不到對應的表格操作，所以都是直接挑過處理。正常恢復後，趕緊把drop掉的表格從備份檔案或者dump出來的sql檔案中恢復回來。注意注意！！！！這種情況要權衡利弊，從時間耗時跟操作安全資料安全考慮，是undo recovery快還是你如此操作快，然後一定一定要跟你的上級或者領導報備操作的風險性，不要默默幹，要報告！！！ 複製程式碼 
 1 2017-03-17T15:12:14.317391Z 0 [Note] mysqld (mysqld 5.7.14-log) starting as process 32094 ...
 2 2017-03-17T15:12:14.430101Z 0 [Note] InnoDB: PUNCH HOLE support not available
 3 2017-03-17T15:12:14.430586Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
 4 2017-03-17T15:12:14.430732Z 0 [Note] InnoDB: Uses event mutexes
 5 2017-03-17T15:12:14.430874Z 0 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
 6 2017-03-17T15:12:14.430993Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
 7 2017-03-17T15:12:14.431084Z 0 [Note] InnoDB: Using Linux native AIO
 8 2017-03-17T15:12:14.433127Z 0 [Note] InnoDB: Number of pools: 1
 9 2017-03-17T15:12:14.434016Z 0 [Note] InnoDB: Not using CPU crc32 instructions
10 2017-03-17T15:12:14.443970Z 0 [Note] InnoDB: Initializing buffer pool, total size = 9G, instances = 8, chunk size = 128M
11 2017-03-17T15:12:16.158820Z 0 [Note] InnoDB: Completed initialization of buffer pool
12 2017-03-17T15:12:16.380118Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
13 2017-03-17T15:12:16.409819Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
14 2017-03-17T15:12:16.478403Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 898935661420
15 2017-03-17T15:12:16.478579Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 898935661429
16 2017-03-17T15:12:16.532923Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 898935661429
17 2017-03-17T15:12:16.533063Z 0 [Note] InnoDB: Database was not shutdown normally!
18 2017-03-17T15:12:16.533105Z 0 [Note] InnoDB: Starting crash recovery.
19 2017-03-17T15:12:17.052734Z 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 100000 row operations to undo
20 2017-03-17T15:12:17.053009Z 0 [Note] InnoDB: Trx id counter is 5718016
21 2017-03-17T15:12:17.321987Z 0 [Note] InnoDB: Last MySQL binlog file position 0 37774, file name bin_log.000016
22 2017-03-17T15:12:17.460435Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
23 2017-03-17T15:12:17.460673Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
24 2017-03-17T15:
            
  

           

              
              

            

            
相關推薦

			   
            
            
            
 

    


    
    
梳理下MySQL崩潰恢復過程

     
 

基於MySQL5.7版本，5.7版本在恢復過程做了優化，本文描述不考慮之前版本。


1 初始化崩潰恢復
    資料庫關閉只有2種情況，正常關閉，非正常關閉（包括資料庫例項crash及伺服器crash）。
    正常關閉情況，所有buffer pool裡邊的髒頁都會都會重新整理一遍到磁碟，同時記錄最新 



  
 

    


    
    
mysql innodb恢復過程

     
  
 
 總體來說，innodb恢復過程包含以下幾個步驟： 
 一、查詢表空間： 
         這裡的查詢表空間，主要是查詢重做日誌來實現的。 
         如果innodb發現到上一次檢查點之後寫入的重做日誌，那麼必 



  
 

    


    
    
MySQL崩潰恢復與組提交

     
   

  
 
 
  
  Ⅰ、binlog與redo的一致性(原子) 
  由內部分散式事務保證 
  我們先來了解下,當一個commit敲下後,內部會發生什麼？ 
   
    
    
     步驟
     操作
     
    
    
     
     st 



  
 

    


    
    
linux系統下mysql的安裝過程

     
 
							
							
							mysql的安裝的方式有兩種，第一種可以通過原始碼安裝，需要通過很長時間的編譯過程。這種方法就不介紹了。第二種是通過二進位制檔案安裝，安裝速度較快，但是安裝包比較大，現在主要介紹這種方法的安裝過程。

1.下載mysql安裝包，下載地址http://dev.my 



  
 

    


    
    
記一次揪心的MySQL資料恢復過程

     
 
							
							
							先說下背景，公司其中一個專案所有服務都部署在客戶的機房內，機房較小，沒有UPS。其中一個MySQL例項(單機，無主從，windows server 2008，MySQL5.6.19)存放大量的日誌資料，每天幾十G的資料，定期清除(儲存大概四個月的資料)，由於硬碟 



  
 

    


    
    
基於Redo Log和Undo Log的MySQL崩潰恢復流程

     
 在之前的文章「簡單瞭解InnoDB底層原理」聊了一下MySQL的Buffer Pool。這裡再簡單提一嘴，Buffer Pool是MySQL記憶體結構中十分核心的一個組成，你可以先把它想象成一個黑盒子。
黑盒下的更新資料流程
當我們查詢資料的時候，會先去Buffer Pool中查詢。如果Buffer Pool 



  
 

    


    
    
一起看下MySQL的崩潰恢復到底是怎麼回事

     
 [TOC]

本文稍微有點晦澀、但是看過之後你就能Get到MySQL的崩潰恢復到底是怎麼做的！

文章公號 首發！連載中！關注微信公號回覆：“抽獎”  還可參加抽 



  
 

    


    
    
Linux下MySQL的備份和恢復

     
 mysql備份   再也不用擔心數據丟失了   MySQL備份的原因
 1. 災難恢復
 2. 審計 
 3. 測試1234512345mysql的備份類型
 1. 根據服務器的在線狀態：
    熱備：服務器處於運行狀態
    冷備：服務器出去停止狀態
    溫備：服務器處於半離線狀態，只能讀，但是不能 



  
 

    


    
    
Windows環境下Mysql如何快速導入或恢復表為innodb的數據

     
 數據恢復   myisam   mysql的安裝   是否   安裝   導入表   style   window   是你   註：
　　一、這個是對Innodb的數據恢復。MyISAM不需要這麽麻煩，只要數據文件存在直接復制過去就可以。
　　二、該方法只適用於
　　　　　　1：想要恢復或者導入表的ibd文 



  
 

    


    
    
Linux下MySQL/MariaDB Galera集群搭建過程【轉】

     
 分支   指定   util   -1   令行   第一個   否則   alt   常見   MariaDB介紹
MariaDB是開源社區維護的一個MySQL分支，由MySQL的創始人Michael Widenius主導開發，采用GPL授權許可證。
MariaDB的目的是完全兼容MySQL，包括API 



  
 

    


    
    
Mysql加鎖過程詳解（9）-innodb下的記錄鎖，間隙鎖，next-key鎖

     
 ans   唯一索引   crazy   cimage   -h   insert   tran   存在   gin   

Mysql加鎖過程詳解（1）-基本知識
Mysql加鎖過程詳解（2）-關於mysql 幻讀理解
Mysql加鎖過程詳解（3）-關於mysql 幻讀理解
Mysql加鎖過程詳解（4）- 



  
 

    


    
    
mysql數據庫無法啟動恢復 mysql數據庫崩潰恢復 mysql數據庫恢復

     
 容量   int   ace   分析文件   events   sta   .html   form   startup   mysql數據庫無法啟動恢復 mysql數據庫崩潰恢復 mysql數據庫恢復
 
客戶名稱 保密
 
數據類型 mysql 5.5 innodb
 
數據容量 1500 MB
 
故 



  
 

    


    
    
EMC存儲崩潰恢復數據過程

     
 數據恢復   EMC   存儲   raid   【Raid數據恢復概述】北京某企業一臺EMC FC AX-4存儲由於存儲上的RAID5陣列故障導致存儲癱瘓，急需進行raid數據恢復。這臺存儲中搭建了一組12塊硬盤的raid5磁盤陣列，陣列中包括有2塊熱備盤。由於raid陣列中出現兩塊硬盤離線，但熱備盤中有一 



  
 

    


    
    
Windows下MySQL的binlog恢復

     
 nta   更多   scp   第一步   ahk   psc   vra   3rd   sna   前言

　　在最近的工作中，由於自己粗（zuo）心（si）誤update操作導致幾百行的數據出現錯誤，在心急如焚的同時（那時候我竟然不知道除了備份之後還有binlog日誌恢復）立馬查資料學習binlog的 



  
 

    


    
    
win10下mysql安裝過程中遇到的各種坑

     
 前幾天重灌系統，又要下回來mysql，但沒想到還是遇到了許多麻煩，翻了十多篇博文才搞定，寫個總結出來方便以後不要重複踩坑，也給大家參考參考。 
1.下載與安裝 
　　這個沒什麼好說的，下載地址網上一大堆，安裝教程也是，舊版本比如說5.6可能麻煩些，csdn要積分，官網要登入，下最新版就好了，我的是5.7.22 



  
 

    


    
    
win10環境下MySql（5.7.21版本）安裝過程出現安裝MySQL無法定位程式輸入點fesetround於動態連結庫

     
 
                Mysql  安裝時報錯： 無法定位程式輸入點fesetround於動態連結庫MSVCR120.dll上

















解決方法：下載 Microsoft Visual C++ 2013 Redistributable Package 安裝



http 



  
 

    


    
    
Mysql在高併發下的崩潰

     
 
                181017 16:47:17  InnoDB: Operating system error number 995 in a file operation.
InnoDB: Some operating system error numbers are described  



  
 

    


    
    
Linux下mysql定時備份及恢復

     
 
                備份1.資料庫定時備份工作指令碼：(日期時間作為名稱的壓縮檔案，解壓開是sql指令碼)/root/backup/script/backup_mysql.sh2.備份輸出路徑：/root/backup/mysql3.執行計劃任務的命令：#crontab -e 開啟計劃任務編輯器 



  
 

    


    
    
MySQL之UNDO及MVCC、崩潰恢復

     
   

  
 
 
  
   
    
    UNDO特性：避免髒讀、事務回滾、非阻塞讀、MVCC、崩潰恢復 
    事務工作流程（圖2） 
    MVCC原理機制 
    崩潰恢復：redo前滾、undo回滾 
    長事務、大事務：危害、判斷、處理 
    UNDO優 



  
 

    


    
    
windows下mysql開啟binlog日誌及利用binlog日誌恢復資料筆記

     
 
                1、開啟binlog日誌。

找到mysql安裝目錄，開啟配置檔案my.ini

在[mysqld]下新增：

bin-log=mysql-bin

儲存後重啟mysql。此時在data目錄會生成mysql-bin.000001和mysql-bin.index。

注意：My