MySQL/mariadb误删ibdata1 ib_logfile0,ib_logfile1 恢复方法

admin

MySQL误删ibdata1 ib_logfile0,ib_logfile1 恢复方法:
7 b' A! C' i4 _3 s6 [& ?. N' C
恢复的步骤和数据库版本没有太大关系。
在linux操作系统中，如果文件从操作系统级别别rm掉，之前打开的文件进程仍持有相应的文件句柄，
所指向的文件仍然可以读写，且该文件的描述符可以从/proc目录中获得(不关闭MySQLd情况下).
# O( h8 Y! Z6 s7 Q: v7 n, }9 l
) k" U4 E% ~& ?- |, }8 }+ P- {在删除3个文件后，MySQLd 仍是可以运行，对外服务的，MySQL一只保持InnoDB文件打开，因此，
在工作中有必要监控文件是否存在。
发现文件被删除之后，不能重启InnoDB，因为启动InnoDB，检测到ibdata1,ib_logfile0,ib_logfile1
  i, H6 B3 ~% A不存在，所以，将创建对应的空文件，InnoDB数据字典是空的，InnoDB无法使用原先存在的ibd文件，故，
MySQL不重启，快速恢复删除的文件是可能的。

, u9 B: I8 Y- z3 G4 h8 {! F在MySQLd运行过程中，ibdata1,ib_logfile0,ib_logfile1一直运行在
) l: v+ x) {  F  B5 H/proc/mysql.pid/fd目录下，其中vm-mysql.pid是mysql进程的PID,获取方法:
5 ]3 n3 e) g9 |  |. r2 V0 T8 b& D[root@mysql ~]# ls -l /proc/$(cat /opt/mysql/data2/mysql.pid)/fd | grep -e ibdata -e ib_
+ M0 H8 L; F' w) }, T' H- ~3 U5 Elrwx------ 1 root root 64 Oct 16 14:16 10 -> /opt/mysql/data2/ib_logfile1 (deleted)
lrwx------ 1 root root 64 Oct 16 14:16 4 -> /opt/mysql/data2/ibdata1 (deleted)
lrwx------ 1 root root 64 Oct 16 14:16 9 -> /opt/mysql/data2/ib_logfile0 (deleted)

但是，我们不能简单copy回源目录中，因在buffer pool有已经修改的页，这些页没有被写入磁盘，如果改变的页
6 X. {# o% X5 F& |( M. z没有永久写入，数据将会丢失，这些导致数据损坏和丢失。
同样原因，我们不能做MySQL备份，仅能coping那些文件。
因此，我们必须确保所有的修改全写入磁盘中。
2 |/ f. I9 V' Z0 \2 q我们现在能做的阻止写，且等待InnoDB刷新所有的页。
- Y5 p* _; `8 R" [) ^1.为了阻止写，我们要么停止应用程序或锁表。
MariaDB [(none)]> flush tables with read lock;
5 O) L. q7 r8 @Query OK, 0 rows affected (0.01 sec)
5 O, n  s$ N$ ?2 T+ s* g
2. show engine innodb status 中脏页刷新到磁盘，
---
LOG
1 p- j; Z/ {: V9 _( L: [---
1 w8 l( C9 ^9 dLog sequence number 0 50355
Log flushed up to   0 50355
  o  U: r+ r1 H: }) rLast checkpoint at  0 50355
9 u) ~4 C! m/ n) i) P$ D  N! Z0 pending log writes, 0 pending chkp writes
39 log i/o's done, 0.00 log i/o's/second
- v4 F3 o* u: y' |
加速脏页刷新，设置dirty pages percentage to zero:
: E) j, [1 S" _2 z: ]/ yMariaDB [(none)]> set global innodb_max_dirty_pages_pct=0;
( L' o: T- O. Q2 \9 kQuery OK, 0 rows affected (0.00 sec)
6 B( s7 y8 @! z/ O# ]
3.确保所有后台进程已经完成自己的工作，也是重要的。
" E* t( ]& P) b( F/ m* z* n注意，插入缓冲线程，它的大小等于1
0 o  U( C7 M2 h# T# m6 }; [-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2,
0 inserts, 0 merged recs, 0 merges
Hash table size 34679, node heap has 1 buffer(s)
$ P6 B# o- l" ~0.00 hash searches/s, 0.00 non-hash searches/s
$ k% w) |4 _/ S' K8 E, I5 a
6 L" _3 x+ F) s+ X4.后台写进程purge thread，清除所有事务。
: K9 v$ w0 A: `" s------------
! `+ }$ y  v9 L2 c7 H2 ]6 c$ @TRANSACTIONS
------------
/ p+ X. `0 K4 L1 }% J! f9 U8 ?Trx id counter 0 784
Purge done for trx's n:o < 0 0 undo n:o < 0 0
; Y( W% L: j6 O但是，如果上次事务没有需要清理操作Trx id计数比较大(如,SELECT)，
* @+ x& E0 y0 P: G3 L& k: A在这种情况下，至少要保证InnoDB不再做任何写动作。
; m- \$ F( D' o--------
9 H* I: [$ q" L  |* F' EFILE I/O
--------
1 m% H3 Q1 Y1 L$ @" X9 V2 K  ZI/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
& ?# v/ }+ J* X" A# \* W* KI/O thread 2 state: waiting for i/o request (read thread)
2 N7 S7 f) V) \' B) iI/O thread 3 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
2 x7 V* o. ]1 V$ _; s8 u0 OS file reads, 81 OS file writes, 59 OS fsyncs
% w3 b% F: Z- [. ~% `# L0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s

经历了4步，所有被修改脏页刷新到磁盘，现在开始copy InnoDB 文件到源目录:
# p# t3 J* Y( `) P) L! p[root@mysql ~]# cp /proc/$(cat /opt/mysql/data2/mysql.pid)/fd/4 /opt/mysql/data2/ibdata1
[root@mysql ~]# cp /proc/$(cat /opt/mysql/data2/mysql.pid)/fd/9 /opt/mysql/data2/ib_logfile0
5 v- O0 _* D. D[root@mysql ~]# cp /proc/$(cat /opt/mysql/data2/mysql.pid)/fd/10 /opt/mysql/data2/ib_logfile1

5.修改ib*所属用户
* s8 a) I! f( Mchown -R mysql ib*

6 H* \/ q6 g. R3 M  J: @6.重启MySQLd
0 Q$ d0 [6 |7 O  z, z........
; \8 i5 w3 @! I- a9 c( _) V
结论：
- o1 B9 q" T2 S! ?- k; ^1.监控InnoDB文件 ibdata 和 ib_logfile* 是否存在
2.清楚恢复策略，否则不要重启MySQLd

admin

于是再/ect/my.cnf中加入max_connections=1000    wait_timeout=5这两个配置



重启mysql，启动成功，但是项目却无法打开，又重新打开mysql日志发现他一直无休止的重启，百度搜了好多办法都不行
8 m5 V9 D, h9 }8 m' |) A3 A
5 m9 P* B! L( E( w! k' W后来看到这段配置
/ e# Q4 ?- L- [* {0 ?) m
" i) V6 T" E- K9 U& x& j2 V- {6 }
/ W. X: N/ Z. z; ^5 J' k( ^; h
# z7 }6 U2 \, s+ f9 m我想应该是因为文件问题导致ibdata1损坏了，然后从1 到6全部都试了一遍，效果却是然并卵
1 \5 G, Y( p5 |' [% }1 [
3 T& {3 G; }# q$ z到最后是这样配置的
2 p  y9 E: R" o: i& Q* X
https://img-blog.csdn.net/20180511171205193?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dsX2FuZw==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
1 |! a! G9 A2 t. S1 \- ], ?
然后重启mysql没有问题，然后打开项目发现还是访问不了，后来发现tomcat停了，重启tomcat，完美解决
) ^! F; R0 E. q* y1 p

admin

操作步骤：

6 Y/ b: @. R/ H" t# u. T+ Y                               
登录/注册后可看大图

admin

概念：
事務日誌或稱redo日誌，在mysql中默認以ib_logfile0,ib_logfile1名稱存在,可以手工修改參數，調節開啟幾組日誌來服務於當前mysql數據庫,mysql采用順序，循環寫方式，每開啟一個事務時，會把一些相關信息記錄事務日誌中(記錄對數據文件數據修改的物理位置或叫做偏移量);
5 L' g& k9 J1 [6 s& a這個系列文件個數由參數innodb_log_files_in_group控制，若設置為4，則命名為ib_logfile0~3。
這些文件的寫入是順序、循環寫的，logfile0寫完從logfile1繼續，logfile3寫完則logfile0繼續。
! }5 y+ p% U; p0 y' f6 O! L
8 B! f) s2 Q+ m/ `+ d$ H+ L- ~作用:
在系統崩潰重啟時，作事務重做；在系統正常時，每次checkpoint時間點，會將之前寫入事務應用到數據文件中。

1 O) e$ }+ Y* T# I! [- q' jIb_logfile的checkpoint field
/ k. B# V5 E2 T; L7 o7 n4 O" M8 ~實際上不僅要記錄checkpoint做到哪兒（LOG_CHECKPOINT_LSN），還要記錄用到了哪個位置（LOG_CHECKPOINT_OFFSET）等其他信息。所以在ib_logfile0的頭部預留了空間，用於記錄這些信息。
$ R' X( H0 [7 R* {7 B$ `因此即使使用後面的logfile，每次checkpoint完成後，ib_logfile0都是要更新的。同時你會發現所謂的順序寫盤，也並不是絕對的
4 Y( Z+ W( A  u2 ]5 A) F! \) k, c相關的一些數字
a) InnoDB留了兩個checkpoint filed，按照註釋的解釋，目的是為了能夠“write alternately”
6 s' \/ |# ~1 I& H  k+ W. @b) 每個checkpint field需要的大小空間為304字節。(相關定義在log0log.h)
, \! @" x5 ^/ ^. fc) 第一個checkpoint的起始位置在ib_logfile0的第512字節(OS_FILE_LOG_BLOCK_SIZE)處；
$ }% x1 y5 Z- M3 g' ]  i8 Fd) 第二個在1536 (3 * OS_FILE_LOG_BLOCK_SIZE)字節處。

# z# @+ ^- ~- j/ W7 S) d8 p( D
特點：
redo log只是記錄所有innodb表數據的變化。
redo log只是記錄正在執行中的dml以及ddl語句。
redo log可以作為異常down機或者介質故障後的數據恢復使用

引入一個問題：在m/s環境中,innodb寫完ib_logfile後,服務異常關閉，會不會主庫能用ib_logfile恢復數據，而binlog沒寫導致從庫同步時少了這個事務？從而導致主從不一致;redo日誌寫入方式：1.ib_logfile寫入當前事務更新數據，並標上事務準備trx_prepare2.寫入bin-log3.ib_logfile當前事務提交提交trx_commit恢復方式:如果ib_logfile已經寫入事務準備,那麽在恢復過程中，會依據bin-log中該事務是否存在恢復數據。假設:1）結束後異常,因沒有寫入bin-log，從庫不會同步這個事務，主庫上，重啟時，在恢復日誌中這個事務沒有commit，即rollback這個事務.2）結束後異常，這會bin-log已經寫入，從庫會同步這個事務。主庫依據恢復日誌和bin-log，也正常恢復此事務綜上描述:bin-log寫入完成，主從會正常完成事務；bin-log沒有寫入，主從庫rollback事務;不會出現主從庫不一致問題.
相關參數（全局&靜態）:innodb_log_buffer_sizeinnodb_log_file_sizeinnodb_log_files_in_groupinnodb_log_group_home_dirinnodb_flush_log_at_trx_commitinnodb_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能力足夠支持業務，如充值消費，敏感業務;
5 P! A5 [+ N( k, i7 M3 J2 z

引入ib_logfile的寫入策略

1、基本概念
6 q0 l; T& U; F( ~2 y0 N7 l& |a)、ib_logfile文件個數由innodb_log_files_in_group配置決定，若為2，則在datadir目錄下有兩個文件，命令從0開始，分別為ib_logfile0和ib_logfile.
1 G/ ?$ k+ j# ]) c- S9 ^! L# Z" Qb)、文件為順序寫入，當達到最後一個文件末尾時，會從第一個文件開始順序復用。
c)、lsn: Log Sequence Number，是一個遞增的整數。 Ib_logfile中的每次寫入操作都包含至少1個log，每個log都帶有一個lsn。在內存page修復過程中，只有大於page_lsn的log才會被使用。
, W" X1 k6 r. @d)、lsn的保存在全局變量log_sys中。遞增數值等於每個log的實際內容長度。即如果新增的一個log長度是len，則log_sys->lsn += len.
e)、ib_logfile每次寫入以512（OS_FILE_LOG_BLOCK_SIZE）字節為單位。實際寫入函數 log_group_write_buf (log/log0log.c)
' t1 O6 V& o3 x! ^  e/ I+ Of)、每次寫盤後是否flush，由參數innodb_flush_log_at_trx_commit控制。
! F# K5 z' e0 z4 Q' M
; p5 n! Y$ a& `  A6 Z$ b
: ^& m1 \. ?# D  e6 ]0 C" |2、log_sys介紹
log_sys是一個全局內存結構。以下說明幾個成員的意義。

lsn	表示已經分配的最後一個lsn的值。
written_to_all_lsn	n表示實際已經寫盤的lsn。需要這個值是因為並非每次生成log後就寫盤。
flushed_to_disk_lsn	表示刷到磁盤的lsn。需要這個值是因為並非每次寫盤後就flush。
buf	待寫入的內容保存在buf中
buf_size	buf的大小。由配置中innodb_log_buffer_size決定，實際大小為innodb_log_buffer_size /16k * 16k。
buf_next_to_write	buf中下一個要寫入磁盤的位置
buf_free	buf中實際內容的最後位置。當buf_free> buf_next_to_write時，說明內存中還有數據未寫盤。

' p+ U$ K: _! u/ u7 c( t

3、相關更新
  {: x- Y5 ?& q5 a用一個簡單的更新語句來說明log_sys以及ib_logfile的更新內容的過程。假設我們的更新只涉及到非索引的固定長度字段。
" n1 ~" t9 y7 G* n+ g8 Oa) 在bufferpool中寫入undo log。 對於一個單一的語句，需要先創建一個undolog頭。
b) 在bufferpool中寫入undo log的實際內容。
1 Y  g* Y# m5 N# F5 O/ t3 A% D/ cc) 在log_sys->buf中寫入buffer page的更新內容。此處保存了更新的完整信息。
d) 在log_sys->buf中寫入啟動事務（trx_prepare）的日誌
1 I  k; f! h% l! Le) 將c、d更新的log內容寫入ib_logfile中。
f) 在log_sys->buf中寫入事務結束(trx_commit)的日誌
g) 將f步驟的log內容寫入ib_logfile中。
/ w" Z- T7 T$ }) t% p
! f1 N6 X/ ]2 `7 u& `  E0 ]% ]3 h- {4、說明
a) 完成上述所有操作時，數據文件還沒有更新。
b) 每次寫入log_sys->buf時同時更新lsn和buf_free。 每次寫ib_logfile時同時更新written_to_all_lsn和buf_next_to_write；
c) 每次寫ib_logfile時以512字節為對齊，如需寫入600字節，則實際寫入1k。寫到最後一個文件末尾則從第一個文件重復使用。
d) 從上述流程看到，在a～d過程中若出現異常關閉，由於沒有寫入到磁盤中，因此整個事務放棄；若在e剛完成時出現異常關閉，雖然事務內容已經寫盤，但沒有提交。在重啟恢復的時候，發現這個事務還沒有提交，邏輯上整個事務放棄。 （重啟日誌中會有Found 1 prepared transaction(s) in InnoDB字樣）。在g完成後出現異常關閉，則能夠在重啟恢復中正常提交。

- _& k3 ^: C1 _' g; h2 B5 h在e和f之間會寫mysql的bin-log，若bin-log寫完前異常關閉，事務無效，bin-log寫入成功後，則異常重啟後能夠根據bin-log恢復事務的修改。
9 ^& ?6 Z( \: E9 G: E
5 \1 Z  T0 M: o9 A8 J6 j% q; [+ ie) 若涉及到索引更新，在步驟c之後會增加索引更新的log。由於索引可能有merge過程，因此在merge過程中會另外增加寫入一個log。但事務完全提交仍在步驟g中。索引的更新由於已經寫盤，並不會因此丟失。

admin

ib_logfile0 记录系统的回滚，重做日志。
& Q( t5 J8 z! T  W0 W
& u8 p! v- A8 p6 Amysql-bin.000011 系统的所有更新记录。


1 T1 _) o1 A% G) ?2 P4 p( Y$ T如果需要更详细的则建议看一下数据库原理方面的教材，应该有一个章节讲这个redo,undo 日志的。
! N. q8 s, X# c,ib_logfile0是重做日志，记录的是文件的物理更改         
, Z8 E9 h) k+ d) hmysql-bin.000011是数据库更新日志  记录的是逻辑更改
0 u2 R0 {5 P* d. ?0 F' h; o
,
& d1 l1 D3 ^2 K+ V/ Wib_logfile0是重做日志，也就是 在你修改数据之前，会先把 修改的操作 作为日志先记录下来。
        
mysql-bin.000011是二进制日志，格式是二进制的，但是这个日志更加有用，比如 在我们做 数据库的主从复制时，这个二进制日志就是关键，mysql会把日志发送到slave，salve会接收日志，然后解析日志，把里面的sql语句重新应用到数据库里，于是就能同步数据了。
,ib_logfile0：记录的是redo log和undo log的信息，这里记录的基本是commit之前的数据。

mysql-bin.000011：记录的是已经执行完毕的对数据库的dml和ddl信息，这里记录的基本是commit之后的数据信息。