A demonstration environment Description:
The system CentOS Linux release 7.2.1511 (Core) X_86 64 mounted on Least of
mysql binary version is the official version 5.7.22-22, mysql uses binary installation, open two instances on a single mysql, mysql instance to start a timer event_scheduler = ON. Further examples 2 to be turned mysql gtid
xtrabackup uses rpm package, version version 2.4.13
MySQL Backup mode once a day full backup and incremental backup binlog
Second, delete the simulation library, data recovery demo:
Tip: Of course here is to demonstrate, non-library creation environment delete, delete table simulation, you know the consequences
Fault simulation:
online testdb test1_event accidentally deleted a table in the library, using the full backup of mysql + day of the day produced the mysql binlog file to restore data to the previous data mistakenly deleted the table test1_event
restoration Description:
official recommended use mysql binlog restoration, production proven this method has been the official is not rigorous practice of the (official following method is recommended)
Recovery process is as follows:
2.1 received accidentally deleted before, probably the first time confirmed that misuse time
2.2 Login to see the current main library binlog position of the point (to remember at this time binlog file that will be used when restoring back)
(root@'mgr01':mysql3306.sock)[testdb]>show master status\G
*************************** 1. row ***************************
File: mysql-bin.000005
Position: 15211
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: bde7b592-b966-11e9-8c64-000c294f3e61:1-10445
1 row in set (0.00 sec)2.3 is the next best flush logs, make the next sql binlog file written to a new
location targeting 2.4 point drop table statement where binglog file:
[root@mgr01 binlog]# mysqlbinlog -v --base64-output=decode-rows /data/mysql/mysql3306/binlog/mysql-bin.000005|grep -i -C 15 drop
### @1=10422
### @2='tomcat'
### @3='xiaohuahua'
### @4='2019-08-08 14:22:18'
# at 14987
#190808 14:22:18 server id 63306 end_log_pos 15018 CRC32 0x873943dd Xid = 20695
COMMIT/*!*/;
#at15018###################################
#190808 14:22:19 server id 63306 end_log_pos 15083 CRC32 0xcc8773ce GTID last_committed=34 sequence_number=35 rbr_only=no
SET @@SESSION.GTID_NEXT= 'bde7b592-b966-11e9-8c64-000c294f3e61:10445'/*!*/;
#at 15083
#190808 14:22:19 server id 63306 end_log_pos 15211 CRC32 0x8d445019 Query thread_id=7213 exec_time=0 error_code=0
use `testdb`/*!*/;
SET TIMESTAMP=1565245339/*!*/;
SET @@session.sql_auto_is_null=0/*!*/;
DROP TABLE `test1_event` /* generated by server */
/*!*/;
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*/;15018 to locate the position of the point is to use the end point of the binlog file recovery
2.5 xtrabackup backup to restore mysql3308 Example:
Tip: mysql 3308 instance to open the Gtid
Restore the backup command:
innobackupex --apply-log /data/backup/db_3306_20190808/
innobackupex --defaults-file=/data/mysql/mysql3308/my3308.cnf --copy-back /data/backup/db_3306_20190808/To the data directory data mysql permissions:
chown -R mysql.mysql /data/mysql/mysql3308/data/Start mysql3308 example:
/usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/mysql3308/my3308.cnf &
View to return to the 3308 instance data, but did not get back in the drop table test1_event this time period there are still a lot of missing data back to the database 3306, binlog file from the increment in the back:
| 10273 | tomcat | xiaohuahua | 2019-08-08 14:17:16 |
| 10274 | tomcat | xiaohuahua | 2019-08-08 14:17:18 |
+-------+----------+------------+---------------------+
(root@'mgr01':mysql3308.sock)[testdb]>select count(*) from test1_event;
+----------+
| count(*) |
+----------+
| 10273 |
+----------+
1 row in set (0.00 sec)xtrabackup backup is on Gtid, so the following when restoring data, to add a parameter --skip-gtids ignored Gtid information binlog files using mysqlbinlog command incremental binglog file, if no parameter --skip-gtids recovery then, resulting in data recovery less than 3308 library
The correct recovery command as follows:
mysqlbinlog /data/mysql/mysql3306/binlog/mysql-bin.000001 --skip-gtids |mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog /data/mysql/mysql3306/binlog/mysql-bin.000002 --skip-gtids |mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog /data/mysql/mysql3306/binlog/mysql-bin.000003 --skip-gtids |mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog /data/mysql/mysql3306/binlog/mysql-bin.000004 --skip-gtids |mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog /data/mysql/mysql3306/binlog/mysql-bin.000005 --stop-position="15018" --skip-gtids |mysql -f --binary-mode -S /tmp/mysql3308.sock Parameters:
--skip-gtids ignore Gtid information binlog file
--binary-mode mainly to solve the problem of Chinese garbled or a special string garbled
-f forced recovery, ignoring error
After executing the above command, the data can be restored to delete the table before the test1_event
The following command can result in data recovery can not restore mysql instance on 3308 :( because my3308 example opened Gtid parameters caused)
mysqlbinlog /data/mysql/mysql3306/binlog/mysql-bin.000001 |mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog /data/mysql/mysql3306/binlog/mysql-bin.000002 |mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog /data/mysql/mysql3306/binlog/mysql-bin.000003 |mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog /data/mysql/mysql3306/binlog/mysql-bin.000004 |mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog --stop-position="15018" /data/mysql/mysql3306/binlog/mysql-bin.000005|mysql -f --binary-mode -S /tmp/mysql3308.sock
2.6 If before starting a new instance mysql3308 closed off from the my3308.cnf Gtid parameters:
3.
In this case use mysqlbinlog /data/mysql/mysql3306/binlog/mysql-bin.00000* | mysql -f --binary-mode -S /tmp/mysql3308.sock can restore the data to the 3308 mysql instance, but during error recovery. Such a return to the 3308 data,
the generated files are not recorded binlog information Gtid
[root@mgr01 backup]# mysqlbinlog --stop-position="15018" /data/mysql/mysql3306/binlog/mysql-bin.000005|mysql -f --binary-mode -S /tmp/mysql3308.sock
ERROR 1781 (HY000) at line 17: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.
ERROR 1781 (HY000) at line 50: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.
ERROR 1781 (HY000) at line 74: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.
ERROR 1781 (HY000) at line 98: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.Of course, the following manner may be used to restore, binglog same document 3308 is not an example of the information recording Gtid, this method may occur an error in the recovery process, can not guarantee the completeness and correctness of data, so the production best not to use this method to retrieve the data recovery
[root@mgr01 backup]# mysqlbinlog --skip-gtids /data/mysql/mysql3306/binlog/mysql-bin.000001|mysql -f --binary-mode -S /tmp/mysql3308.sock
ERROR 1050 (42S01) at line 27: Table 'test1_event' already exists
ERROR 1062 (23000) at line 92: Duplicate entry '1' for key 'PRIMARY'
ERROR 1537 (HY000) at line 132: Event 'e_test' already exists
mysqlbinlog --skip-gtids /data/mysql/mysql3306/binlog/mysql-bin.000002|mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog --skip-gtids /data/mysql/mysql3306/binlog/mysql-bin.000003|mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog --skip-gtids /data/mysql/mysql3306/binlog/mysql-bin.000004|mysql -f --binary-mode -S /tmp/mysql3308.sock
mysqlbinlog --skip-gtids --stop-position="15018" /data/mysql/mysql3306/binlog/mysql-bin.000005|mysql -f --binary-mode -S /tmp/mysql3308.sockTips: production or the best open Gtid so restoring data and database synchronization, as well as solve the synchronization error is very convenient.
to sum up:
For DDL statements like drop database, drop tables, drop tables, this statement truncate table can be restored using mysqlbinlog. As well as tools to be used binlog2sql flashback
For such statements, whether binglog format row format, or the statement format, or Mixed format, binlog format are recorded in the format statement for the row
use mysqlbinlog only support database-level extraction
All equipment + use mysqlbinlog to a point in time recovery
using the mysqlbinlog --skip-gtids there is a big risk points