1. Event background
The MySQL database is automatically fully backed up at 0:00 every day
. At 9:00 a.m. one day, Ergouzi accidentally dropped a database.
We need to restore the data through the fully backed up data file and the incremental binlog file.
2. Main ideas and principles
1. Use the CHANGE MASTER statement recorded in the fully prepared sql file, the binlog file and its location point information to find out the incremental part of the binlog file
2. Use the mysqlbinlog command to export the above binlog file as a sql file, and remove the drop statement in it
3. By exporting the sql file of the full backup file and the incremental binlog file, the complete data can be restored
3. Schematic diagram of the process
4. Operation process
Just enter the command directly in the linux console, do not enter the mysqldump command after logging into the database
[root@Server db]# mysqldump -u用户名 -p 数据库名 > 数据库名.sql
simulated data
CREATE TABLE `student` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` char(20) NOT NULL,
`age` tinyint(2) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `index_name` (`name`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8
mysql> insert student values(1,'zhangsan',20);
mysql> insert student values(2,'lisi',21);
mysql> insert student values(3,'wangwu',22);
full command
mysqldump -uroot -p -B -F -R -x --master-data=2 test|gzip >/server/backup/test_$(date +%F).sql.gz`
Parameter Description:
-B 指定数据库
-F 刷新日志
-R 备份存储过程等
-x 锁表
--master-data 在备份语句里添加CHANGE MASTER语句以及binlog文件及位置点信息
Continue to insert data and delete database
mysql> insert student values(4,'xiaoming',20);
mysql> insert student values(5,'xiaohong',20);
When inserting data, we simulate misoperation and delete the test database.
mysql> drop database test;
At this time, between the time of full backup and the moment of misoperation, the data written by the user is in the binlog and needs to be restored.
View the newly added binlog file after full backup
cd /server/backup/
ls
test_2020-08-19.sql.gz
gzip -d test_2020-08-19.sql.gz
grep CHANGE test_2020-08-19.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=107;
This is the location of the binlog file at the time of full backup, that is, line 107 of mysql-bin.000003, so the data in the binlog file before this file has been included in this full backup sql file
. sql, remove the drop statement
cp /data/3306/mysql-bin.000003 /server/backup/
mysqlbinlog -d test mysql-bin.000003 >mysql-bin.000003.sql
Next, use vim to edit the mysql-bin.000003.sql file and remove the drop statement
Note: Before restoring the full backup data, the binlog file must be removed, otherwise, during the restoration process, the statement will continue to be written to the binlog, which will eventually cause the incremental recovery data to become confusing. Restoring
data
mysql -uroot -p < test_2020-08-19.sql
mysql -uroot -p -e "select * from test.student;"
±—±---------±----+
| id | name | age |
±—±---------±----+
| 1 | zhangsan | 20 |
| 2 | lisi | 21 |
| 3 | wangwu | 22 |
±—±---------±----+
At this time, the data at the full backup time is restored, and then the mysql-bin.000003.sql file is used to restore the new data between the full backup time and the deletion of the database.
mysql -uroot -p test < mysql-bin.000003.sql
mysql -uroot -p -e "select * from test.student;"
±—±---------±----+
| id | name | age |
±—±---------±----+
| 1 | zhangsan | 20 |
2 | lisi | 20 |
| 3 | wangwu | 20 |
| 4 | xiaoming | 20 |
| 5 | xiaohong | 20 |
±—±---------±----+
At this point, the entire recovery process is over, isn't it very simple? That's right, it's that simple! !
V. Summary
1. It is suitable for repairing when there are misoperations caused by artificial SQL statements or when there is no hot backup such as master-slave replication.
2. The recovery conditions must be fully prepared and incremental for all data.
3. It is recommended to stop external updates when restoring, that is, to prohibit updating the database.
4. First restore the full amount, then restore the incremental logs after the full backup time point into SQL files in order, and then delete the problematic SQL statements in the file (you can also use time and location points), and then restore to the database.
Congratulations on your successful recovery!