Reexploration of mysql backup and recovery

1. My current backup solution is:
A (master) -----> B (slave) for real-time synchronization, complete backup at every Sunday on B (slave), do from Monday to Saturday
Incremental backup, Incremental backup time selection, flexible modification according to business needs. When the DB fails, or the server business logic appears
When a major bug occurs and a gamer complaint is serious, we need to recover the data.
2. My current recovery plan is:
Stop all servers and perform a full backup and recovery on Server Load balancer:
Mysql-uroot-p ***** <allbackup. SQL
Then select a time point for incremental recovery:
Mysqlbinlog -- start-date = "14:00:00" -- stop-date = "17:30:00" mysql-bin. [0-9] * | mysql-uroot-p ****
In this way, all the forms of all databases are restored to normal.
3. The problem is:
Very troublesome and painful. If a problem occurs in the tb_account form in db_account, other databases are normal. So it is too difficult to do this,
Because full backup takes effect for all databases, such recovery also takes effect for all databases. After the restoration, you need to find the desired data on B (slave,
Import to A (master), and other data cannot be kept unchanged. Pain !!!
4. The improved solution is:
Perform full backup for each database without using the original method of backing up all databases (that is, the following method ):
Mysqldump-h $ HOST-u $ USER-p $ PASSWORD -- opt -- all-databases -- flush-logs> $ BAKDIR/$ DATESTR. SQL
In this way, the backup data of each database is generated in an SQL file, that is, the SQL file under the original backup directory is increased from one to N, so that
You can recover a specific database. If there is a problem with the database, you can recover the database. If there is no point in the database, you don't have to worry about my learning anymore.
Saves a lot of trouble. You can write as follows:
Mysqldump-h $ HOST-u $ USER-p $ PASSWORD -- flush-logs db_account> account. SQL
Mysqldump-h $ HOST-u $ USER-p $ PASSWORD -- flush-logs db_test1> test1. SQL
Mysqldump-h $ HOST-u $ USER-p $ PASSWORD -- flush-logs db_test2> test2. SQL
Mysqldump-h $ HOST-u $ USER-p $ PASSWORD -- flush-logs db_test3> test3. SQL
What should I do with Incremental backup?
What should I do if I incrementally restore db_account based on the time point? There is a way
Mysqlbinlog -- start-date = "14:00:00" -- stop-date = "17:30:00"-d db_account mysql-bin. [0-9] *
You can use-d to specify the database for incremental recovery, so that you can perform full backup recovery and Incremental Backup recovery for the specified database. How harmonious is everything.

5. A little worry:
The incremental data of db_account is deleted when a specific database db_account is fully backed up and flush-logs is used. Is there any of the following possible reasons:
5.1. The incremental data in the two databases is in a mysql-binfile.
5.2. the incremental data of a database is stored in two mysql-binfiles.
If the above possibilities exist, will there be any hidden risks or problems during the flush-logs process? For example, db_account is deleted when it is flush-logs.
A file, but this file also contains incremental data from other databases. Or flush-logs is not based on file deletion, but data deletion.
Find the incremental data of db_account in the file, and then delete the file. If the file has no data, delete the file. Everyone knows,
There are quite a few mysql-bin files. If you do not delete them, the hard disk will pop up one day.