Delete misuse sometimes unexpected, if you have a good habit of data backup table, then at least you can recover that data before the backup. If we open the binlog mysql, then the data can be recovered by its incremental operating log. How to open the binlog prequel has been explained, for example Here's how to recover through binlog:
1, look at the current binlog position, referred to herein as position 1:
mysql> show master status; +---------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---------------------+----------+--------------+------------------+-------------------+ | mysql-binlog.000001 | 529 | | | | +---------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.01 sec)
2, DML operations, create a test table, insert two data misuse removed one of:
mysql> create table t_test( -> name varchar(50) default null); Query OK, 0 rows affected (0.06 sec) mysql> insert into t_test values('wlf'); Query OK, 1 row affected (0.01 sec) mysql> insert into t_test values('wms'); Query OK, 1 row affected (0.01 sec) mysql> delete from t_test where name = 'wlf'; Query OK, 1 row affected (0.01 sec)
3, now look binlog position, referred to herein as position 2:
mysql> show master status; +---------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---------------------+----------+--------------+------------------+-------------------+ | mysql-binlog.000001 | 1496 | | | | +---------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)
4, if we want to restore the deleted piece of data, you should know that as of the moment to the location where the number is deleted before, and this position must lie between position 1 (ie, 529) and 2 (ie, 1496):
mysql> show binlog events in 'mysql-binlog.000001' from 529; +---------------------+------+----------------+-----------+-------------+-----------------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +---------------------+------+----------------+-----------+-------------+-----------------------------------------------------------------+ | mysql-binlog.000001 | 529 | Anonymous_Gtid | 1 | 594 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | mysql-binlog.000001 | 594 | Query | 1 | 719 | use `test`; create table t_test( name varchar(50) default null) | | mysql-binlog.000001 | 719 | Anonymous_Gtid | 1 | 784 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | mysql-binlog.000001 | 784 | Query | 1 | 856 | BEGIN | | mysql-binlog.000001 | 856 | Table_map | 1 | 907 | table_id: 109 (test.t_test) | | mysql-binlog.000001 | 907 | Write_rows | 1 | 947 | table_id: 109 flags: STMT_END_F | | mysql-binlog.000001 | 947 | Xid | 1 | 978 | COMMIT /* xid=11 */ | | mysql-binlog.000001 | 978 | Anonymous_Gtid | 1 | 1043 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | mysql-binlog.000001 | 1043 | Query | 1 | 1115 | BEGIN | | mysql-binlog.000001 | 1115 | Table_map | 1 | 1166 | table_id: 109 (test.t_test) | | mysql-binlog.000001 | 1166 | Write_rows | 1 | 1206 | table_id: 109 flags: STMT_END_F | | mysql-binlog.000001 | 1206 | Xid | 1 | 1237 | COMMIT /* xid=12 */ | | mysql-binlog.000001 | 1237 | Anonymous_Gtid | 1 | 1302 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' | | mysql-binlog.000001 | 1302 | Query | 1 | 1374 | BEGIN | | mysql-binlog.000001 | 1374 | Table_map | 1 | 1425 | table_id: 109 (test.t_test) | | mysql-binlog.000001 | 1425 | Delete_rows | 1 | 1465 | table_id: 109 flags: STMT_END_F | | mysql-binlog.000001 | 1465 | Xid | 1 | 1496 | COMMIT /* xid=13 */ | +---------------------+------+----------------+-----------+-------------+-----------------------------------------------------------------+ 17 rows in set (0.02 sec)
We see 594-719 was built tables , 719-978 is the first insert statements , 978-1237 is the second insert statements , 1237-1465 is accidently delete statement to insert the data first . We already know that the moment for incremental recovery log delete operations as of the position, it is clear that 1237, the start position it? Before performing recovery, we recognize the current t_test only one data:
mysql> select * from t_test; +------+ | name | +------+ | wms | +------+ 1 row in set (0.01 sec)
Then we began to look at from 594 to recover what would be the result of:
D:\Dev\mysql\mysql-5.7.26-winx64\data>mysqlbinlog mysql-binlog.000001 --start-position 594 --stop-position 1237 | mysql -u root -p test Enter password: ********* ERROR 1050 (42S01) at line 25: Table 't_test' already exists
Incorrect report, because we t_test table already exists, of course, build tables repeat the error. Then resume the starting position we should skip the build table statements, you can start with 719, one more time:
D:\Dev\mysql\mysql-5.7.26-winx64\data>mysqlbinlog mysql-binlog.000001 --start-position 719 --stop-position 1237 | mysql -u root -p test Enter password: ********* D:\Dev\mysql\mysql-5.7.26-winx64\data>
This time there is no error, we went to look at the database if the data recovery:
mysql> select * from t_test; +------+ | name | +------+ | wms | | wlf | | wms | +------+ 3 rows in set (0.00 sec)
Oh, only the first restoration data is in error, but also the repeated insertion of second data. How to solve it? There are two ways: the first is directly t_test also drop off, and then perform our once restored, will be performed from the table to build the first, second insert; the second is our only way to recover is first inserted, It is executed only 719-978. But if we have a lot of data is accidentally deleted, you can not know the precise location from which the recovery start to the end of the operation which position, it does not matter, we can recover based on time, the --start-position and --stop- --start-datetime into positon and --stop-datetime.
Above mysqlbinlog binlog command is located in the log (such as mysql-binlog.000001 example) directory execution, the latter test is my database name. Finally, we come by a way to do this once:
First drop table
mysql> drop table t_test; Query OK, 0 rows affected (0.05 sec)
594-1237 recover again from scratch:
D:\Dev\mysql\mysql-5.7.26-winx64\data>mysqlbinlog mysql-binlog.000001 --start-position 594 --stop-position 1237 | mysql -u root -p test Enter password: ********* D:\Dev\mysql\mysql-5.7.26-winx64\data>
Data has now returned to normal:
mysql> select * from t_test; +------+ | name | +------+ | wlf | | wms | +------+ 2 rows in set (0.00 sec)