利用伪master主机来增量恢复mysql

一.基本信息

版本：10.0.20-MariaDB-log

数据文件和redo log位置:/apps/dbdat/mariadb10_data3306/

bing log位置：/apps/dbdat/mariadb10_data3306/log

恢复主机信息:mvxl0784 10.16.24.109

伪master主机信息：mvxl0782 10.16.24.107

配置文件：/etc/my3306.cnf

二.伪master主机构建

1.搭建一个普通mysql server，作为伪master主机.

2.将需要恢复用的binlog文件copy到伪master主机的binlog位置：/apps/dbdat/mariadb10_data3306/log

先查看伪master主机上的binlog日志清单：

(product)root@localhost [(none)]> show binary logs;

+------------------+-----------+

| Log_name | File_size |

+------------------+-----------+

| mysql-bin.000001 | 507 |

| mysql-bin.000002 | 326 |

+------------------+-----------+

2 rows in set (0.00 sec)

copy需要恢复的binlog后，将需要恢复的binlog文件增加到mysql-bin.index文件中，如下：

[apps@mvxl0782 apps]$ cd /apps/dbdat/mariadb10_data3306/log/

[apps@mvxl0782 log]$ ls -ltr

total 1048604

-rw-r----- 1 apps apps 507 May 20 11:09 mysql-bin.000001

-rw-rw---- 1 apps apps 326 May 20 11:27 mysql-bin.000002

-rw-r----- 1 apps apps 104 May 20 11:27 mysql-bin.index

-rw-r----- 1 apps apps 536871119 May 20 11:38 mysql-bin.000271

-rw-r----- 1 apps apps 536871210 May 20 11:38 mysql-bin.000272

[apps@mvxl0782 log]$ vi mysql-bin.index

/apps/dbdat/mariadb10_data3306/log/mysql-bin.000001

/apps/dbdat/mariadb10_data3306/log/mysql-bin.000002

/apps/dbdat/mariadb10_data3306/log/mysql-bin.000271

/apps/dbdat/mariadb10_data3306/log/mysql-bin.000272

再查看：

(product)root@localhost [(none)]> flush logs;

Query OK, 0 rows affected (0.02 sec)

(product)root@localhost [(none)]> show binary logs;

+------------------+-----------+

| Log_name | File_size |

+------------------+-----------+

| mysql-bin.000001 | 507 |

| mysql-bin.000002 | 369 |

| mysql-bin.000271 | 536871119 |

| mysql-bin.000272 | 536871210 |

| mysql-bin.000273 | 365 |

+------------------+-----------+

5 rows in set (0.00 sec)

由于flush logs或重启mysql操作都会切换log，但由于这些新产生的log都没有事务操作，即使后面同步到从库

中执行，也不会影响到需要恢复的数据准确性。

三.slave上恢复

在需要恢复的库上执行：

(product)root@localhost [(none)]> select execution_status,execution_time,end_date from

`lots`.`t_task_log` where execution_date='2016-05-17 09:25:00';

Empty set (6.69 sec)

查询记录返回为空。

确认我们开始恢复的binlog位置：

我们查看备份集中的xtrabackup_info和xtrabackup_binlog_info文件

cat xtrabackup_info

start_time = 2016-05-17 01:00:01

end_time = 2016-05-17 01:11:55

lock_time = 2

binlog_pos = filename 'mysql-bin.000271', position 291755824, GTID of the last change '0-

19873306-348307239'

cat xtrabackup_binlog_info

mysql-bin.000271 291755824 0-19873306-348307239

从上面看到，备份开始时间为2016-05-17 01:00:01，完成时间为2016-05-17 01:11:55，对应的的binlog为

mysql-bin.000271，position为291755824。

在假master库上建立复制帐号：

(product)root@localhost [(none)]> grant replication slave on *.* to
'repl'@'10.16.24.%'

identified by "replsafe";

Query OK, 0 rows affected (0.00 sec)

从库上执行change master:

change master to

master_host='10.16.24.107',

master_port=3306,

master_user='repl',

master_password='replsafe',

master_log_file='mysql-bin.000271',

master_log_pos=291755824;

刚启动start slave,主从延迟比较大：

(product)root@localhost [(none)]> show slave status\G

*************************** 1. row ***************************

Slave_IO_State: Queueing master event to the relay log

Master_Host: 10.16.24.107

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000271

Read_Master_Log_Pos: 501712015

Relay_Log_File: relay-bin.000002

Relay_Log_Pos: 3071556

Relay_Master_Log_File: mysql-bin.000271

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 294826845

Relay_Log_Space: 209957017

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: 307799

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1073306

Master_SSL_Crl:

Master_SSL_Crlpath:

Using_Gtid: No

Gtid_IO_Pos:

1 row in set (0.00 sec)

等段时间到后面就追平了。

查看上面SQL查询记录：

product)root@localhost [(none)]> select execution_status,execution_time,end_date from

`lots`.`t_task_log` where execution_date='2016-05-17 09:25:00';

+------------------+----------------+---------------------+

| execution_status | execution_time | end_date |或

+------------------+----------------+---------------------+

| success | 218239 | 2016-05-17 09:28:38 |

| success | 859612 | 2016-05-17 09:39:19 |

| success | 519037 | 2016-05-17 09:33:39 |

| success | 9845 | 2016-05-17 09:25:10 |

| success | 528138 | 2016-05-17 09:33:48 |

| success | 300821 | 2016-05-17 09:30:01 |

| success | 528493 | 2016-05-17 09:33:48 |

+------------------+----------------+---------------------+

7 rows in set (0.21 sec)

或指定具体恢复目标位置:

先确认2016-5-18 0点所对应的binlog位置：

然后利用:START SLAVE UNTIL master_log_file='xxxx',master_log_pos=xxx恢复到指点时间点。