Preface
March 8, 2021, a beautiful day-Women’s Day, but I deleted my library today. I was really speechless. I experienced a 50-minute congested drive (10km distance) in the morning, but I couldn’t stop myself. The steps of the company’s deletion of the database came on Monday, alas, I didn’t have the courage to run away...
Close to the subject, to be honest, after realizing this step of my own operation, I first clarified the reason to the leader, and then it was exactly what the leader said, let I gave an initiation, awakened like a dream, and when I came down, I began to sharpen my sword and restore the data.
Recovery operation
step1: First restore with a complete data backup
Since our production environment is backed up by the database's backup script (regularly backed up every day), we obtain the backup sql and then execute it on the production environment. 
On the backup server:
cd /u01/databak/42/202103080400
scp 20210308_040001-wg_wenhai_data.sql.gz 数据库服务器ip:/root/
On the database server:
gunzip 20210308_040001-wg_wenhai_data.sql.gz
Log in to mysql to execute:
use wg_wenhai_data
source /root/20210308_040001-wg_wenhai_data.sql
step2: log viewed in binlog through mysqlbinlog
Note: Based on binlog recovery, although it can be recovered according to time, it can also be recovered through the corresponding end_log_pos after the time, which will be shown below.
Point-in-time recovery
1) mysqlbinlog view detailed location
mkdir /root/log
mysqlbinlog --base64-output=decode-rows -vvv /u01/mysql/mysqlbinlog/mysql-bin.000155 > /root/log/mysql-bin.000155.log
2) The command based on time recovery is as follows
mkdir /root/log/sql
mysqlbinlog /u01/mysql/mysqlbinlog/mysql-bin.000155 --start-datetime='2021-03-08 0:00:00' --stop-datetime='2021-03-08 9:40:43' > /root/log/sql/binlog-date.sql
Recover based on the position id of the binlog log
1) mysqlbinlog view detailed location
2) Obtain the position id value according to the recovery time point
The prerequisite for recovery is based on the time point of deleting the database before restoring the database. Since I covered the database in the production ring, I had to find the action of creating the initial database in the binlog in the overwritten database. This is why the position id is selected, because the green box is the start command of the overlay.
You can see that the position ids at midnight and 9:40:43 are 97506871 and 269167350, respectively.
mysqlbinlog --start-position=97506871 --stop-position=269167350 /u01/mysql/mysqlbinlog/mysql-bin.000155 > /root/log/sql/binlog.sql
Compare the file differences between the two methods: It is found that although the file size is not completely the same, but the number of insert, update, and delete is the same, so you can directly perform the recovery.
step3: log viewed in binlog through mysqlbinlog
mysql -uusername -ppassword -h127.0.0.1
source /root/log/sql/binlog-date.sql
