binlog增量備份需要注意的地方，會(huì)死人的�。�！

justin033

最近公司備份方式在調(diào)整，采用周日全庫(kù)+每小時(shí)binlog增量備份。我這里說(shuō)下有兩點(diǎn)需要注意的地方，體現(xiàn)了mysql在備份功能的差強(qiáng)人意�？隙ㄟ�有方面，歡迎大家的經(jīng)驗(yàn)和心得


1. 用到臨時(shí)表時(shí)，恢復(fù)binlog需要注意，只能在一個(gè)session里恢復(fù)所有binlog文件的數(shù)據(jù)。因?yàn)榕R時(shí)表只存在于單個(gè)session時(shí)間

2. 針對(duì)5.0版本的，一定要注意statement binlog模式對(duì)create table b select * from a; 只能記錄語(yǔ)句而不是數(shù)據(jù)。如果表a刪除了，恢復(fù)表b的數(shù)據(jù)就麻煩了

###剛開(kāi)始binlog_format為row
create table tbl_a (a int)
/*!*/;
# at 195
#100422 23:23:20 server id 1  end_log_pos 263   Query   thread_id=1     exec_tim
e=0     error_code=0
SET TIMESTAMP=1271949800/*!*/;
BEGIN
/*!*/;
# at 263
# at 307
#100422 23:23:20 server id 1  end_log_pos 307   Table_map: `test`.`tbl_a` mapped
to number 135
#100422 23:23:20 server id 1  end_log_pos 351   Write_rows: table id 135 flags:
STMT_END_F

BINLOG '
6GnQSxMBAAAALAAAADMBAAAAAIcAAAAAAAAABHRlc3QABXRibF9hAAEDAAE=
6GnQSxcBAAAALAAAAF8BAAAQAIcAAAAAAAEAAf/+AQAAAP4CAAAA/gMAAAA=
'/*!*/;
# at 351
#100422 23:23:20 server id 1  end_log_pos 420   Query   thread_id=1     exec_tim
e=0     error_code=0
SET TIMESTAMP=1271949800/*!*/;
COMMIT
/*!*/;
# at 420
#100422 23:24:43 server id 1  end_log_pos 488   Query   thread_id=1     exec_tim
e=0     error_code=0
SET TIMESTAMP=1271949883/*!*/;
BEGIN
/*!*/;
# at 488


###binlog_format沒(méi)變，通過(guò)create table select from來(lái)創(chuàng)建表。在row_based mode下。創(chuàng)建的語(yǔ)句，變成先創(chuàng)建表再插入值
#100422 23:24:43 server id 1  end_log_pos 602   Query   thread_id=1     exec_tim
e=0     error_code=0
SET TIMESTAMP=1271949883/*!*/;
CREATE TABLE `tbl_b` (
  `a` int(11) DEFAULT NULL
)
/*!*/;
# at 602
# at 646
#100422 23:24:43 server id 1  end_log_pos 646   Table_map: `test`.`tbl_b` mapped
to number 136
#100422 23:24:43 server id 1  end_log_pos 690   Write_rows: table id 136 flags:
STMT_END_F

BINLOG '
O2rQSxMBAAAALAAAAIYCAAAAAIgAAAAAAAAABHRlc3QABXRibF9iAAEDAAE=
O2rQSxcBAAAALAAAALICAAAQAIgAAAAAAAEAAf/+AQAAAP4CAAAA/gMAAAA=
'/*!*/;
# at 690
#100422 23:24:43 server id 1  end_log_pos 759   Query   thread_id=1     exec_tim
e=0     error_code=0
SET TIMESTAMP=1271949883/*!*/;
COMMIT
/*!*/;

###接著把session的binlog_format設(shè)置成statement，通過(guò)create table select from來(lái)創(chuàng)建表。對(duì)create table b select * from a; 只能記錄語(yǔ)句而不是數(shù)據(jù)
# at 759
#100422 23:27:57 server id 1  end_log_pos 860   Query   thread_id=1     exec_tim
e=1     error_code=0
SET TIMESTAMP=1271950077/*!*/;
create table tbl_c select * from tbl_a
/*!*/;

###最后把session的binlog_format設(shè)置成mixed，通過(guò)create table select from來(lái)創(chuàng)建表。對(duì)create table b select * from a; 只能記錄語(yǔ)句而不是數(shù)據(jù)
# at 860
#100422 23:30:04 server id 1  end_log_pos 961   Query   thread_id=1     exec_tim
e=0     error_code=0
SET TIMESTAMP=1271950204/*!*/;
create table tbl_d select * from tbl_a
/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

andkylee

怎么個(gè)死法？

justin033

1. 用到臨時(shí)表時(shí)，恢復(fù)binlog需要注意，只能在一個(gè)session里恢復(fù)所有binlog文件的數(shù)據(jù)。因?yàn)榕R時(shí)表只存在于單個(gè)session時(shí)間

--- 如果用到臨時(shí)表的事務(wù)數(shù)據(jù)跨了多個(gè)binlog文件，就得用一個(gè)session恢復(fù)此多個(gè)binlog文件


2. 針對(duì)5.0版本的，一定要注意statement binlog模式對(duì)create table b select * from a; 只能記錄語(yǔ)句而不是數(shù)據(jù)。如果表a刪除了，恢復(fù)表b的數(shù)據(jù)就麻煩了

--- 如果是statement based binlog，這樣種情況你就得先恢復(fù)a表再恢復(fù)b表

andkylee

回復(fù) 3# justin033


    create table b select * from a; 只能記錄語(yǔ)句而不是數(shù)據(jù)。如果表a刪除了，恢復(fù)表b的數(shù)據(jù)就麻煩了


表a被刪除，難道表b也被刪除了？


這樣的話，和這條 create table b select * from a語(yǔ)句就沒(méi)有關(guān)系了。


直接轉(zhuǎn)到另外一個(gè)問(wèn)題：　如何利用日志恢復(fù)誤操作導(dǎo)致的表b被刪除？

yueliangdao0608

分析的很好，鼓勵(lì)下。

lh0365

樓主牛啊。這些天一直在研究MYSQL的增量備份，不知道大家有沒(méi)有好的方法

ruochen

LZ很不錯(cuò)

最近學(xué)習(xí)的盡頭很足啊，希望能多多記筆記，然后共享出來(lái)

vitas333_cu

臨時(shí)表的意思？？  恢復(fù)的話 還得如何操作？？