MySQL incremental backup and recovery instance "go"

A small number of databases can be fully backed up every day, as this will not take much time, but when the database is large, it is unlikely that a full backup will take place every day, and an incremental backup can be used. The principle of incremental backup is to use the MySQL binlog log.
The MySQL version of this operation is 5.5.40 for Linux (x86_64) .

Incremental backup to ensure that binary logs are turned on, refer to the MySQL log system:

Mysql> Show variables like '%log_bin% ';

First make a full backup of the PAK database:

$ mysqldump-h localhost-upak-ppwd-p3306--master-data=2--single-transaction--opt Pak > Pak_bak_full.sql

At this point, you will get a fully-prepared file pak_bak_full.sql. The mysqldump operation causes the log to scroll once, assuming that the new Binlog file is mysql-bin.000002.

1. Simulate the insertion of data and mis-operation

A. Insert some data into a table in the Pak Library and execute the flush logs command. This will result in a new binary log file, mysql-bin.000003,mysql-bin.000002, which saves all the changes that were made after the full backup, as well as the addition of the recorded operations to the mysql-bin.00002.

B. Add two records to the T_user table in the Pak library and delete the T_user table by mistake. The actions for adding records and deleting tables in T_user are recorded in mysql-bin.000003.

2. Start recovery

The recovery process does not log:

MySQL > Set global sql_log_bin=0;

3. First import full data

$ mysql-h Localhost-upak-ppwd < pak_bak_full.sql or mysql> source/path/backup/pak_bak_full.sql

We can also see the binlog position at full standby:

head-50 backup-file.sql |grep ' Change Master ' – Change Master to master_log_file= ' mysql-bin.000001 ', master_log_pos= 4321;

To view the location in your current binary log:

head-50 backup-file.sql |grep ' Change Master ' – Change Master to master_log_file= ' mysql-bin.000001 ', master_log_pos= 4321;

According to the above two position can probably determine which several binlog files need to be fully recovered.

4. Restore mysql-bin.000002

Position or point-in-time before recovery, full-ready binlog need to be fully recovered, multiple files separated by spaces

$ mysqlbinlog/var/lib/mysql/mysql-bin.000002 | Mysql-uroot-p

At this point the query can get the first two data.

5. Recovering some mysql-bin.000003

This log contains the new record and the two parts of the mis-deleted table, we need to restore to the new record, the location of the previous error delete operation.

If you know the command for the Misoperation DROP TABLE , you can find the position before the misoperation in the Binlog file by using the following method:
(as shown in the following information, DROP TABLE POS before misoperation is 775, done at datetime 141204 15:08:04 or pos 882 DROP TABLE )

$ mysqlbinlog/var/lib/mysql/mysql-bin.000003 |grep-c 5 ' DROP TABLE '#141204 15:07:05 server ID 1 end_log_pos 775 Xid = 376commit/*!*/; # at 775#141204 15:08:04 server ID 1 end_log_pos 882 Query    thread_id=10    exec_time=0    error_code=0SET timestamp=1417676884/*!*/;D rop TABLE ' t_user '/* generated by Server *//*!*/; # at 882
           

Restore command:

$ mysqlbinlog/var/lib/mysql/mysql-bin.000003--stop-position=775 | Mysql-h localhost-uroot-p

If position is difficult to determine, but knows the exact (server) time to restore to, you can also use DateTime:

$ mysqlbinlog/var/lib/mysql/mysql-bin.000003--stop-datetime= "2014-12-04 15:08:00" | Mysql-uroot-p

If the database is migrated instead of the wrong operation, then no position or datetime is required and incremental recovery is done with all binlog files.

When you are sure that the recovery is successful, remember to turn on logging:

MySQL > Set global sql_log_bin=1;

Error

1. Unknown variable ' Default-character-set=utf8 '
   When using mysqlbinlog the view binary log, the following error is prompted:

   /usr/local/mysql/bin/mysqlbinlog:unknown variable ' Default-character-set=utf8 '

   The reason is that in my order to unify the MySQL client to the service side of the character encoding, in the /etc/my.cnf file [client] , the [mysqld] section joins default-character-set = utf8 , mysqlbinlog will be my.cnf read from the [client] configuration, But Mysqlbinlog does not recognize this option, which is said to be a bug.

   There are two ways to deal with this bug:
   First, nature is the annotation to the [client] character set in the configuration;
   Second, instead loose-default-character-set = utf8 . Added before the option, indicating that this option is skipped loose- when the program does not recognize this option and gives a warning.

Turn from

MySQL incremental backup and Recovery instance | Sean ' s Notes
http://seanlook.com/2014/12/05/mysql_incremental_backup_example/

MySQL incremental backup and recovery instance "go"