使用binlogserver的日志恢复单表

最近不知道写什么，就把以前写的文章拿出来吧。 

用这种伪装master方式恢复比直接导入binlog方法最大的好处是导入速度快，而且如果发生恢复异常会像正常主从复制异常一样有报错信息，方便排查；

这个是利用binlogserver保存的日志进行恢复单表的实验。

实验场景

1. 单实例库宕了且服务器无法启动，将数据恢复

2. 一套高可用库的服务器都挂了（得多倒霉），将数据恢复

具有的资源：xtrabackup 全备+ binlogserver 的日志

服务器介绍

实验思路

3308为生产库，为单实例且没有slave，有某时刻的xtrabackup的全备，使用binlogserver进行binlog实时备份。当3308某个表发生了truncate 。需要把数据恢复到truncate 前。

学习技能是：通过binlogserver 的日志作为伪装master 和利用xtrabackup恢复从库的方式进行恢复数据

实验操作

一.进行备份

xtrabackup备份

innobackupex --defatuls-file=/data/mysql/mysql3308/my3308.cnf  -S /data/mysql/mysql3308/mysql3308.sock -uroot -p --backup --no-timestamp /data/mysql/mysql3308/backup/full_back_`date +%F`.sql

创建binlogserver

[root@mysql-zst3 binlogserver]# nohup mysqlbinlog --raw --read-from-remote-server --host=172.0.0.51 --port=3308  --user=repl3307 --password=repl --stop-never  mysql-bin.000043 &

这次实验的全备备份是在  mysql-bin.000043 完成的，因此从这里开始进行binlogserver备份即可

二.数据破坏

• 实验表为sbtest_bk。此时sbtest_bk数据数，此时binlog位置，且binlogserver正常

该实例的uuid=e2b6a2cf-2e3c-11e8-a9cd-000c29817dea

因此未破坏数据的GTID为: e2b6a2cf-2e3c-11e8-a9cd-000c29817dea:132

• 数据破坏 进行truncate table；

三进行恢复

3.1创建3311伪master

在binlogserver服务器上3311上创建一个实例并读取备份的binlog；

注意：实际情况下是不会再binlogserver上创建实例的。

3.2搭建好3311实例后将binlog注册（show master status）

这个3311是一个没有数据的新实例。

虽然binlog是注册进来了，但并没有执行binlog内容

在3311上进行操作：

1、进行reset master，将日志信息清空
2、关闭3311实例
3、删除3311实例logdir下所有文件
4、将binlog server下的binary log拷贝到logdir，生成mysql-bin.index文件，修改权限
生成mysql-bin.index 文件方法

[root@mysql-zst3 logs]# ls /data/mysql/mysql3311/logs/mysql-bin.0000* > mysql-bin.index 

5、启动3311，show master status 这里的mysql-bin.000043-48为从binlogserver传过来的日志文件

show master status; 查看gtid情况

3.3搭建3312 作为3311的slave进行恢复

这个3312实例：使用的是的3308 使用xtrabackup的全备进行恢复的。

这里做了一个特殊的操作，如果有需要的可以参考，不需要可不操作:我只恢复systest库因此我把其他库都删除了(先进行--apply-log 后再进行删除）。除了系统库只剩了systest库进行恢复3312实例

innobackupex --apply-log full_back_`date +%F`.sql 
可以进行删除不需要的库，以减少copy的时间
innobackupex --defaults-file=/data/mysql/mysql3312/my3312.cnf --copy-back  full_back_`date +%F`.sql
修改权限
chown -R mysql.mysql *
启动实例
mysqld --defaults-file=/data/mysql/mysql3312/my3312.cnf &

检查3312实例状态

3.4搭建slave：3312，master：3311 的主从

3.4.1使用master_auto_positon=1（即指定gtid）

"root@localhost:mysql3312.sock  [systest]>change master to
master_host='172.0.0.52',
master_port=3311,
master_user='repl',
master_password='repl',
master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.11 sec)

指定复制停止点

这里需要解析出对应的binlog中发生truncate 的操作的位置，

指定停止点
"root@localhost:mysql3312.sock  [systest]>start slave sql_thread until sql_before_gtids='e2b6a2cf-2e3c-11e8-a9cd-000c29817dea:133'; 注意该value为一个值不是范围
Query OK, 0 rows affected (0.02 sec)

开启io thread

start slave io_thread;

检查

3.4.2使用master_auto_positon=0搭建主从

确认logfile，logpos起始点 查看xtrabackup 中的 xtrabackup_info 文件记录的position和gtid位置

因此确定起点位 master_log_file='mysql-bin.000046', master_log_pos=234,

创建主从

change master to
master_host='172.0.0.52',
master_port=3311,
master_user='repl',
master_password='repl',
master_log_file='mysql-bin.000046',
master_log_pos=234,
master_auto_position=0

确定终点位置mysql-bin.000046上解析图为：

指定复制终点，并开启io_thread

start slave sql_thread until master_log_file='mysql-bin.000046',master_log_pos=1910151;
start slave io_thread

检查