碼上快樂

相關內容    簡體    繁體

MySQL binlog 的恢復操作

本文轉載自   查看原文   2017-09-22 13:25   1078    MySQL binlog 恢復數據/ MySQL備份主從復制
 測試出有個問題：mysqlbinlog 不加任何參數 恢復整個binlog 日志文件發現里面有這個操作 SET @@SESSION.GTID_NEXT 的操作，
 如果需要恢復文件的時候就需要把他過濾掉，否則恢復數據不成功
 
測試環境：./mysql  Ver 14.14 Distrib 5.7.19
結論：需要用binlog 日志還原數據記錄的時候，備份好自己的binlog 日志以后，然后執行 reset master，然后在直接導入我們mysqlbinlog 導出的文件。
         或者導入的時候加入-f 參數強行導入
 
測試步驟如下：
測試表結構 
CREATE TABLE `t1` (
  `id` int(60) NOT NULL AUTO_INCREMENT,
  `name` varchar(20) NOT NULL DEFAULT '',
  `age` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8

 

1 insert into t1 values(1,'xiaoxiao',20),(2,'huahua',21),(3,'lili',22);  ###mysqb-bin.0000001
2 flush logs
3 insert into t1 values(4,'xiaohong',18);  # mysql-bin.000002
  insert into t1 values(5,'aying',22);
4 flush logs
5  delete from t1 where id<4;   #mysql-bin.000003

 

 這個時候我們看到我們有了3個binlog文件 
show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       499 |
| mysql-bin.000002 |       774 |
| mysql-bin.000003 |       194 |
+------------------+-----------+

 

 /usr/local/mysql/bin/mysqlbinlog --start-position=219  mysql-bin.000001 >/tmp/ok.txt

###查看以下是日志信息

 

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#170922 10:14:10 server id 2003309  end_log_pos 123 CRC32 0x509b4a7a    Start: binlog v 4, server v 5.7.19-log created 170922 10:14:10 at startup
ROLLBACK/*!*/;
BINLOG '
8nHEWQ9tkR4AdwAAAHsAAAAAAAQANS43LjE5LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADyccRZEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AXpKm1A=
'/*!*/;
# at 219
#170922 10:19:50 server id 2003309  end_log_pos 290 CRC32 0x5073a29d    Query   thread_id=183   exec_time=0     error_code=0
SET TIMESTAMP=1506046790/*!*/;
SET @@session.pseudo_thread_id=183/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 290
#170922 10:19:50 server id 2003309  end_log_pos 338 CRC32 0xca27d49b    Table_map: `zst`.`t1` mapped to number 223
# at 338
#170922 10:19:50 server id 2003309  end_log_pos 421 CRC32 0xacc98577    Write_rows: table id 223 flags: STMT_END_F

BINLOG '
RnPEWRNtkR4AMAAAAFIBAAAAAN8AAAAAAAEAA3pzdAACdDEAAwMPAwI8AASb1CfK
RnPEWR5tkR4AUwAAAKUBAAAAAN8AAAAAAAEAAgAD//gBAAAACHhpYW94aWFvFAAAAPgCAAAABmh1
YWh1YRUAAAD4AwAAAARsaWxpFgAAAHeFyaw=
'/*!*/;
# at 421
#170922 10:19:50 server id 2003309  end_log_pos 452 CRC32 0x57228b9c    Xid = 3692
COMMIT/*!*/;
# at 452
#170922 10:20:02 server id 2003309  end_log_pos 499 CRC32 0xe31d7a38    Rotate to mysql-bin.000002  pos: 4
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
/usr/local/mysql/bin/mysqlbinlog -v  mysql-bin.000001 >/tmp/faile.txt

#### 查看以下的日志信息
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#170922 10:14:10 server id 2003309  end_log_pos 123 CRC32 0x509b4a7a    Start: binlog v 4, server v 5.7.19-log created 170922 10:14:10 at startup
ROLLBACK/*!*/;
BINLOG '
8nHEWQ9tkR4AdwAAAHsAAAAAAAQANS43LjE5LWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAADyccRZEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AXpKm1A=
'/*!*/;
# at 123
#170922 10:14:10 server id 2003309  end_log_pos 154 CRC32 0x2a8835fb    Previous-GTIDs
# [empty]
# at 154
#170922 10:19:50 server id 2003309  end_log_pos 219 CRC32 0xbf230db3    GTID    last_committed=0        sequence_number=1       rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= '6fb6a0c6-9dd2-11e7-a4e8-0050569c404d:1'/*!*/;        #### 這個操作，直接導致恢復整個日志文件會出錯。
# at 219
#170922 10:19:50 server id 2003309  end_log_pos 290 CRC32 0x5073a29d    Query   thread_id=183   exec_time=0     error_code=0
SET TIMESTAMP=1506046790/*!*/;
SET @@session.pseudo_thread_id=183/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 290
#170922 10:19:50 server id 2003309  end_log_pos 338 CRC32 0xca27d49b    Table_map: `zst`.`t1` mapped to number 223
# at 338
#170922 10:19:50 server id 2003309  end_log_pos 421 CRC32 0xacc98577    Write_rows: table id 223 flags: STMT_END_F

BINLOG '
RnPEWRNtkR4AMAAAAFIBAAAAAN8AAAAAAAEAA3pzdAACdDEAAwMPAwI8AASb1CfK
RnPEWR5tkR4AUwAAAKUBAAAAAN8AAAAAAAEAAgAD//gBAAAACHhpYW94aWFvFAAAAPgCAAAABmh1
YWh1YRUAAAD4AwAAAARsaWxpFgAAAHeFyaw=
'/*!*/;
### INSERT INTO `zst`.`t1`
### SET
###   @1=1
###   @2='xiaoxiao'
###   @3=20
### INSERT INTO `zst`.`t1`
### SET
###   @1=2
###   @2='huahua'
###   @3=21
### INSERT INTO `zst`.`t1`
### SET
###   @1=3
###   @2='lili'
###   @3=22
# at 421
#170922 10:19:50 server id 2003309  end_log_pos 452 CRC32 0x57228b9c    Xid = 3692
COMMIT/*!*/;
# at 452
#170922 10:20:02 server id 2003309  end_log_pos 499 CRC32 0xe31d7a38    Rotate to mysql-bin.000002  pos: 4
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

 

./mysql -h127.0.0.1 -P3309 -uroot -p </tmp/ok.txt  （ 因為我們導出的時候是基於位置點的，所有我們跳過了gtid）
能夠還原出刪除的數據
./mysql -h127.0.0.1 -P3309 -uroot -p </tmp/faile.txt（里面有SET @@SESSION.GTID_NEXT= '6fb6a0c6-9dd2-11e7-a4e8-0050569c404d:1 所以我們需要跳過GTID ）
不能夠還原刪除的數據
 
把 faile.txt 導出文件里面 SET @@SESSION.GTID_NEXT= '6fb6a0c6-9dd2-11e7-a4e8-0050569c404d:1'/*!*/; 刪除或者注釋掉可以恢復刪除的數據
 
解決辦法：1：像剛才我們看到的日志一樣，我們需要把SET @@SESSION.GTID_NEXT= '6fb6a0c6-9dd2-11e7-a4e8-0050569c404d:1'/*!*/; 
 跳過進行了，比如說我們把日志里面過濾掉或者注釋掉在導入是能成功的。
 
 2：在導入前我們需要reset我們的所有日志文件，在reset  master log之前，請備份好自己的日志文件，否則后果可能很慘。
 或者加入 -f 參數強制導入 這樣在導入。
 
所以問題的重點是GTID，至於這么操作根據自己的實際情況來恢復數據吧。
 
 


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 binlog2sql實現MySQL誤操作的恢復 binlog2sql實現MySQL誤操作的恢復 MySQL利用binlog恢復誤操作數據 Mysql之binlog日志說明及利用binlog日志恢復數據操作記錄 MySQL 之binlog日志說明及利用binlog日志恢復數據操作記錄 mysql通過binlog恢復數據 Mysql binlog 數據恢復 mysql關於binlog日志的操作 Mysql使用binlog恢復數據解決誤操作問題的兩種方法 利用mysql的binlog恢復數據
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM