利用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正常

数据破坏，进行truncate table；

当线上发生truncate table的时候，如果改变没数据依然可以使用，但又不能没有这个表，则可以做以下处理;
插入一个跳跃性的主键作为标记，在恢复将数据导入的时候可以区分数据区间，并进行flush logs

模拟继续插入数据

三进行恢复

3.1创建3311伪master

在binlogserver服务器上3311上创建一个实例并读取备份的binlog；
注意：实际情况下是不会再binlogserver上创建实例的。且也只需要最近xtrabackup 进行全备后的binlog文件

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

虽然是注册进来但并没有执行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 的操作的位置，方法可参考另一篇文章
逻辑全备+binlog+只恢复单表数据：链接

指定停止点
"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起始点
此时观察xtrbackup_binlog_pos_innodb 内的日志位置和xtrabackup_info 是不同的
不过可以进行解析mysql-bin.000046 这里有没有操作（xtrabackup_info记录的是日志里的，因此会比xtabackup_binlog_pos_innodb(记录redo里的）可能会高一些。如果有操作需要手动进行恢复了如手动执行sql，或者日志导入，一般是ddl语句，ddl语句不记录到redo中。或者压根就没操作~~）

因此确定起点位
master_log_file=’mysql-bin.000045’,
master_log_pos=5729109,

创建主从

change master to
master_host='172.0.0.52',
master_port=3311,
master_user='repl',
master_password='repl',
master_log_file='mysql-bin.000045',
master_log_pos=5729109,
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

检查